April 1997

All, I have customer that has a USR Total Control Hub with a Netserver card that will be configuring a port/modem to dial into my PM2ER-30 (ComOS 3.5) -- are there any known caveats that I should be concerned about??? I'm presuming (since I'll control the Radius config) that I'll configure the port just as if an NT (or other routable OS) was dialing in and set the IP address, routing on, etc and it will react similiarly -- bad presumption or does that sound solid...? Thanks, Timothy

Two items. First, I haven't been able to get MPPP to work with an Ascend = Pipeline using ISDN and the USR TCE hub, the second channel never comes = up. Does anyone use these two boxes successfully with MPPP? And second, = does STAC or MS-STAC compression work between these two (and how can one = tell)?=20 thanks in advance. pete@ebay.com

Well, I'm not sure about the STAC compression (I have it turned on, and it _seems_ to work, but I'm not positive it _does_ work), but I have my Pipeline 130 connected to our USR Netserver (3.3.28) with two B-channels all of the time. Ironically, the Pipeline never drops a channel or a connection, but the USR Courier I-modem I have (with the newest flash code) always has problems. On the P130 (not sure about the 25 or 50), this is how I set it up: >From the Main Edit Menu -> 20-000 Ethernet -> 20-100 Connections -> 20-10* (name of your connection) -> Encaps options... Now set the following (for full-time 128k connections): Base Ch Count=2 Min Ch Count=2 Max Ch Count=2 This does the trick for myself and a couple of other customers with ISDN access. I hope this helps. By the way, if the Netserver you're connecting to is using RADIUS, make sure that you are allowed to achieve two simultaneous connections. David Wielech Chief Network Engineer TelephoNET Corporation At 11:48 AM 4/2/97 -0800, you wrote: >Two items. First, I haven't been able to get MPPP to work with an Ascend Pipeline using ISDN and the USR TCE hub, the second channel never comes up. Does anyone use these two boxes successfully with MPPP? And second, does STAC or MS-STAC compression work between these two (and how can one tell)? > >thanks in advance. > >pete@ebay.com > >

After messing around with "pppmodem on|off" and doing some tests, I ran into what appears to be a bigger problem. For testing, I was using "netperf" which is available from ftp.ee.lbl.gov. The TCP_STREAM and TCP_RR worked well (albeit slowly), but UDP_STREAM failed repeatedly with the error: netperf: receive_response: no response received. errno 4 counter 0 Note that this only happened when I was sending from a network OUT through the Total Controls to a client connected in via modem. Sending from the client IN through the Total Controls yielded no problems, and quite good performance. It is also interesting to note that the UDP_RR test worked in both directions. So it appears to be a constant stream problem that the Netserver is running up against. Dropping UDP stream packets on the floor would jive with what we've been seeing with Quake/RealAudio clients. Has anyone else seen this? For reference, my Netserver card is on version 3.3.28.

Once upon a time Brian shaped the electrons to say... >are any of us that purchased at $33,000 going to get money back? Is there >some kind of price protection or no? April Fools day was yesterday. Seriously - if you by a car and the next week they go on sale you can't go in and demand a refund. I think it is silly that people complain that a vendor dropped their price. Obviously when you bought it you thought it was worth it. You could have spent a lot less on another vendor's box, but you didn't. So now USR has a promotion to try and sell more TCs. That's life. Expecting money back is completely irrational. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

We purchased a USR TCE system with 48 ports for $33,000 a few months back. Now supposedly I hear USR has some promotion where these are less than $15,000.............. are any of us that purchased at $33,000 going to get money back? Is there some kind of price protection or no? 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

Surely you jest, refunds? Let the buyer beware! At 07:37 PM 4/2/97 -0600, you wrote: > >We purchased a USR TCE system with 48 ports for $33,000 a few months back. >Now supposedly I hear USR has some promotion where these are less than >$15,000.............. > >are any of us that purchased at $33,000 going to get money back? Is there >some kind of price protection or no? > >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 > > > Thanks, Greg Coffey, CoffeyNet ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. 307-234-5443 307-234-5446 Fax Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, http://www.coffey.com Wheatland, Pinedale, Lander & Lusk, WY ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Once upon a time Brian shaped the electrons to say... >what did you all pay, and when did you buy your units? We have the 48port >USR TCE hub, NMC card, 1 ps, isdn, can accept 2 pri's >$33k, 2 months ago Ouch - two months ago you could get a Livingston PM-3 or an Ascend MAX for half that. What made you decide on a USR TC? Seriously - there had to be something the others were lacking, right? -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Is this $15,000 price on the TCE legit or just somebody's idea of a good april fools joke? Lamar Townsend

On 3-25-97 @ 9:05pm, Tom Bilan wrote: > Also, the TC is returning the property #26 and it isn't defined > in the radius dictionary file. I even downloaded the latest radiusd > and dictionary file. I tried adding it in myself and it didn't > return anything that made sense to me. I tried changing the value > to type string, ipaddr, integer and date. The RADIUS attribute #26 is called "Vendor Specific Attributes", and is a standard location for defining proprietary extensions to the RADIUS protocol (as opposed to some non-standard locations used by other vendors). If you take a look at the IETF spec for RADIUS, you'll get an idea on how the Vendor Specific attributes should be formatted. As for what USR does with them, here's a quick list: x9000 IP-Input-Filter (framed user access accept, string) x9001 IPX-Input-Filter (framed user access accept, string) x9003 IP-Output-Filter (framed user access accept, string) x9004 IPX-Output-Filter (framed user access accept, string) x9005 SAP-Output-Filter (framed user access accept, string) x9006 VPN-ID (framed user access accept/accounting, integer) x9007 VPN-Name (framed user access accept, string) x9008 VPN-Neighbor (framed user access accept, IP addr) x9009 Framed-Routing-V2 (framed user access accept, integer) x900A VPN-Gateway (framed user access accept, IP addr) x900B Tunnel-Authenticator (framed user access accept, IP addr) x900C Packet-Index x900D Cutoff x900E Access-Accept-Packet All except the "filter" attributes are used in our VPN setup information, and only the VPN-ID (x9006) should appear in the RADIUS accounting records. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

On Wed, 2 Apr 1997, Greg Coffey wrote: So did we......But, belly up and buy more TC Racks at the new lower price and dollar cost average down your port costs. Example: $33,000/48 = $675/port [tough ! ] $15,000/48 = $312/port [ nice ] ______ $48,000/96 = $500/port...lower than $675 above $15,000

On Wed, 2 Apr 1997, Greg Coffey wrote: > Surely you jest, refunds? Let the buyer beware! > > > At 07:37 PM 4/2/97 -0600, you wrote: > > > >We purchased a USR TCE system with 48 ports for $33,000 a few months back. > >Now supposedly I hear USR has some promotion where these are less than > >$15,000.............. > > > >are any of us that purchased at $33,000 going to get money back? Is there > >some kind of price protection or no? > > > >Brian > > > > alot of times vendors offer a "price-protected" price on an item, I just didn't know if there was price protection on the USR system......... what did you all pay, and when did you buy your units? We have the 48port USR TCE hub, NMC card, 1 ps, isdn, can accept 2 pri's $33k, 2 months ago > > > Thanks, > Greg Coffey, CoffeyNet 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

Pete Ashdown <pashdown@xmission.com> writes: > Dropping UDP stream packets on the floor would jive with what we've been > seeing with Quake/RealAudio clients. Has anyone else seen this? > > For reference, my Netserver card is on version 3.3.28. Hmm - is there any possibility that there is a MTU mismatch or that the client in question can't handle a fragmented UDP datagram? Since the TCP tests work, I'm guessing that the client and NETServer are in agreement as to the MTU, but if for example the dialup is using a smaller MTU than the ethernet on which your netperf is running, then perhaps the NETServer has to fragment the UDP packet over the dialup link. I've had trouble before with PC implementations that don't process fragmentation reassembly (at all or properly) for UDP packets. This can also hit you sometimes with DNS queries, if the response is bigger than the dialup MTU. If this is the same environment under which the Annex you've mentioned earlier works properly, is there any difference (either in configuration or in final negotiations for a dialup session) in terms of MTU for the dialup link, or I guess for the ethernet of either server device. If the client supports some sort of debugging, you could also enable tracing on the NETServer and then on the client and compare the two ends of the connection to see if they agree on the packets involved. -- David

There is no existing command to easily summarize how many ports are active/ready vs. active/online vs. inactive. The closest that I can suggest is a parse of the command "show all", which would tell you which port (ie., S10, S11, I5, I6) and the port status (ie., A R P, A I -, I I P, A I P, etc...) -OR- a parse of the command "show sessions" and look at the port number (again, S10, S11, I5, I6) and whether there's a user listed in the Users column or a - (no user). As far as managing the port usage and duplicate logins and etc..., we've been working on a protocol called RADIUS Resource Management, which adds RADIUS messages to handle issues such as you mentioned via a "smarter" RADIUS server, including IP/IPX address pooling and duplicate user logins and number of multilink sessions. The nice thing about the RADIUS server managing those resources is that you can vary service based upon time-of-day, such as limiting the number of sessions during prime hours but allow more bandwidth during low-traffic periods. This new functionality is part of NETServer v3.3.x code and later, and needs to work with a RADIUS server that shares the protocol enhancements, such as Merit's v2.0 server release (we worked very closely with Merit to design this). Any thoughts on that idea? Are we off-track on that? Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________ Reply Separator _________________________________ Author: Laszlo Vecsey <master@internexus.net> at Internet Is there a netserver console command to show how many Sxx ports (quad modems) are available, or more accurately, online and prepared for a call? (The system might have more quad modems/ports than PRI lines to handle them) I'm finishing up a freeware utility that does a few different things, (disconnects duplicate logins, people over a certain idle or online time.. especially during prime time hours) and it would be helpful if the user wouldn't have to specify a maxport setting.. but instead it would be extracted from somewhere.

--IMA.Boundary.283050068 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Timothy, I don't know of any "gotcha's" to this configuration. In fact, you need to setup both with location table entries for LAN-to-LAN routing. This should be a pretty easy config, because the NETServer will think it's dialing into another NETServer, and the PortMaster will think it's talking to another PortMaster. I haven't specifically tried with PortMaster v3.5, but I know we've tried this with several different versions on both sides, and have had consistent (positive) results. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________ Reply Separator _________________________________ Author: Timothy Deem <tdeem2@alpha.comsource.net> at Internet All, I have customer that has a USR Total Control Hub with a Netserver card that will be configuring a port/modem to dial into my PM2ER-30 (ComOS 3.5) -- are there any known caveats that I should be concerned about??? I'm presuming (since I'll control the Radius config) that I'll configure the port just as if an NT (or other routable OS) was dialing in and set the IP address, routing on, etc and it will react similiarly -- bad presumption or does that sound solid...? Thanks, Timothy --IMA.Boundary.283050068 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 341991B0; Tue, 1 Apr 97 17:24:11 -0600 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id RAA09847; Tue, 1 Apr 1997 17:26:12 -0600 (CST) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wCCVH-0004He-00; Tue, 1 Apr 1997 15:58:11 -0700 Received: from alpha.comsource.net (alpha.comsource.net [205.243.40.1]) by mail.xmission.com (8.8.5/8.7.5) with SMTP id PAA16374 for <usr-tc@xmission.com>; Tue, 1 Apr 1997 15:57:53 -0700 (MST) Received: from localhost by alpha.comsource.net; (5.65v3.2/1.1.8.2/17May96-0857AM) id AA24588; Tue, 1 Apr 1997 16:52:54 -0600 USR Total Control Listserv <usr-tc@xmission.com> Message-Id: <Pine.OSF.3.95.970401165016.10962A-100000@alpha.comsource.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.283050068--

--IMA.Boundary.383050068 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Pete, First, are you saying/using "MultiLink PPP" or "MP+". The Total Control NETServer doesn't support MP+, so that may be the issue you're running into. If the NETServer refuses the MP+ request and the Pipeline doesn't attempt Multilink PPP, then you'll never get the second channel to come up; there's no commonly-used protocol in that link to say how to put them back together on the Hub side. If you haven't already, try FORCING a MultiLink PPP call (not MP+). And Yes, both STAC and Microsoft compression schemes work between these two; in fact, although we don't directly support it, you can often get Ascend compression to work between these two (it's close enough to Microsoft compression to fool the negotiation sometimes). Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________ Reply Separator _________________________________ Author: pete helme <pete@ebay.com> at Internet Two items. First, I haven't been able to get MPPP to work with an Ascend Pipeline using ISDN and the USR TCE hub, the second channel never comes up. Does anyone use these two boxes successfully with MPPP? And second, does STAC or MS-STAC compression work between these two (and how can one tell)? thanks in advance. pete@ebay.com --IMA.Boundary.383050068 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 342BBB20; Wed, 2 Apr 97 14:04:03 -0600 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id OAA06737; Wed, 2 Apr 1997 14:06:02 -0600 (CST) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wCW2j-000614-00; Wed, 2 Apr 1997 12:50:01 -0700 Received: from thompson.ebay.com (thompson.ebay.com [206.184.213.42]) by mail.xmission.com (8.8.5/8.7.5) with ESMTP id MAA22975 for <usr-tc@xmission.com>; Wed, 2 Apr 1997 12:49:18 -0700 (MST) Received: from ip130.ebay.interbahn.net (ip130.ebay.interbahn.net [205.215.226.130]) by thompson.ebay.com (8.8.5/8.6.12) with SMTP id LAA00592 for <usr-tc@xmission.com>; Wed, 2 Apr 1997 11:48:55 -0800 (PST) Received: by ip130.ebay.interbahn.net with Microsoft Mail id <01BC3F5B.D8BC8AA0@ip130.ebay.interbahn.net>; Wed, 2 Apr 1997 11:48:57 -0800 Message-ID: <01BC3F5B.D8BC8AA0@ip130.ebay.interbahn.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.383050068--

Peter Evans <peter@gol.com> writes: > since the netserver knows who's doing what, how about making this > information available by snmp. then we could just snmpwalk the > appropriate bits, see who's on what and perhaps use an snmp > write to boot off anyone who is on twice. > > this could, conceivably be useful don't you think? > > better than logging on every five minutes and doing a "show sessions" > ^_^! Hmm - well, if you compare using UDP or TCP and SNMP or TELNET, your 5 minute "show sessions" operation is functionally equivalent to your snmpwalk. Slightly different parsing (text lines versus SNMP objects) but not all that different, and arguable more efficient and faster :-) Personally, we use a locally developed tool to encapsulate the login sequencing so that we can issue commands to any NETServer in the network without worrying about passwords and the underlying telnet. While a single binary now, it started life as an expect script so something like that could be used in lieu of snmpwalk with publically available tools. We actually do have regular tasks that monitor NETServer configuration and usage information via such "scripts," although not for this specific purpose. So it's very doable. Of course, that's not to say that SNMP management isn't an attractive feature. But to be honest, my personal preference should things move more in that direction is to see the NETServer manageable via SNMP via the NMC rather than requiring that it be communicated with as a separate device, unlike the other cards in the chassis. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

>Ouch - two months ago you could get a Livingston PM-3 or an Ascend MAX for >half that. What made you decide on a USR TC? Seriously - there had to be >something the others were lacking, right? For me, reading DataCom's labtest review of the Ascend MAX caving in with only 16 connections made me decided against the Ascend. That and their incessant marketing blather (I receive more junk from Ascend than anyone else). The reason I decided against the Livingston is that I couldn't find any reviews/tests of it anywhere, plus the fact that we have to sell off 350+ USR Couriers. Selling an incompatible modem with our service wouldn't make much sense. Can you please try to keep advocacy of your company's product off this list? -- Pete XMission

It's legit, I got a call from George Mulry at Westcon this morning with the details. Have gotten 3-4 email offers too from other firms. At 09:37 PM 4/2/97 -0600, you wrote: >Is this $15,000 price on the TCE legit or just somebody's idea of a good april fools joke? > >Lamar Townsend > > Thanks, Greg Coffey, CoffeyNet ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. Local Internet for Casper, Rawlins, Douglas, Casper, WY 82601 Wheatland, Pinedale, Lander & Lusk, WY http://www.coffey.com (307) 234-5443 ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

On Fri, 4 Apr 1997, Bob Purdon wrote: > > > For me, reading DataCom's labtest review of the Ascend MAX caving in with > > only 16 connections made me decided against the Ascend. That and their > > incessant marketing blather (I receive more junk from Ascend than anyone > > else). > > Same here - everyone we talked to (except the Ascend dealer) told us of > performance and code stability problems on the Ascend. Price was horrendous. We've been using Maxs for quite a while. I have a 4000 with 4 PRIs running isdn and I get 12K - 13K connections with no problems. We have another 4000 with 48 modems, and I haven't noticed any problems either. The version of the month game can get to be annoying, but I guess that's the price we pay for more and more features. > > > The reason I decided against the Livingston is that I couldn't find any > > reviews/tests of it anywhere > > We couldn't even get Livingston gear here, and even when we can (RSN) we > would be one of the first guinea pigs in Australia with one. Not a > comfortable situation. Pricing was OK. > > Cisco - didn't trust their Microcom modems after hearing of everyone's > problems with the modem code and the new IOS features. I like IOS though. > > So, we went USR. We love their modems, although their 'personalised' version > of Livingston's ComOS both comforted us and worried us at the same time. It > was modem stability that was most critical to us at the time, and we've most > definitely achieved that. V.FC support was also important. > We just installed a USR rack. The product is quite nice, the architecture is somewhat strange and the support sucks. I don't understand why when I buy a device from USR, I need to upgrade it in 4 different places. When I upgrade a Max I just upgrade it once and I'm done. What really pisses me off though is USR's policy with support. You do get 90 days free support, but you have to call support and wait for hours for them to mail you the upgrade that you should have had installed in the chassis in the first place. So here I sit on $24,000 worth of equipment that came pre installed with an old version of the software, I can log into their ftp site and see the version of the software I need, but I can't download it cause I don't have a support contract. I need to call support to have them email it to me, and then they of course email me the wrong version so I have to go through this 3 or 4 times. Ascend's support is light years ahead as far as I'm concerned. Livingston's used to be quite good too, but I haven't tried it recently. Dror Dror Matalon Voice: 510 649-6110 Direct Network Access Fax: 510 649-7130 2039 Shattuck Avenue Modem: 510 649-6116 Berkeley, CA 94704 Email: dror@dnai.com

At 12:43 AM 4/3/97 -0600, kjohnson@usr.com wrote: > Pete, > > First, are you saying/using "MultiLink PPP" or "MP+". The Total > Control NETServer doesn't support MP+, so that may be the issue you're > running into. If the NETServer refuses the MP+ request and the > Pipeline doesn't attempt Multilink PPP, then you'll never get the > second channel to come up; there's no commonly-used protocol in that > link to say how to put them back together on the Hub side. If you > haven't already, try FORCING a MultiLink PPP call (not MP+). Just an FYI here....the Pipeline will request MP+ and MP in the initial LCP request (when configured for it)...the TC *should* reject MP+...and everything will then follow the normal PPP/LCP negotiation rules. If MP is not negotiated for whatever reason, then obviously the second channel would not come up. > And Yes, both STAC and Microsoft compression schemes work between > these two; in fact, although we don't directly support it, you can > often get Ascend compression to work between these two (it's close > enough to Microsoft compression to fool the negotiation sometimes). Curious observation..since Ascend's original CCP negotiation was significantly different from the final-spec CCP negotiation.... Kevin Smith Updated Service and Support Senior Technical Support Engineer Resources are now at: Customer Satisfaction Ascend Communications http://www.ascend.com/service

We currently have 24 USR Total Control racks, each with 48 ports, chan T1 card, NMC, NetServer, the works. 4 of them are the new Enterprise Hubs (with the dual power supplies), and a majority have single-sided modems (although some of the older ones have double-sided). All of the racks authenticate via radiusd 2.4.21. Recently, almost randomly, some of our users when they dial in get a "Host Unavailable" message when they try to send their username and then it promplty hangs up. Has anyone ever seen this before or know what might cause it? Because there are so many racks, and because this problem seems totally random (I don't ever seem to get it, and by the time the helpdesk calls me to complain, it's all gone) I'm having a heck of a time debugging what could cause it. All the NetServers can ping the boxes and don't lose network connectivity (we can tell via some monitoring programs we have written) when this occurs. Can anyone tell me at least a starting point for this, what to check for? All the settings across the racks should be identical (we have an expect script to set them up) and we've never had a problem in the past with those settings. -jkk -- Jim Klossner - jkk@frontiernet.net http://www.frontiernet.net Frontier Internet Operations and Administrative Center (716) 777-8745

> > April Fools day was yesterday. > but WAS it an April Fools joke? Brian > Seriously - if you by a car and the next week they go on sale you can't go > in and demand a refund. > > I think it is silly that people complain that a vendor dropped their price. > Obviously when you bought it you thought it was worth it. You could have > spent a lot less on another vendor's box, but you didn't. > > So now USR has a promotion to try and sell more TCs. That's life. Expecting > money back is completely irrational. > > -MZ > -- > Livingston Enterprises - Chair, Department of Interstitial Affairs > Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com > For support requests: support@livingston.com <http://www.livingston.com/> > Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > 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

> > April Fools day was yesterday. > but WAS it an April Fools joke? Brian > Seriously - if you by a car and the next week they go on sale you can't go > in and demand a refund. > > I think it is silly that people complain that a vendor dropped their price. > Obviously when you bought it you thought it was worth it. You could have > spent a lot less on another vendor's box, but you didn't. > > So now USR has a promotion to try and sell more TCs. That's life. Expecting > money back is completely irrational. > > -MZ > -- > Livingston Enterprises - Chair, Department of Interstitial Affairs > Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com > For support requests: support@livingston.com <http://www.livingston.com/> > Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > 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

kjohnson@usr.com wrote: | As far as managing the port usage and duplicate logins and etc..., | we've been working on a protocol called RADIUS Resource Management, | which adds RADIUS messages to handle issues such as you mentioned via | a "smarter" RADIUS server, including IP/IPX address pooling and | duplicate user logins and number of multilink sessions. The nice | thing about the RADIUS server managing those resources is that you can | vary service based upon time-of-day, such as limiting the number of | sessions during prime hours but allow more bandwidth during | low-traffic periods. | This new functionality is part of NETServer v3.3.x code and later, and | needs to work with a RADIUS server that shares the protocol | enhancements, such as Merit's v2.0 server release (we worked very | closely with Merit to design this). hope they despag'ed that source this time. | Any thoughts on that idea? Are we off-track on that? since the netserver knows who's doing what, how about making this information available by snmp. then we could just snmpwalk the appropriate bits, see who's on what and perhaps use an snmp write to boot off anyone who is on twice. this could, conceivably be useful don't you think? better than logging on every five minutes and doing a "show sessions" ^_^! Peter ----* -- O_u \\ Ciscomancer // \\ Global OnLine Japan U \Beh! \\ Postmonster // Ukyu? \\ Engineering Dept.

On Wed, 2 Apr 1997 kjohnson@usr.com wrote: > On 3-25-97 @ 9:05pm, Tom Bilan wrote: > > Also, the TC is returning the property #26 and it isn't defined > > in the radius dictionary file. I even downloaded the latest radiusd > > and dictionary file. I tried adding it in myself and it didn't > > return anything that made sense to me. I tried changing the value > > to type string, ipaddr, integer and date. > so can USR give all of us a dictionary, that say any UNIX radius can read, complete with ALL the USR attributes? I did get a dictionary from USR once, it was missing many of your common Radius attributes such as Port-Type and Port-Limit..........it did have USR attributes tho..... what i need is for USR to put together a list of ALL attributes understood by the TCE hub....... 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

> > This new functionality is part of NETServer v3.3.x code and later, and > needs to work with a RADIUS server that shares the protocol > enhancements, such as Merit's v2.0 server release (we worked very > closely with Merit to design this). > > Any thoughts on that idea? Are we off-track on that? I have Netserver 3.3.28 I also have Merit 2.0 is this functionality working? documented? I got a Merit radius once from USR, it was 2.4.20 with USR extenstions, severely hacked up.........it only partially worked..........it got rid of all the "Vendor-Specific-Attribute" messages in my log files, by defining proper attributes in the dictionary file, but alot of the util programs, although they compiled, did not function. > > Kurtiss > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~ __ __ ~ > ~ Kurtiss Johnson | | | | RRRRR ~ > ~ Product Manager | | | | ***RR RR ~ > ~ US Robotics | \_/ |*** RRRRR ~ > ~ kjohnson@usr.com \___/ RR RR ~ > ~ See us at www.usr.com! ~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > ______________________________ Reply Separator _________________________________ > Subject: (usr-tc) available ports/lines > Author: Laszlo Vecsey <master@internexus.net> at Internet > Date: 3/28/97 3:07 PM > > > Is there a netserver console command to show how many Sxx ports (quad > modems) are available, or more accurately, online and prepared for a call? > (The system might have more quad modems/ports than PRI lines to handle > them) > > I'm finishing up a freeware utility that does a few different things, > (disconnects duplicate logins, people over a certain idle or online time.. > especially during prime time hours) and it would be helpful if the user > wouldn't have to specify a maxport setting.. but instead it would be > extracted from somewhere. > > 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

> > This new functionality is part of NETServer v3.3.x code and later, and > needs to work with a RADIUS server that shares the protocol > enhancements, such as Merit's v2.0 server release (we worked very > closely with Merit to design this). > > Any thoughts on that idea? Are we off-track on that? I have Netserver 3.3.28 I also have Merit 2.0 is this functionality working? documented? I got a Merit radius once from USR, it was 2.4.20 with USR extenstions, severely hacked up.........it only partially worked..........it got rid of all the "Vendor-Specific-Attribute" messages in my log files, by defining proper attributes in the dictionary file, but alot of the util programs, although they compiled, did not function. > > Kurtiss > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ~ __ __ ~ > ~ Kurtiss Johnson | | | | RRRRR ~ > ~ Product Manager | | | | ***RR RR ~ > ~ US Robotics | \_/ |*** RRRRR ~ > ~ kjohnson@usr.com \___/ RR RR ~ > ~ See us at www.usr.com! ~ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > ______________________________ Reply Separator _________________________________ > Subject: (usr-tc) available ports/lines > Author: Laszlo Vecsey <master@internexus.net> at Internet > Date: 3/28/97 3:07 PM > > > Is there a netserver console command to show how many Sxx ports (quad > modems) are available, or more accurately, online and prepared for a call? > (The system might have more quad modems/ports than PRI lines to handle > them) > > I'm finishing up a freeware utility that does a few different things, > (disconnects duplicate logins, people over a certain idle or online time.. > especially during prime time hours) and it would be helpful if the user > wouldn't have to specify a maxport setting.. but instead it would be > extracted from somewhere. > > 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

Jim Klossner <Jim_Klossner@frontiernet.net> writes: > Recently, almost randomly, some of our users when they dial in get a > "Host Unavailable" message when they try to send their username and then > it promplty hangs up. The Host Unavailable would indicate that the NETServer attempted to connect somewhere and failed. You don't mention what the service model is, but you don't generally see this with SLIP/PPP but only with telnet/rlogin/portmux sort of services. I know you indicated that all the units were configured identically, but you might want to verify that all of your ports have security enabled. If they don't, and a user hits that port, it will revert to automatically making a connection (telnet I think) to the global or port host list, which is probably all 0.0.0.0 in your config, assuming a PPP service. In such a case, it won't be able to reach the "0.0.0.0" host and will generate such a message. > Because there are so many racks, and because this problem seems > totally random (I don't ever seem to get it, and by the time the helpdesk > calls me to complain, it's all gone) I'm having a heck of a time debugging > what could cause it. I would certainly suggest seeing if your helpdesk can obtain any banner information from your NETServer from the customer - depending on the package they may be able to pop up a log window showing the login sequence. If that's the case, and if you have port information in your banner it'll probably help identify the point where they entered the system. Then, the NETServer syslogs or any accounting daemon logs would be a logical place to check, as well as your authentication daemon logs to see if any requests were even made. If not, then perhaps just crunching your NETServer syslogs to try to find callers that failed to make a PPP connection could help focus attention. True, there will be a possible SNR problem in the logs due to "normal" failures, but some patterns may jump out. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

> What really pisses me off though is USR's policy with support. You > do get 90 days free support, but you have to call support and wait for > hours for them to mail you the upgrade that you should have had installed > in the chassis in the first place. So here I sit on $24,000 worth of equipment > that came pre installed with an old version of the software, I can log > into their ftp site and see the version of the software I need, but > I can't download it cause I don't have a support contract. I need to > call support to have them email it to me, and then they of course > email me the wrong version so I have to go through this 3 or 4 times. well what do you think the alternative is? We had them come out and install the new version of all the software (they installed the unit etc), and they installed the latest versions, and left us with outdated manuals.......so we dont even have to docs to use the stuff......we had to print out about a gazillion pdf files........either way the support sucks Brian > > > Dror > > Dror Matalon Voice: 510 649-6110 > Direct Network Access Fax: 510 649-7130 > 2039 Shattuck Avenue Modem: 510 649-6116 > Berkeley, CA 94704 Email: dror@dnai.com > 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

First let me say that Bell Atlantic has to be the WORST company when it comes to provisioning PRI and T1 lines. Not only are they always late (3 months in one case) they NEVER have installed one right the first time. We have had our TC enterprise hubs for almost 2 months now and finally are able to use them now that our lines are starting to be installed. My main point of this email is to see how others are doing with regards to X2. Overall I would say it is worth it for someone to upgrade his client side modem to X2. Our tests show 45-50K connections on a fairly consistent bases and about a 50-70% improvement in overall Net performance. We have seen one problem that I hope others can help verify. Mindspring also is experiencing this problem as it was in the dcom.modem newsgroup. We are having roughly 10% of our calls being disconnected with the reason according to the TC Hub of 'retransmit limit exceeded'. Mindspring in the dcom.modem newsgroup also is having roughly 10-12% of this same disconnect problem and are not upgrading to X2 in their other pops until they resolve this problem with USR. Has anyone else experienced this and is their any rep from USR moderating this group that can shed some light on this...thank you -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Rick <rallan@monmouth.com> writes: > Mindspring also is experiencing this problem as it was in the > dcom.modem newsgroup. We are having roughly 10% of our calls being > disconnected with the reason according to the TC Hub of 'retransmit > limit exceeded'. Mindspring in the dcom.modem newsgroup also is having > roughly 10-12% of this same disconnect problem and are not upgrading to > X2 in their other pops until they resolve this problem with USR. Has > anyone else experienced this and is their any rep from USR moderating > this group that can shed some light on this...thank you Get your customers to upgrade to the latest client code (3/21/97) and the problem should disappear. The code was just placed onto the USR update server late this past weekend, and the update wizard available from the USR site can update an existing x2 flash modem. Alternatively, I would recommend disabling selective reject on your hub modems (it's configurable per modem in the signal group (mdmSc) of the MIB) until your clients have upgraded. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

> For me, reading DataCom's labtest review of the Ascend MAX caving in with > only 16 connections made me decided against the Ascend. That and their > incessant marketing blather (I receive more junk from Ascend than anyone > else). Same here - everyone we talked to (except the Ascend dealer) told us of performance and code stability problems on the Ascend. Price was horrendous. > The reason I decided against the Livingston is that I couldn't find any > reviews/tests of it anywhere We couldn't even get Livingston gear here, and even when we can (RSN) we would be one of the first guinea pigs in Australia with one. Not a comfortable situation. Pricing was OK. Cisco - didn't trust their Microcom modems after hearing of everyone's problems with the modem code and the new IOS features. I like IOS though. So, we went USR. We love their modems, although their 'personalised' version of Livingston's ComOS both comforted us and worried us at the same time. It was modem stability that was most critical to us at the time, and we've most definitely achieved that. V.FC support was also important. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

At 04:35 PM 4/3/97 -0600, you wrote: >On Wed, 2 Apr 1997 kjohnson@usr.com wrote: > >> On 3-25-97 @ 9:05pm, Tom Bilan wrote: >> > Also, the TC is returning the property #26 and it isn't defined >> > in the radius dictionary file. I even downloaded the latest radiusd >> > and dictionary file. I tried adding it in myself and it didn't >> > return anything that made sense to me. I tried changing the value >> > to type string, ipaddr, integer and date. >> > > >so can USR give all of us a dictionary, that say any UNIX radius can read, >complete with ALL the USR attributes? > >I did get a dictionary from USR once, it was missing many of your common >Radius attributes such as Port-Type and Port-Limit..........it did have >USR attributes tho..... > >what i need is for USR to put together a list of ALL attributes understood >by the TCE hub....... > >Brian > AND... Why do all the sessions end in lost carrier whether we 'reset S5', the customer clicks disconnect or they drop carrier because of "problems". Tom

> We currently have 24 USR Total Control racks, each with 48 ports, chan T1 > card, NMC, NetServer, the works. 4 of them are the new Enterprise Hubs (with > the dual power supplies), and a majority have single-sided modems (although > some of the older ones have double-sided). All of the racks authenticate > via radiusd 2.4.21. > > Recently, almost randomly, some of our users when they dial in get a > "Host Unavailable" message when they try to send their username and then > it promplty hangs up. Is that Radius 2.4.21 the Merit Radius, or another? I remember hearing recently about a bug in Merit Radius where under high load it could fail to keep up and cause this sort of problem. It was most prevalent after some type of system outage where users were typically dialling in on all ports simultaneously. I don't recall where I heard it, but I do remember seeing a patch. Sorry I can't be more helpful. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> I don't understand why when I buy a device from USR, I need to upgrade > it in 4 different places. Personally, I like it that way. I know if I update the NMC or NETServer card software I'm not going to cause any modem connection problems. I can update modem firmware card by card if I wish, so I can try it on 4 modems out of the entire rack before I commit the whole rack. Unlike Ascend, where one bit of software does everything. I heard recently about the OSPF code that broke the modems. The fix for the modems then broke the OSPF code again, and so on. Can you upgrade just a few modems at a time as a trial? > When I upgrade a Max I just upgrade it once and I'm done. Provided the update works. One of the primary reasons we avoided Ascend, other than price and performance, was because of the 'release of the week' approach to their software. > What really pisses me off though is USR's policy with support. You > do get 90 days free support, but you have to call support and wait for > hours for them to mail you the upgrade that you should have had installed > in the chassis in the first place. Can't speak for the US, but our racks came with the latest firmware installed. The tech support has been good on the occasions we've used it. Can't complain, unlike some other vendors I've dealt with. > I can't download it cause I don't have a support contract. I need to > call support to have them email it to me, and then they of course > email me the wrong version so I have to go through this 3 or 4 times. Don't have those problems here in Oz. Sure, you need a contract to get new code, but we have no problem getting what we need from the local people. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

What type of authentication are you using? If you're using tacacs you should check your tacacs logs and/or the logs for the comm servers you use, whether they are netserver or cisco 2511s or what. If you use tacacs let me know and I'll tell you a few things we found. Thanks, Ray Kopp Syracuse Unviersity Computing and Media Services Network Systems rjkopp@mailbox.syr.edu On Thu, 3 Apr 1997, Jim Klossner wrote: > We currently have 24 USR Total Control racks, each with 48 ports, chan T1 > card, NMC, NetServer, the works. 4 of them are the new Enterprise Hubs (with > the dual power supplies), and a majority have single-sided modems (although > some of the older ones have double-sided). All of the racks authenticate > via radiusd 2.4.21. > > Recently, almost randomly, some of our users when they dial in get a > "Host Unavailable" message when they try to send their username and then > it promplty hangs up. Has anyone ever seen this before or know what might > cause it? Because there are so many racks, and because this problem seems > totally random (I don't ever seem to get it, and by the time the helpdesk > calls me to complain, it's all gone) I'm having a heck of a time debugging > what could cause it. All the NetServers can ping the boxes and don't lose > network connectivity (we can tell via some monitoring programs we have > written) when this occurs. Can anyone tell me at least a starting point > for this, what to check for? All the settings across the racks should be > identical (we have an expect script to set them up) and we've never had > a problem in the past with those settings. > > -jkk > > -- > Jim Klossner - jkk@frontiernet.net http://www.frontiernet.net > Frontier Internet Operations and Administrative Center > (716) 777-8745 >

Oops, sorry I guess I didn't read the post enough. I see you said you use radius. Whatever the case if your server resides elsewhere it may be reachability issues with periodic network problems or server load problems. We tried to use tacacs on a Sun workstation using it through inetd rather than as a standalone daemon and it did exactly what you said, only alot more. When we made it standalone, we still would get some of these if the server was busy (sometimes multiple processes got spawned on the server and they never went away thus pigging up the CPU). Thanks, Ray Kopp Syracuse Unviersity Computing and Media Services Network Systems rjkopp@mailbox.syr.edu

Quoted from David Bolen: > > The Host Unavailable would indicate that the NETServer attempted to > connect somewhere and failed. You don't mention what the service > model is, but you don't generally see this with SLIP/PPP but only with > telnet/rlogin/portmux sort of services. This is for ppp service. > I know you indicated that all the units were configured identically, > but you might want to verify that all of your ports have security > enabled. If they don't, and a user hits that port, it will revert to > automatically making a connection (telnet I think) to the global or > port host list, which is probably all 0.0.0.0 in your config, assuming > a PPP service. In such a case, it won't be able to reach the > "0.0.0.0" host and will generate such a message. Acutally I think this might what it is. I took your suggestion below and made the welcome message tell the user what rack/modem it was. This afternoon I had 2 modems (on two separate racks) reported to me, and both of the modems did not have security enabled on them. I hope that this is the solution to it :) > I would certainly suggest seeing if your helpdesk can obtain any > banner information from your NETServer from the customer - depending > on the package they may be able to pop up a log window showing the > login sequence. If that's the case, and if you have port information > in your banner it'll probably help identify the point where they > entered the system. Then, the NETServer syslogs or any accounting > daemon logs would be a logical place to check, as well as your > authentication daemon logs to see if any requests were even made. > > If not, then perhaps just crunching your NETServer syslogs to try to > find callers that failed to make a PPP connection could help focus > attention. True, there will be a possible SNR problem in the logs due > to "normal" failures, but some patterns may jump out. Unfortunatly, because the rack never contacts the radius server (I think that's where it's getting the "host unavailable" from), I don't have any radius accounting reports to look at. The banner suggestion though I did use. I guess the users get the following: Welcome to Frontier Internet login: Host Unavailable <click> Therefore, I just made each port report it's rack and modem in the welcome message. Thanks for everyone's help. I hope I have this beat. -jkk -- Jim Klossner - jkk@frontiernet.net http://www.frontiernet.net Frontier Internet Operations and Administrative Center (716) 777-8745

Jim Klossner <Jim_Klossner@frontiernet.net> writes: > I had 2 modems (on two separate racks) reported to me, and both of the modems > did not have security enabled on them. I hope that this is the solution > to it :) Sounds like time to walk all of your NETServers and check for this, and add it to your automatic configuration script if it isn't already there. :-) > Unfortunatly, because the rack never contacts the radius server (I think > that's where it's getting the "host unavailable" from), I don't have > any radius accounting reports to look at. The banner suggestion though > I did use. The only way that you'll get the "Host is currently unavailable" message if the RADIUS authentication server is involved is if the RADIUS server returned a target address for a telnet/rlogin/portmux user that was unreachable. I don't think it can happen with a framed user at all. So checking the logs can eliminate the Failures of authentication (either a reject from the server, or if the NETServer can't reach the server at all), will show up to the user as "Invalid login" not "Host unavailable" That's why I mentioned the NETServer syslogs though, since they'll reflect the attempt to login even if the RADIUS server is never contacted. Actually, I guess I thought the RADIUS accounting server to get stuff in any case, but then again, maybe it only generates Start/Stop records for successful sessions - I don't currently use an accounting server myself yet in production so I'm less familiar with that path. > I guess the users get the following: > > Welcome to Frontier Internet > > login: Host Unavailable > <click> I haven't done this in a while, but actually, unless the port itself is defined to be an automatic telnet/rlogin to a defined host, I believe your users should get both the login: and Password: prompts. Oh, unless they're using PAP in which case the authentication will be recognized right at the login: prompt. That's so the NETServer can check the local users table first. But upon not finding a local users table entry, and the port not being set to security, it will then switch to using the local port or global host list automatically. So the login probably looks like: Welcome to Frontier Internet login: xxx Password: yyy *** Host is currently unavailable *** (minus the Password: prompt for PAP) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

We currently have 3 TC-Hubs working fine with our Bell Atlantic's DMS100 switches. However today we were unable to get a new one working with Bell Atlantic's AT&T 5ESS switch. Can someother users out there that have it working with Bell Atlantic's 5ESS switch give some advice on any problems they had. We had a conference call today for over 3 hours with ourselves , Bell and USR and were unable to resolve it. Bell blamed USR and USR blames bell.........:> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Rick said once upon a time: > >We currently have 3 TC-Hubs working fine with our Bell Atlantic's DMS100 >switches. However today we were unable to get a new one working with >Bell Atlantic's AT&T 5ESS switch. Can someother users out there that >have it working with Bell Atlantic's 5ESS switch give some advice on any >problems they had. We had a conference call today for over 3 hours with >ourselves , Bell and USR and were unable to resolve it. Bell blamed USR >and USR blames bell.........:> Are you using DSS or PRI services? My experience with DSS and 5ESS states that the "DNIS numbers received" has to MATCH what the phone company is sending you. Otherwise you're going to get an early pickup and the 5ESS seems to hate that. The DMS100 doesn't care. For your reference, these settings are accessible via TCM by selecting the modem(s), then going into "Programmed Settings" "Call Control Options" and then "DNIS-Based Incoming Call Digits". I think the 5ESS default is 4. Yes, I went to hell and back to resolve this with US West.

One of my techs discovered this the other day: Brev Patterson said once upon a time: > Just looking at slc1-snmp (the rest seem about the same), this is >what it looked like: > >UDP In Datagrams = 1347723 >UDP Out Datagrams = 9524 >UDP No Ports = 1338751 (Total number of received UDP datagrams for > which there was no application at the > destination port.) >UDP In Errors = 0 (Number of received UDP datagrams that could > not be delivered for reasons other than the > lack of an application at the destination > port.) > > > The numbers just seem strangely one-sided.. 95% of In Datagrams >were errors? > >| Brev Patterson >| brevp@xmission.com, bpatterson3@weber.edu >| http://www.xmission.com/~brevp >| Karl Malone for '97 NBA MVP -- Pete XMission

What is the spec on Netserver RAM? Can I upgrade to a 16meg Netserver simply by putting in a 16meg SIMM? -- Pete XMission

Pete Ashdown <pashdown@xmission.com> writes: > What is the spec on Netserver RAM? Can I upgrade to a 16meg Netserver > simply by putting in a 16meg SIMM? It depends on the base model of the NETServer. If you have the older version then it comes with 4MB of memory on the board itself, and if you ordered it as an ISDN card it has a 4MB SIMM for a total of 8MB. With that card, you always have the initial 4MB, but can replace the 4MB SIMM with a 8MB or 16MB SIMM. So on such a card to meet a 16MB requirement you actually end up going to 20MB, but yes that's a simple SIMM replacement. These cards show up as a "uchasAccessServer" or "uchasISDNGatewayNAC" via the management path (not sure how TCM displays it) depending on whether it is outfitted with the ISDN daughtercard. A "version" command will show a "Standard" packet bus circuit. The newer NETServer cards (EPB or enhanced packet bus) come with 16MB of memory right on the card itself and an empty SIMM, which can be used to increase memory higher. They show up via management as a "uchasEnhancedAccessServer" or "uchasEnhancedISDNGatewayNAC" depending on whether or not they are outfitted for ISDN with the daughter card. A "version" command will show an "Enhanced" packet bus circuit. -- David

Pete Ashdown wrote: > > Rick said once upon a time: > > > >We currently have 3 TC-Hubs working fine with our Bell Atlantic's DMS100 > >switches. However today we were unable to get a new one working with > >Bell Atlantic's AT&T 5ESS switch. Can someother users out there that > >have it working with Bell Atlantic's 5ESS switch give some advice on any > >problems they had. We had a conference call today for over 3 hours with > >ourselves , Bell and USR and were unable to resolve it. Bell blamed USR > >and USR blames bell.........:> > > Are you using DSS or PRI services? My experience with DSS and 5ESS states > that the "DNIS numbers received" has to MATCH what the phone company is > sending you. Otherwise you're going to get an early pickup and the 5ESS > seems to hate that. The DMS100 doesn't care. > > For your reference, these settings are accessible via TCM by selecting the > modem(s), then going into "Programmed Settings" "Call Control Options" and > then "DNIS-Based Incoming Call Digits". I think the 5ESS default is 4. > > Yes, I went to hell and back to resolve this with US West. Found out today that Bell gave us a bad trunk............what else is new ......old same ()*&^)^ from Bell Atlantic.... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

David Bolen wrote: > > Pete Ashdown <pashdown@xmission.com> writes: > > > What is the spec on Netserver RAM? Can I upgrade to a 16meg Netserver > > simply by putting in a 16meg SIMM? > > It depends on the base model of the NETServer. If you have the older > version then it comes with 4MB of memory on the board itself, and if > you ordered it as an ISDN card it has a 4MB SIMM for a total of 8MB. > > With that card, you always have the initial 4MB, but can replace the > 4MB SIMM with a 8MB or 16MB SIMM. So on such a card to meet a 16MB > requirement you actually end up going to 20MB, but yes that's a simple > SIMM replacement. > > These cards show up as a "uchasAccessServer" or "uchasISDNGatewayNAC" > via the management path (not sure how TCM displays it) depending on > whether it is outfitted with the ISDN daughtercard. A "version" > command will show a "Standard" packet bus circuit. > > The newer NETServer cards (EPB or enhanced packet bus) come with 16MB > of memory right on the card itself and an empty SIMM, which can be > used to increase memory higher. They show up via management as a > "uchasEnhancedAccessServer" or "uchasEnhancedISDNGatewayNAC" depending > on whether or not they are outfitted for ISDN with the daughter card. > A "version" command will show an "Enhanced" packet bus circuit. > > -- David We recently got in 4 TC PRI bundles and I don't think any of them have the newer card.....can you tell me what you mean by via management. Is there a way to tell the exact type using the TCM software? If not, what did you mean by management?(have to hook up to the NMC direct?)..........thankx for any reply -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Rick <rallan@monmouth.com> writes: > .....can you tell me what you mean by via management. Is > there a way to tell the exact type using the TCM software? If not, what > did you mean by management?(have to hook up to the NMC > direct?)..........thankx for any reply Sorry - I should have been clearer. I was referring to the object identifier value that would be returned to a query to the NMC of the uchasSlotModuleType as defined in the MIB. It just happens to be the first way I thought of to identify the different card types :-) Most of my interaction with TC hubs is via direct SNMP operations to the NMC card, so I'm not as familiar with how this information is displayed by TCM, which I haven't used in quite a bit. I expect that if you selected the slot and then asked for slot information (the same table that has the module version and description) would also display the NAC type. An alternative in this case is the version output I also described, which you can issue when logged into the NETServer as !root. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Pete Ashdown wrote: | What is the spec on Netserver RAM? Can I upgrade to a 16meg Netserver | simply by putting in a 16meg SIMM? standard 72pin no-parity 70ns 16mb works. (not edo!) you might want to use single sided simm as it lies flat against the MB. that reminds me, I have to buy some of those for 3.4.blah Peter ----* -- O_u \\ Ciscomancer // \\ Global OnLine Japan U \Beh! \\ Postmonster // Ukyu? \\ Engineering Dept.

--IMA.Boundary.647725068 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >since the netserver knows who's doing what, how about making this >information available by snmp. then we could just snmpwalk the >appropriate bits, see who's on what and perhaps use an snmp >write to boot off anyone who is on twice. Again, we're running into limitations on the current router core architecture; it's just taking time to overcome those limits. Look for enhanced SNMP management support in future releases of NETServer code. Until then, we're largely using RADIUS services to accomplish the resource management. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --IMA.Boundary.647725068 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 34367720; Thu, 3 Apr 97 02:16:50 -0600 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id CAA23206; Thu, 3 Apr 1997 02:18:47 -0600 (CST) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wCh0K-00025d-00; Thu, 3 Apr 1997 00:32:16 -0700 Received: from gol1.gol.com (gol1.gol.com [202.243.48.4]) by mail.xmission.com (8.8.5/8.7.5) with ESMTP id AAA07906 for <usr-tc@mail.xmission.com>; Thu, 3 Apr 1997 00:31:55 -0700 (MST) Received: (from peter@localhost) by gol1.gol.com (8.8.5/8.8.5) id QAA21637 for usr-tc@mail.xmission.com; Thu, 3 Apr 1997 16:31:51 +0900 (JST) Message-Id: <199704030731.QAA21637@gol1.gol.com> In-Reply-To: <34353C60.3000@usr.com> from "kjohnson@usr.com" at Apr 2, 97 10:05:24 pm Organization: Global Online - Engineering Dept. +81-3-5341-8000 X-no-archive: yes X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.647725068--

--IMA.Boundary.847725068 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part > is this functionality working? documented? Working? Yes; we have sites running it now, including a few LARGE installations. Documented? I believe so, in the NETServer v3.3 Command Reference and in the v3.3 User's Guide, although I will need to double-check to 100% confirm. >I got a Merit radius once from USR, it was 2.4.20 with USR extenstions, >severely hacked up.........it only partially worked..........it got rid of >all the "Vendor-Specific-Attribute" messages in my log files, by defining >proper attributes in the dictionary file, but alot of the util programs, >although they compiled, did not function. Yes, it was Engineering code simply to prototype the protocol negotiation for RADIUS Resource Management and for the VTP tunneling protocol. Unfortunately, Sales found it and started trying to sell the server code; it just goes to show that we need to hide things better from Sales. :) We are working on several fronts to include the Resource Management capability in several commercially-available RADIUS servers, as well as working with developers like Merit who make source code publically available. I'll ask someone to check into the source code Merit has posted to "confirm functionality" if a person simply compiled the source as-is. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --IMA.Boundary.847725068 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 344337E0; Thu, 3 Apr 97 16:47:26 -0600 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id QAA19464; Thu, 3 Apr 1997 16:49:25 -0600 (CST) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wCvCJ-0001uX-00; Thu, 3 Apr 1997 15:41:35 -0700 Received: from ns1.shreve.net (signal@ns1.shreve.net [208.206.76.2]) by mail.xmission.com (8.8.5/8.7.5) with ESMTP id PAA07064 for <usr-tc@mail.xmission.com>; Thu, 3 Apr 1997 15:40:27 -0700 (MST) Received: from localhost (signal@localhost) by ns1.shreve.net (8.8.5/8.8.5) with SMTP id QAA11851; Thu, 3 Apr 1997 16:40:16 -0600 cc: usr-tc@xmission.com, Laszlo Vecsey <master@internexus.net> In-Reply-To: <34353C60.3000@usr.com> Message-ID: <Pine.LNX.3.93.970403163815.11664G-100000@ns1.shreve.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.847725068--

>> >> April Fools day was yesterday. >> > but WAS it an April Fools joke? > Brian It was no joke, Brian. This is a limited-time, limited-quantity offer, but it's for real and it's for $299/port. Your USR reseller has the details on the program, if you're interested. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--IMA.Boundary.565835068 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Officially, the correct method of upgrading an older NETServer from current configuration to 16+ megs (all current shipping NETServers have 16+ megs on-board) is to purchase the USR Memory Upgrade Kit (80-002149-0) from your USR reseller. Unofficially, the NETServer requires a standard 72-pin personal computer SIMM, 70ns or faster, non-parity; we have had customers upgrade via parts from their favorite computer store under extreme situations. I would recommend that you purchase the Memory Upgrade Kit for two reasons: 1) we purchase the SIMMs from a known vendor and test them ourselves before packaging and shipping them, so quality issues are lessened, 2) the cost is basically identical to purchasing the SIMMs at your favorite computer store (we make $0.00 on the product), so unless you're a reseller and purchase SIMMs at huge discounts (larger than USR's purchasing power) you'll get the same price. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________ Reply Separator _________________________________ Author: Pete Ashdown <pashdown@xmission.com> at Internet What is the spec on Netserver RAM? Can I upgrade to a 16meg Netserver simply by putting in a 16meg SIMM? -- Pete XMission --IMA.Boundary.565835068 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 349596E1; Mon, 7 Apr 97 15:30:38 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id PAA05720; Mon, 7 Apr 1997 15:12:55 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wEJ9o-0001XW-00; Mon, 7 Apr 1997 12:28:44 -0600 Received: from slack.xmission.com (pashdown@slack.xmission.com [199.104.120.18]) by mail.xmission.com (8.8.5/8.7.5) with ESMTP id MAA05564 for <usr-tc@mail.xmission.com>; Mon, 7 Apr 1997 12:27:46 -0600 (MDT) Received: (from pashdown@localhost) by slack.xmission.com (8.8.5/8.7.5) id MAA08856 for usr-tc; Mon, 7 Apr 1997 12:27:38 -0600 (MDT) Message-Id: <199704071827.MAA08856@slack.xmission.com> X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.565835068--

--IMA.Boundary.965835068 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >These cards show up as a "uchasAccessServer" or "uchasISDNGatewayNAC" >via the management path (not sure how TCM displays it) depending on >whether it is outfitted with the ISDN daughtercard. A "version" >command will show a "Standard" packet bus circuit. >The newer NETServer cards (EPB or enhanced packet bus) come with 16MB >of memory right on the card itself and an empty SIMM, which can be >used to increase memory higher. They show up via management as a >"uchasEnhancedAccessServer" or "uchasEnhancedISDNGatewayNAC" >depending on whether or not they are outfitted for ISDN with the >daughter card. A "version" command will show an "Enhanced" packet bus >circuit. I would recommend using the "version" command from the console/CLI interface for any NETServer. Although it's software dependent, some of the releases have had problems with reporting erroneous information in the SNMP access requests, whereas the CLI is right 100% of the time (so far, anyway). Software versions that work include v3.2.6 and v3.3.3, or v3.3.28/3.3.37 and 3.4.23/3.4.33. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --IMA.Boundary.965835068 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 3499B390; Mon, 7 Apr 97 20:11:22 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id TAA14372; Mon, 7 Apr 1997 19:53:41 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wELbc-000529-00; Mon, 7 Apr 1997 15:05:36 -0600 Received: from interlock.ans.net (interlock.ans.net [147.225.5.5]) by mail.xmission.com (8.8.5/8.7.5) with SMTP id PAA19242 for <usr-tc@mail.xmission.com>; Mon, 7 Apr 1997 15:05:24 -0600 (MDT) Received: by interlock.ans.net id AA17361 (InterLock SMTP Gateway 3.0 for usr-tc@mail.xmission.com); Mon, 7 Apr 1997 17:04:09 -0400 Message-Id: <199704072104.AA17361@interlock.ans.net> Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 7 Apr 1997 17:04:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 7 Apr 1997 17:04:09 -0400 In-Reply-To: Your message of Mon, 7 Apr 1997 12:27:38 -0600 (MDT) Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.965835068--

Hi, all. I know maybe this kind of e-mail doesn't fall into this group but I think everybody know this kind of stuff so I try. There is several question on TCENH. 1. If my local network address is 1.1.1.0 and Netserver's ip is 1.1.1.20. Netmask is 255.255.255.0 and then I want to assign ip pool into 1.1.2.0. I had tried to set net0 routing on and set framed user routing on in Radius. But I couldn't ping 1.1.1.0 but only 1.1.1.20. Probably my knowledge on routing is wrong. What I thought was remote client should be connected with Netserver so when I tried to ping 1.1.1.30 then Netserver would forward into 1.1.1.30. Wrong? When I looked at Netserver's routing table, there was no gateway for client. i.e. if client ip was 1.1.2.30 then its gateway also 1.1.2.30. IMHO I can solve this problem to set default gateway in client's Radius file. Right? 2. I am so confused on PPTP and L2TP. The Internet Equal Access is based on PPTP or L2TP or what? I heard CCA is based on L2TP. To test CCA or CBA there is software for implemeting CCA in Netserver? 3. What is domain Radius? Where can I find on that? I mean how to set up in Windows and Unix each. Well, this time I think it is enough. Any help is much appreciated. From Seoul, Seob

On Wednesday, April 09, 1997 11:18 AM, Pete Ashdown wrote: > Rumor has it (or at least our rep told us) that the $15K rack is an older > version of the chassis. It can not accept the upcoming high-density (?) > cards and/or the IDSL/ADSL cards from USR. I was told exactly the same thing by our supplier. The price is definitely for "clearance" reasons.

Rumor has it (or at least our rep told us) that the $15K rack is an older version of the chassis. It can not accept the upcoming high-density (?) cards and/or the IDSL/ADSL cards from USR. Our rep stated that for the latest equipment, the price hasn't changed.

What are the advantages to the newer chassis? What is ISDL/ADSL? At 11:26 AM 4/9/97 -0000, you wrote: >On Wednesday, April 09, 1997 11:18 AM, Pete Ashdown wrote: >> Rumor has it (or at least our rep told us) that the $15K rack is an older >> version of the chassis. It can not accept the upcoming high-density (?) >> cards and/or the IDSL/ADSL cards from USR. > >I was told exactly the same thing by our supplier. The price >is definitely for "clearance" reasons. > > > > Thanks, Greg Coffey, CoffeyNet ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. Local Internet for Casper, Rawlins, Douglas, Casper, WY 82601 Wheatland, Pinedale, Lander & Lusk, WY http://www.coffey.com (307) 234-5443 ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

David Bolen said once upon a time: >The newer NETServer cards (EPB or enhanced packet bus) come with 16MB >of memory right on the card itself and an empty SIMM, which can be >used to increase memory higher. They show up via management as a >"uchasEnhancedAccessServer" or "uchasEnhancedISDNGatewayNAC" depending >on whether or not they are outfitted for ISDN with the daughter card. >A "version" command will show an "Enhanced" packet bus circuit. Is there any consideration that should be given into possibly upgrading to this card if we have the "Standard"?

Marcus Needham <marcus@theriver.com> writes: > I was told exactly the same thing by our supplier. The price > is definitely for "clearance" reasons. Hmm... it sounds like the "older" rack is the previous configuration without the integrated fan tray and clock on the backplane. It's my understanding (although I'm sure someone from USR will correct me if I'm wrong) that the high density cards will still work just fine in the older chassis, although you may or may not be able to install quite as many because of TDM bus limitations. Not sure about the xDSL stuff. -- David

On Wed, 9 Apr 1997, Marcus Needham wrote: > On Wednesday, April 09, 1997 11:18 AM, Pete Ashdown wrote: > > Rumor has it (or at least our rep told us) that the $15K rack is an older > > version of the chassis. It can not accept the upcoming high-density (?) > > cards and/or the IDSL/ADSL cards from USR. > > I was told exactly the same thing by our supplier. The price > is definitely for "clearance" reasons. > yep, its an older chasis without the high speed backplane. but a high speed backplane chasis only costs $3000.00 $15000.00 + 3000.00

On Wed, 9 Apr 1997, Marcus Needham wrote: > On Wednesday, April 09, 1997 11:18 AM, Pete Ashdown wrote: > > Rumor has it (or at least our rep told us) that the $15K rack is an older > > version of the chassis. It can not accept the upcoming high-density (?) > > cards and/or the IDSL/ADSL cards from USR. > > I was told exactly the same thing by our supplier. The price > is definitely for "clearance" reasons. > yep, its an older chasis without the high speed backplane. but a high speed backplane chasis only costs $3000.00 $15000.00 + 3000.00

Pete Ashdown <pashdown@xmission.com> writes: > Is there any consideration that should be given into possibly upgrading to > this card if we have the "Standard"? It's just my personal view, but it's probably not worth it. Don't be too misled by the use of "standard" and "enhanced." The newer cards do use a different circuit for the packet bus but when all is said and done it doesn't really perform all that differently. Since the cards are a newer generation, I do think the hardware platform itself is a bit of a better design, and the differences such as base memory on the board are nice, but probably not enough to be worth the cost of updating older cards. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Marcus Needham wrote: > > On Wednesday, April 09, 1997 11:18 AM, Pete Ashdown wrote: > > Rumor has it (or at least our rep told us) that the $15K rack is an older > > version of the chassis. It can not accept the upcoming high-density (?) > > cards and/or the IDSL/ADSL cards from USR. > > I was told exactly the same thing by our supplier. The price > is definitely for "clearance" reasons. Can someone from USR please help clarify this ....??? thank you -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

David Bolen wrote: > > Marcus Needham <marcus@theriver.com> writes: > > > I was told exactly the same thing by our supplier. The price > > is definitely for "clearance" reasons. > > Hmm... it sounds like the "older" rack is the previous configuration > without the integrated fan tray and clock on the backplane. > > It's my understanding (although I'm sure someone from USR will correct > me if I'm wrong) that the high density cards will still work just fine > in the older chassis, although you may or may not be able to install > quite as many because of TDM bus limitations. > > Not sure about the xDSL stuff. > > -- David Dave, can you clarify what you mean by older chassis?? We recently purchased 5 PRI bundles about 2 months ago and I want to make certain that we did not get stuck with old chassis.....what can I look for to determine if I have the newer or older chassis??? thank you -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

We just got another /24 from UUNET, which we would like to have our USR Total control server utilize as its assigned ip pool. USR TC is 208.206.76.15 I added the following to our router (208.206.76.1) ip route 208.214.44.0 255.255.255.0 208.206.76.15 then on the USR TC I did add route 208.214.44.0/24 208.206.76 15 1 set assigned 208.214.44.1 This DOES assign them IP's from the new /24 (208.214.44.0) but does NOT create the routes. If i do "set assigned 208.206.76.100" to put things back the way they were before, then everything works just fine. does the usr have to have an ip on the same /24 as its assigned ip pool? what could I be doing wrong? 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

I was reseaching a routing problem of my own (NT servers, argh) and I stumbled upon this in the archives: >Has anyone been able to get something like this to work? > >signal Authentication-Type = Unix-PW > Service-Type = Framed, > Framed-Protocol = PPP, > Framed-IP-Address = 208.206.76.90, > Framed-IP-Netmask = 255.255.255.0, > Framed-Routing = None, > Framed-Route = "208.206.76.91/32 0.0.0.0 2", > Framed-MTU = 1500, > Framed-Compression = Van-Jacobson-TCP-IP > >Just want to route 2 IP's to the customer and that is all.............cant >seem to get anything written to the route table. If you are trying to route two IP's, I don't see it. You've got two conflicting subnets in the above statement. That is: 208.206.76.90 255.255.255.0 overlaps 208.206.76.91 255.255.255.255 If you want to route two IPs to a customer, it is better to make a subnet of size 4, or mask 255.255.255.252. This would give your client two useable IPs, 208.206.76.91 and 208.206.76.92. 208.206.76.90 is the subnet number and the 208.206.76.93 is the broadcast. The entry above would then look like: signal Authentication-Type = Unix-PW Service-Type = Framed, Framed-Protocol = PPP, Framed-IP-Address = 208.206.76.91, Framed-IP-Netmask = 255.255.255.252, Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP However, for any subnets that are not host routes (255.255.255.255) or class routes (255.255.255.0, 255.255.0.0, etc), you need to be running RIPv2 on your Netserver, and RIPv2 on your upstream router. With a Cisco, this needs to be version 11.1 or higher. Then the trick to turn on RIPv2 routing on a Netserver looks like this: set ripv2 on set net0 routing broadcast Or replace net0 with your frame interface if you aren't routing out the ethernet. This works great for us. What I have to figure out now is how to route one subnet through another for NT's braindead routing. -- Pete XMission

Hoo boy, Brian was right. After sitting on hold for 45 minutes with USR tech support, I eventually landed with a person who barely knew what routing was. The problem with NT is that it requires two subnets to route one. Like this: (TC) --> (NT RAS) -> (NT network) Instead of normal routing which looks like this: (TC) --> (Network) So we assign a 255.255.255.255 subnet to the RAS connection (just so we don't waste anything), and then try to route the NT netowk through that subnet with a Framed-Route. This is what my RADIUS entry looks like user Authentication-Type = Unix-PW Framed-IP-Address = 207.135.128.10, Framed-IP-Netmask = 255.255.255.255, Framed-Route = "166.70.32.224 207.135.128.10 1" (The defaults such as Framed-Protocol are filled in later.) This works, but the problem lies in that the mask for 166.70.32.224 is always setup as a class C. In this case, it is a /28. Now, if you change the attribute to look like this (as previously suggested): Framed-Route = "166.70.32.224/28 207.135.128.10 1" The Netserver ignores the attribute and no route is setup. The genius who I was on the phone with at USR kept telling me that I should use the "Framed-IP-Netmask" for this, and I kept telling him that this wasn't the netmask I was concerned about. That netmask sets up just fine. So he left the phone for a few minutes and then came back to tell me that there was a "Framed_Route_Netmask" attribute in the latest dictionary of USR's RADIUS server. Well, I suspected this was a wrong answer, and it turned out to be that way. There is no such attribute. Do any of you USR dark-hearts have an answer to this? -- Pete XMission

Is there any way to reset the NMC "private" password if you forget it? (without wiping the entire config) Is there a way to extract it via TCM? also this is interesting, if you do snmpwalk nmc.ip.number public_password returns snmp info snmpwalk nmc.ip.number private_password returns snmp info nothing new here, but whats wierd is snmpwalk nmc.ip.number '' .............returns snmp info! 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

At 12:44 PM 4/12/97 -0400, you wrote: >Where can I get the latest radius/development sources? > ...and Access routines that are useful. Do we have to invent them all ourselves?

Where can I get the latest radius/development sources?

is anyone using the NMC's radius accounting abilities under a unix radius such as merit? I have on my NMC card, Logging Group:all, Logging Server:Primary, and the logging server ip and port set. I also hacked in the NMC_ATTRIB's into my merit dictionary from the USR ACCDICT.DAT. I dont see the nmc trying to connect to the server though. What could be wrong? I set a secret on the nmc, saved, did a restart, added the nmc to my clients file..............anyone got this working, it has the ability to track some interesting info , including connect speed. 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

There are more than a couple of developmental efforts for RADIUS servers, but you can get good, stable RADIUS source from Livingston's ftp site, ftp.livingston.com.

On Sat, 12 Apr 1997, Mark R. Lindsey wrote: > There are more than a couple of developmental efforts for RADIUS > servers, but you can get good, stable RADIUS source from Livingston's > ftp site, ftp.livingston.com. I've been using the radius 1.16 from there for some time now, however I am looking to use the new features that are available in the more recent versions that I can't seem to find. Some previous posts on this mailing list mention version numbers like 2.4.20.. with USR extensions and hacks. Where are these other distributions being maintained? - lv

Did you ever get an answer to this? I was gone during the thead and haven't seen any responses yet. I too would be interested in this info. At 06:59 PM 3/26/97 -0700, you wrote: >Does anyone know what the new "ISDN Modem" added cost feature does? I >noticed this after upgrading to X2. Will it allow me to do 56K ISDN >signaling over a channelized T1 (oh, please!)? > >-- >Pete >XMission > > Greg Coffey CoffeyNet Internet Service Provider for: Casper, Pinedale, Douglas, Wheatland, Rawlins, Lander & Lusk Wy HTTP://www.coffey.com 307-234-5443

How do I log all the cool stuff via NMC/RADIUS? I have NMC logging set to "all", the primary server set, ip set, port etc. I have the secret configured in the nmc and raadius server. I cant get it to log anything more than: Sun Apr 13 19:00:08 1997 NAS-IP-Address = 208.206.76.16 NAS-Port = 1 Acct-Delay-Time = 12 Acct-Session-Id = 743 Vendor-Specific = Vendor-Specific = Vendor-Specific = Vendor-Specific = Acct-Status-Type = Start That's it, all I get. Do I have to ADDITIONALLY go set up traps on the modems or other hardware, in order for attributes like TX-Connect-Speed etc to be logged? I did set every attribute on one modem to "enablelog" and still got nothing but the above. anyone doing this? 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

Just recently got a second PRI line activated, and they both function fine with the original 6 DS quads that this total control kit came with. The other 6 SS quads I added are being ignored; I've added them through the DualPRI console as being in their respective slots, but calls are just not being taken by them.. they just get routed in sequence to the original six (older) DS quads. Any ideas? I'm running the latest code possible on all cards.

On Sun, 13 Apr 1997, Laszlo Vecsey wrote: > Just recently got a second PRI line activated, and they both function fine > with the original 6 DS quads that this total control kit came with. The > other 6 SS quads I added are being ignored; I've added them through the > DualPRI console as being in their respective slots, but calls are just not > being taken by them.. they just get routed in sequence to the original six > (older) DS quads. > > Any ideas? I'm running the latest code possible on all cards. > did you set them active from the netserver? 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

> On Sun, 13 Apr 1997, Laszlo Vecsey wrote: > > > Just recently got a second PRI line activated, and they both function fine > > with the original 6 DS quads that this total control kit came with. The > > other 6 SS quads I added are being ignored; I've added them through the > > DualPRI console as being in their respective slots, but calls are just not > > being taken by them.. they just get routed in sequence to the original six > > (older) DS quads. > > > > Any ideas? I'm running the latest code possible on all cards. > > > > did you set them active from the netserver? > Do you mean the Sxx ports? They're all configured the same way, and active. I've even pulled out all the 6 old quads and placed the new ones in the same exact slots that the old ones were in; they dont respond. :( - lv

Do you have the cards set up to receive calls from the PRI or from the NIC... You can check this in the Total Control Manager. I forget which option, but you select the modem on the card. It's the LAST option on one of the configure menus... If you don't have total control manager, connect to each of your modems and send the at%d2 command. That will enable them to take calls from the PRI... Also, the option at the bottom of the menu should have reference to %dx or something like that... If you have the manager, you know how they list the at command next to the option... Check it out... Let me know...

> Do you have the cards set up to receive calls from the PRI or from the > NIC... You can check this in the Total Control Manager. I forget which > option, but you select the modem on the card. It's the LAST option on > one of the configure menus... If you don't have total control manager, > connect to each of your modems and send the at%d2 command. That will > enable them to take calls from the PRI... > That was it.. it was set to t1, not pri! Thank you so much. > Also, the option at the bottom of the menu should have reference to %dx or > something like that... If you have the manager, you know how they list > the at command next to the option... >

At 05:35 PM 4/14/97 -0400, you wrote: >Has anyone encountered these symptoms? Takes some x2 users a bunch of >times to connect, and when they do its at 48k. Could this be because most >of the lines at the switching station(s) are analog, or have conversions, >and only some of them are digital.. so its a hit or miss situation? > -----------snip We experience a 60 second time interval to log in at 56k for the handshake to complete. If we log in to the same modem with a 28.8k modem, the time is only about 10 seconds. We are only getting 40-44k transmit speeds. Don't know how much to blame US West. We've had a trouble ticket going on it with USR for over a month.

Has anyone encountered these symptoms? Takes some x2 users a bunch of times to connect, and when they do its at 48k. Could this be because most of the lines at the switching station(s) are analog, or have conversions, and only some of them are digital.. so its a hit or miss situation? I have a couple users that dial up and are assigned an IP address, say ppp53. When I 'show session' it doesn't show up as ppp53.domainname.com, but simply ppp53 for some reason. I can't ping it, and when I show the 'Sxx' port they're logged into it has hundreds of Framing Errors; Bad CRC. I'm not sure if this is related to ppp in modem yet, haven't tested. I'm running 3.3.28 on the netserver. Is any of this fixable in the Total Control? My local phone company switch? Is this just a side affect of x2, which wont be resolved until almost all the phone switches go digital? In any case I'm curious as to why the hostname would show up differently from users who are connected normally. Also, it seems this user always seemed to be assigned ppp53, where as when I dialed up with his account I would get a random pppXX like usual. I guess its related to the framing errors.. and the x2 connection. Whats the AT command to disable x2 on their sportsters/couriers? - lv

faulkner@montrose-colo.com (Jim Faulkner) writes: > We experience a 60 second time interval to log in at 56k for the handshake > to complete. If we log in to the same modem with a 28.8k modem, the time is > only about 10 seconds. (...) Hmm - there's really no reason to see that kind of difference. In my experience training at x2 is about equivalent to V.34 (I haven't clocked it recently but at least within a second or two). Wait, I just ran a test call - 12s from remote modem answering to CONNECT message. About the only thing that I can think of that could create such a difference in training time is if the modem has to retrain more than once during the initial training sequence, which could be indicative of line noise or problems with the two modems communicating. However, a retrain is only about another 7-8s, so you'd really have to be retraining to get to 60s, and in most cases such a high rate of retraining should bump you back down to V.34. It might be useful to either call in with a client modem with M2, to leave the speaker on. That way you can hear any retraining going on even if it occurs just after the modem displays a CONNECT message (and normally shuts the speaker off). You can also check the ATI6 counters on the client modem and the statistics table on the hub modem after the connection has succeeded. I'm presuming that by the handshake completing you are referring to the point at which the modem is transferring data, and not anything involving a login to a terminal server (or NETServer) or PPP negotation or anything, right? > Don't > know how much to blame US West. Well, if the problem are actually due to line conditions on your digital circuit, or equipment servicing it then of course they can come into play. If the problems are on the local loop of the caller or callers then it depends how much you can get them to do since using x2 requires more from a line than a telco is really required to give. You might try calling into other x2 numbers from the same client line in order to take one of the two sides out as a variable - if the behavior is the same it is more likely the client line but if it works well, then you might want to investigate your end. Oh, and I would of course verify that both ends are using the latest code available, since changes and bug fixes are constantly underway. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Now that I've upgraded to 3.4.23 and 16 megs of RAM, the UDP problems I was having with an MTU of 1500 are no longer present. FYI -- Pete XMission

Did you upgrade from the "standard" netserver card to 3.4.23 or did you get the newer enhanced netserver card? I have been unable to upgrade from 8MB to 16MB and to 3.4.23. Should I be able to do this with the the standard netserver card? Corey Piggott Infinet Network Engineering On Tue, 15 Apr 1997, Pete Ashdown wrote: > Now that I've upgraded to 3.4.23 and 16 megs of RAM, the UDP problems I was > having with an MTU of 1500 are no longer present. FYI > > -- > Pete > XMission >

Did you upgrade from the "standard" netserver card to 3.4.23 or did you get the newer enhanced netserver card? I have been unable to upgrade from 8MB to 16MB and to 3.4.23. Should I be able to do this with the the standard netserver card? Corey Piggott Infinet Network Engineering On Tue, 15 Apr 1997, Pete Ashdown wrote: > Now that I've upgraded to 3.4.23 and 16 megs of RAM, the UDP problems I was > having with an MTU of 1500 are no longer present. FYI > > -- > Pete > XMission >

Corey Piggott said once upon a time: > > >Did you upgrade from the "standard" netserver card to 3.4.23 or did you >get the newer enhanced netserver card? > >I have been unable to upgrade from 8MB to 16MB and to 3.4.23. Should I be >able to do this with the the standard netserver card? Here's my version information: U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.4.23 Build date: Mar 6 1997 Build time: 10:12:26 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Standard Licensed for 60 ports. So I guess I'm "standard".

Brian said once upon a time: >When you upgrade the OS on the Netserver card, do you loose your >configuration? If so, is there a way to store it first then reload it >verbatum? No, the configuration stays. In any case, I keep a file of common configuration commands for my Netservers. So all I need to do when I set a new one up is cut-n-paste, then fill in the specifics. Makes keeping track of undocumented configuration parameters easy.

On Tue, 15 Apr 1997, Corey Piggott wrote: > > Did you upgrade from the "standard" netserver card to 3.4.23 or did you > get the newer enhanced netserver card? how can you tell the diff between a standard and enhanced netserver card? When you upgrade the OS on the Netserver card, do you loose your configuration? If so, is there a way to store it first then reload it verbatum? > > I have been unable to upgrade from 8MB to 16MB and to 3.4.23. Should I be > able to do this with the the standard netserver card? > > Corey Piggott > Infinet Network Engineering > > On Tue, 15 Apr 1997, Pete Ashdown wrote: > > > Now that I've upgraded to 3.4.23 and 16 megs of RAM, the UDP problems I was > > having with an MTU of 1500 are no longer present. FYI > > > > -- > > Pete > > XMission > > > 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

On Tue, 15 Apr 1997, Corey Piggott wrote: > > Did you upgrade from the "standard" netserver card to 3.4.23 or did you > get the newer enhanced netserver card? how can you tell the diff between a standard and enhanced netserver card? When you upgrade the OS on the Netserver card, do you loose your configuration? If so, is there a way to store it first then reload it verbatum? > > I have been unable to upgrade from 8MB to 16MB and to 3.4.23. Should I be > able to do this with the the standard netserver card? > > Corey Piggott > Infinet Network Engineering > > On Tue, 15 Apr 1997, Pete Ashdown wrote: > > > Now that I've upgraded to 3.4.23 and 16 megs of RAM, the UDP problems I was > > having with an MTU of 1500 are no longer present. FYI > > > > -- > > Pete > > XMission > > > 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

At 05:02 AM 4/15/97 -0600, you wrote: >Now that I've upgraded to 3.4.23 and 16 megs of RAM, the UDP problems I was >having with an MTU of 1500 are no longer present. FYI What was the problem ? We have a customer who is having a problem dialing into a USR hub with a P50 where the USR negotiates an MRU/MRRU of 1500. When the P50 sends a 1500 byte frame with the MP/PPP header, the USR doesn't acknowledge receiving it. The same setup works with the Ascend MAX *and* the Livingston PM3.... Could this be related to your problem ? Kevin Smith Updated Service and Support Customer Satisfaction Resources are now at: Ascend Communications http://www.ascend.com/service

Where is one supposed to find the MPIP UNIX server that is mentioned in the Netserver 3.4 release notes?

Kevin Smith said once upon a time: >>Now that I've upgraded to 3.4.23 and 16 megs of RAM, the UDP problems I was >>having with an MTU of 1500 are no longer present. FYI > >What was the problem ? > >We have a customer who is having a problem dialing into a USR hub with a P50 >where the USR negotiates an MRU/MRRU of 1500. When the P50 sends a 1500 byte >frame with the MP/PPP header, the USR doesn't acknowledge receiving it. The >same setup works with the Ascend MAX *and* the Livingston PM3.... > >Could this be related to your problem ? I didn't delve into it that deeply. The problem was that simple UDP stream tests with "netperf" repeatedly failed when they were sent out the USR TC hub. Changing the MTU size to something smaller like 1002 solved the problem. With 3.4.23, "netperf" does UDP streams flawlessly. I hammered it with a variety of tests and didn't have any problems.

On Tue, 15 Apr 1997, Pete Ashdown wrote: > Corey Piggott said once upon a time: > > > > > >Did you upgrade from the "standard" netserver card to 3.4.23 or did you > >get the newer enhanced netserver card? > > > >I have been unable to upgrade from 8MB to 16MB and to 3.4.23. Should I be > >able to do this with the the standard netserver card? > > Here's my version information: > > U.S. Robotics > Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.4.23 > Build date: Mar 6 1997 > Build time: 10:12:26 > > Network Interface Card: Ethernet & Frame Relay Combination (26) > ISDN Interface Card : MUNICH32 (4) > Packet Bus Circuit : Standard > > Licensed for 60 ports. > > So I guess I'm "standard". > U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.3.28 Build date: Dec 13 1996 Build time: 13:54:59 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Standard Licensed for 60 ports. hmm, me too. Am I missing anything by not going to 3.4.23? What were the major changes? 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

Brian said once upon a time: >hmm, me too. Am I missing anything by not going to 3.4.23? What were the >major changes? Did you plug in your SIMMs to upgrade your Netservers? Nothing should stop you past that point. According to one USR engineer, 3.4.23 is about "eight times" faster than prior versions.

On Tue, 15 Apr 1997, Pete Ashdown wrote: > Brian said once upon a time: > >When you upgrade the OS on the Netserver card, do you loose your > >configuration? If so, is there a way to store it first then reload it > >verbatum? > > No, the configuration stays. In any case, I keep a file of common > configuration commands for my Netservers. So all I need to do when I set a > new one up is cut-n-paste, then fill in the specifics. Makes keeping track > of undocumented configuration parameters easy. I backup my netserver configurations with the Netserver Manager. I keep the .ncf files on a file server so they get backed up daily and for security, because the passwords and secrets are in clear text. If a Netserver gets amnesia, I can set the IP and gateway and restore the config from disk. If *I* get amnesia, I have a copy of the Netserver password. I also have an interactive script in the terminal program on my laptop to configure a netserver from scratch via telnet or direct serial, a real time saver. Regards, Charles Hill ioNET Network Specialist

On Tue, 15 Apr 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >hmm, me too. Am I missing anything by not going to 3.4.23? What were the > >major changes? > > Did you plug in your SIMMs to upgrade your Netservers? Nothing should stop > you past that point. > > According to one USR engineer, 3.4.23 is about "eight times" faster than > prior versions. > Can I use normal PC Style simms? parity? edo? what do I need to order? 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

Pete Ashdown <pashdown@xmission.com> writes: > According to one USR engineer, 3.4.23 is about "eight times" faster than > prior versions. Hmm, that might be a little overly optimistic, but yes, the overall throughput supported by 3.4.23 (aggregate of all channels) is significantly faster than earlier versions. The performance of a single channel is also faster, but not anywhere near as much as the aggregate of all channels. -- David PS: You'll get more of a performance boost if you are using the newer 5.x.y modem code (even if not in x2 mode) since there was some major reworking of the packet bus code path. /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Are the Session-Timeout and Acct-Settion-Time radius dictionary entries the same? Also, my dictionary file does not have IP-Filter-In or IP-Filter-Out, does that mean I can't use them until I manually edit them in the dictionary file? Does support for these filter options also have to be hardcoded into radiusd? (I'm using 1.16 since I can't find source to anything more recent) Specifically I need to set a maximum session time on an account that exists in the netserver, not in my radius configuration. I'm using 3.3.28; is there a commandline option to do this? - lv

Laszlo Vecsey wrote: > > Are the Session-Timeout and Acct-Settion-Time radius dictionary entries > the same? Also, my dictionary file does not have IP-Filter-In or > IP-Filter-Out, does that mean I can't use them until I manually edit them > in the dictionary file? Does support for these filter options also have to > be hardcoded into radiusd? (I'm using 1.16 since I can't find source to > anything more recent) > > Specifically I need to set a maximum session time on an account that > exists in the netserver, not in my radius configuration. I'm using 3.3.28; > is there a commandline option to do this? > > - lv Try using set sx idle xx where x is the port number and xx is the timeout limit..... remember to reset the port after setting it.... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Do you guys know if there is a command line function that I can use to find out the modulation type of someone dialing in. Or even a connect speed?? The TCM is cool and all, but I'm a command line fool myself... Thanks for input..

Once upon a time Laszlo Vecsey shaped the electrons to say... >Is there a way to telnet to an Sxx port, and manually dialing out with AT >commands? I remember there being a small c program at ftp.livingston.com Set the port for service_device telnet [socket num] and set it for device /dev/network (or twoway /dev/network) Then you can telnet to the unit at that socket to connect to the port. Well, that's how PMs do it. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

On Wed, Apr 16, 1997 at 03:48:34PM -0700, MegaZone wrote: > Once upon a time Laszlo Vecsey shaped the electrons to say... > >Is there a way to telnet to an Sxx port, and manually dialing out with AT > >commands? I remember there being a small c program at ftp.livingston.com > > Set the port for service_device telnet [socket num] > and set it for device /dev/network (or twoway /dev/network) > > Then you can telnet to the unit at that socket to connect to the port. > > Well, that's how PMs do it. > Note that if you do this, *anybody* can telnet to that socket and control your modem. However, if you use port numbers 10000 - 10100, these are permanently filtered from the outside. Then there are two ways to get to the port. 1: Telnet to the box as !root, on the usual port 23. Then, from the ComOS command line, telnet back to the box itself with the socket port number you've assigned to that serial port. 2: Create a user in the user table for that port, with the "host" set to the box's IP address, and "service" set to "telnet 10xxx". Then you can log into the box with that username, and you'll be connected directly to the serial port. -- David Carmean <dlc@avtel.net> Avtel Communications, Santa Barbara, CA +1-805-730-7740 Opinions herein are those of the author only, unless otherwise noted

Is there a way to telnet to an Sxx port, and manually dialing out with AT commands? I remember there being a small c program at ftp.livingston.com that seemed to be standardized for this purpose, am I on the right track? - lv

On Wed, 16 Apr 1997, Joseph Jones wrote: > Do you guys know if there is a command line function that I can use to > find out the modulation type of someone dialing in. Or even a connect > speed?? The TCM is cool and all, but I'm a command line fool myself... > > Thanks for input.. If you have Tcl and scotty on your unix machine, you can use this scotty script. You have to specify the nmc's hostname and the port number the user is logged into (Sxx) without the "S". I had to prune it down because the original accepts a username as a parameter and relies on a proprietary utility to find the user's NAS name and port number. It will tell you the phone number they are calling from, their initial and current connect speeds (transmit AND receive), modulation type, and other goodies. You will need to copy the mdm.mib file from the TCM distribution and hardcode the path in the script. If you're read-only community string is not "public", you'll have to change that, too. -CH ------------modck-------------- #!/usr/local/bin/scotty -f # # scotty script to check the user's phone number and connect speed. # # Written by Charles Hill and Jason Lee for ioNET, Inc. # # Usage: modck <nmcname> <portnum> # # You must have Tcl and scotty installed for this script to work. # You'll have to modify these variables as necessary. set mibdir "/path/to/the/mibs" set community "public" # # This proc takes the octet stream, and looks for the word # INTEGER. It then strips the integer that follows. # proc stripnum {raw} { # ----- trim "garbage" from the raw string ----- set num1 [string first "R" $raw] # ----- extract modulation type number ----- set cooked [string range $raw $num1 end] scan $cooked "R %d" num return $num } # # This proc takes the octet stream, and looks for the word # INTEGER. It then strips the string that follows. This is # for the functions whose numeric return value is interpreted # by scotty. # proc stripstr {raw} { # ----- trim "garbage" from the raw string ----- set num1 [string first "R" $raw] # ----- extract modulation type number ----- set cooked [string range $raw $num1 end] scan $cooked "R %s" str return [string range $str 0 [expr [string length $str]-2]] } # # This proc will return the phone number of the customer, formatted # as ###-###-####. If caller ID is not available, either because # the calling number is not supplying it, or if the PRI does not # support, a message stating such is returned. # proc phoneno {raw} { set start [expr [string last "G" $raw]+4] set stop [expr [string length $raw]-3] set num [string range $raw $start $stop] if {![regexp $num " "]} { return [string range $num 0 2]-[string range $num 3 5]-[string range $num 6 9] } else { return "No caller ID available" } } # # This proc returns the call duration. It is formatted by scotty, # so the script merely strips leading spaces. # proc getcalldur {raw} { set start [expr [string last " " $raw]+1] set stop [expr [string length $raw]-3] set num [string range $raw $start $stop] return $num } # # Main program # set arg1 " " set arg2 " " set arg3 " " switch $argc { 0 { puts "Usage: modck nmcname portnum" exit } 1 { set nmc [lindex $argv 0] exit } 2 { set nmc [string tolower [lindex $argv 0]] set port [lindex $argv 1] } } if {$port > 52} { puts "This is an ISDN call. There are no modem stats" exit } # # ----- determine the slot and channel number ----- # incr port 3 set slot [expr $port / 4] set chan [expr $port % 4+1] set slotchan [format "%2d%3d" $slot $chan] regsub -all " " $slotchan "0" slotchan # # ----- open an snmp session to the appropriate mgt card ----- # mib load "$mibdir/mdm.mib" set session [snmp session -address $nmc -community $community] # # ----- retrieve user's inital receive rate ----- # set initialrx [stripstr [$session get "mdmCsInitialTxLinkRate.$slotchan"]] set initialtx [stripstr [$session get "mdmCsInitialRxLinkRate.$slotchan"]] set currentrx [stripstr [$session get "mdmCsFinalTxLinkRate.$slotchan"]] set currenttx [stripstr [$session get "mdmCsFinalRxLinkRate.$slotchan"]] set modtype [stripstr [$session get "mdmCsModulationType.$slotchan"]] set phnum [phoneno [$session get "mdmCsLastCallingPartyNum.$slotchan"]] set datacomp [stripstr [$session get "mdmCsCompressionType.$slotchan"]] set errorctrl [stripstr [$session get "mdmCsErrorControlType.$slotchan"]] set upshifts [stripnum [$session get "mdmCsUpshiftQty.$slotchan"]] set downshifts [stripnum [$session get "mdmCsFallbackQty.$slotchan"]] set charssent [stripnum [$session get "mdmCsCharsSent.$slotchan"]] set charsrcvd [stripnum [$session get "mdmCsCharsReceived.$slotchan"]] set blksrsent [stripnum [$session get "mdmCsBlocksResent.$slotchan"]] set blkssent [stripnum [$session get "mdmCsBlocksSent.$slotchan"]] set numnaks [stripnum [$session get "mdmCsLinkNakQty.$slotchan"]] set lnkblker [stripnum [$session get "mdmCsBlerQty.$slotchan"]] set retrnreq [stripnum [$session get "mdmCsRetrainsRequested.$slotchan"]] set retrngr [stripnum [$session get "mdmCsRetrainsGranted.$slotchan"]] set calldur [getcalldur [$session get "mdmCsCallDuration.$slotchan"]] # # ----- Output the user's information ----- # puts "============== NMC name: $nmc ===============" puts "Slot and Channel --> $slotchan" puts "Phone Number --> $phnum" puts "Initial Speeds (Tx/Rx) --> $initialtx/$initialrx" puts "Current Speeds (Tx/Rx) --> $currenttx/$currentrx" puts "Error Control Method --> $errorctrl" puts "Modulation Type --> $modtype" puts "Data Compression Method --> $datacomp" puts "Characters Sent/Received --> $charssent/$charsrcvd" puts "Blocks Sent --> $blkssent" puts "Blocks Resent --> $blksrsent" puts "Number of NAKs --> $numnaks" puts "Number of Line Block Errors --> $lnkblker" puts "Shifts Up/Down --> $upshifts/$downshifts" puts "Retrains requested/granted --> $retrnreq/$retrngr" puts "Call Duration --> $calldur" exit

Actually, you can. There are two ways of doing it. And you really have to follow the instructions pretty closely... Check it out. First of all, there's the method of just assigning it to a port. This is fine for things like talking to it if you need to configure or something like that and then just changing it right back. The problem arises in the fact that if you assign it to a port below 10,000 it's unscure, then entire Internet (or at least anyone probing the ports on your Netserver) could get into it without anything to stop them... If you wanted to do this, you would do these steps. set modem Sxx active set Sxx device /dev/network set Sxx service_device telnet yyyy(port to telnet to below 10,000) set Sxx modem off save all reset Sxx The other way is to implement security... Definatly do this if you're going to leaving the port around for a long time... set modem Sxx active set Sxx device /dev/network set Sxx service_device telnet yyyyy(Higher than 10,000) set Sxx modem off save all reset Sxx This prepares the port, afterwards, you have to set up a user that can access it. The netserver doesn't allow connections past 10,000 from the outside world. It will allow connection on ports higher than 10,000 from within itself, so by adding a user into your user profile and setting that user to use the ip of the netserver and port 10,001 or whatever, you can access the modem using security... Here's an example of what to do to create the dialin user profile. add user modem1 password booyaka set user modem1 host xxx.xxx.xxx.xxx(netserver) set user modem1 service telnet 10001 Once you're done, you should be able to telnet to the netserver, login as modem1 using password booyaka and it should connect you to the modem. Let me know if you have problems...

Hi, everyone... I am having problem with TC's netserver card sending 0sec duration to Radius Acct. I had tried Radius 1.16, 2.0 and both have the same problem.. i suspect this is a bug in the netserver card version i am runnig of. I am currently running 3.1.7, which is very old.. can someone please advice on which version we should upgrade to?? thank you.. i belive 3.4 doesn't support radius 2.0, is that right?? anyone had tried it and found any incompatibility..?? thanks in advance... 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

What would cause the Accounting Server to stop recording calls and under TCM -> NMC -> Logging Server to change from Primary to None? This happens rather frequently and I can't figure out why. The PC that is listed as the Primary Server is always on - it never is shut down. It is running Windows 95.

Where can I find a complete list of reasons that would trigger the NMC hub status to go critical (red) ? - lv

I noticed that in ati4 on a total control quad card, PRI system, there is a LAST ANI # slot that lists the callers phone number. Is there any other way to access this information, through the netserver perhaps? It might be useful to have it passed along through radius.

I asked this earlier, but got no response. Is there any way to specify a subnet size in the TC Radius "Framed-Route" line? Right now if I do a CIDR number after the subnet number ( X.X.X.X/Y ), the TC rejects the route and never installs it. If I specify no CIDR, the route is installed as a class C. I _really_ need this for NT routing. -- Pete XMission

On Thu, 17 Apr 1997, Pete Ashdown wrote: > I asked this earlier, but got no response. Is there any way to specify a > subnet size in the TC Radius "Framed-Route" line? > > Right now if I do a CIDR number after the subnet number ( X.X.X.X/Y ), the > TC rejects the route and never installs it. If I specify no CIDR, the > route is installed as a class C. > > I _really_ need this for NT routing. I am told, by USR, that version 3.3.x of Netserver does NOT support Framed-Route, but this is however in 3.4.x, and will be in 3.5 (3.5 will run on netservers that dont have 16MB)...........still waiting for USR engineers to call with a solution on this.........to see, if there is any way to do framed-route with 3.3.x currently, i just manually statically route them there ip's by adding static routes that are never taken down on the netserver. Brian > -- > Pete > XMission > 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

On Thu, 17 Apr 1997, Pete Ashdown wrote: > I asked this earlier, but got no response. Is there any way to specify a > subnet size in the TC Radius "Framed-Route" line? > > Right now if I do a CIDR number after the subnet number ( X.X.X.X/Y ), the > TC rejects the route and never installs it. If I specify no CIDR, the > route is installed as a class C. > > I _really_ need this for NT routing. I am told, by USR, that version 3.3.x of Netserver does NOT support Framed-Route, but this is however in 3.4.x, and will be in 3.5 (3.5 will run on netservers that dont have 16MB)...........still waiting for USR engineers to call with a solution on this.........to see, if there is any way to do framed-route with 3.3.x currently, i just manually statically route them there ip's by adding static routes that are never taken down on the netserver. Brian > -- > Pete > XMission > 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

On Thu, 17 Apr 1997, Greg Osterdyk wrote: > What would cause the Accounting Server to stop recording calls and under > TCM -> NMC -> Logging Server to change from Primary to None? This happens > rather frequently and I can't figure out why. The PC that is listed as the > Primary Server is always on - it never is shut down. It is running Windows 95. > Did you save your TCM config? Save to the NMC Card? 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

On Thu, 17 Apr 1997, Greg Osterdyk wrote: > What would cause the Accounting Server to stop recording calls and under > TCM -> NMC -> Logging Server to change from Primary to None? This happens > rather frequently and I can't figure out why. The PC that is listed as the > Primary Server is always on - it never is shut down. It is running Windows 95. > Did you save your TCM config? Save to the NMC Card? 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

On Thu, 17 Apr 1997, Laszlo Vecsey wrote: > I noticed that in ati4 on a total control quad card, PRI system, > there is a LAST ANI # slot that lists the callers phone number. > > Is there any other way to access this information, through the netserver > perhaps? It might be useful to have it passed along through radiu

On Thu, 17 Apr 1997, Laszlo Vecsey wrote: > I noticed that in ati4 on a total control quad card, PRI system, > there is a LAST ANI # slot that lists the callers phone number. > > Is there any other way to access this information, through the netserver > perhaps? It might be useful to have it passed along through radius. > go into nmc logging group, enable primary log server, set the log servers ip, set logging options to all. then go into the modems, trap enables, and "enableAll" for all attributes associated with an Incoming connection. do a SET both on the NMC AND MODEM settings, AND save to NVRAM!!!! Then Radius will log all of that info. 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

I fetched radius 2.4.23 from ftp.merit.edu, and the problem I'm running into is that after authentication (i checked the logfile) the modem disconnects immediately. Is anyone running this version with their USR TC without problems? Thu Apr 17 17:25:33 1997: rad_authenticate: 115/4 'bci' at Total-Control PPP Thu Apr 17 17:25:33 1997: Authentication: 115/4 'bci' via Total-Control from Total Control port 39 PPP - OK Thu Apr 17 17:25:37 1997: Accounting: 116/2 'bci' via Total-Control from Total Control port 39 Start - OK Thu Apr 17 17:25:37 1997: Accounting: 117/3 'bci' via Total-Control from Total Control port 39 Stop - OK Thu Apr 17 17:26:06 1997: rad_authenticate: 118/5 'bci' at Total-Control PPP Thu Apr 17 17:26:06 1997: Authentication: 118/5 'bci' via Total-Control from Total Control port 41 PPP - OK Thu Apr 17 17:26:09 1997: Accounting: 119/4 'bci' via Total-Control from Total Control port 41 Start - OK Thu Apr 17 17:26:10 1997: Accounting: 120/5 'bci' via Total-Control from Total Control port 41 Stop - OK

At 05:32 PM 4/17/97 -0500, you wrote: >On Thu, 17 Apr 1997, Greg Osterdyk wrote: > >> What would cause the Accounting Server to stop recording calls and under >> TCM -> NMC -> Logging Server to change from Primary to None? This happens >> rather frequently and I can't figure out why. The PC that is listed as the >> Primary Server is always on - it never is shut down. It is running Windows 95. >> > > >Did you save your TCM config? Save to the NMC Card? > >Brian Yep. It quits completely on its own. I can go look a couple hours later and it is good and a couple more hours after that, it stops.

On Thu, 17 Apr 1997, Joseph Jones wrote: > > > Guys, there is a way to do this... > > See, I never use radius to assign addresses to my dedicated customers... > I give them a username and password profile on the netserver itself. I > haven't found any problem with this so far, and I am doing > framed-routes... I'm running 3.3.28 Welll yeah thats just normal routing, which works. But "Framed-Route" is RADIUS specific, and all you have to do, not very complicated, is for example, after setting up the user as a radius user, just do: route add a.b.c.d/xx a.b.c.d x save all then your done 3.4 does fix this however 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

On Thu, 17 Apr 1997, Laszlo Vecsey wrote: > > I am told, by USR, that version 3.3.x of Netserver does NOT support > > Framed-Route, but this is however in 3.4.x, and will be in 3.5 (3.5 will > > run on netservers that dont have 16MB)...........still waiting for USR > > engineers to call with a solution on this.........to see, if there is any > > way to do framed-route with 3.3.x > > > > Interesting.. any clue why 3.4.x memory requirements went up and 3.5 will > be back down again? Guess I wont need to pop in a simm for a while, if at > all. > > Framed-Route will definately be a bonus, my static route table is starting > to grow large and ugly.. I hope Idle-Timeout and IP-Filter's work by then > too, because they dont appear to with 3.3.28... Idle-Timeout works just fine, and IP filters work terrific. hmm, you must be doing something wrong with them, if you want I can probably help you out with this, but I make HEAVY use of Idle-Timeout. What you are probably doing wrong, is #1 it's "Session-Timeout" not "Idle-Timeout" (at least here it is, Merit v2.4.23). here is an example: guest Authentication-Type = Unix-PW Service-Type = Framed, Session-Timeout = 600, Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.0, Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP, Port-Limit = 1, NAS-Port-Type = Async, Filter-Id = "guest" As you can see, I set Filter-Id guest. Therefore, on the Netserver, there are 2 filters declared: guest.in and guest.out. Command> show filter guest.in - IP rules - 1 deny 0.0.0.0/0 0.0.0.0/0 tcp dst lt 24 2 deny 0.0.0.0/0 0.0.0.0/0 tcp dst eq 110 3 deny 0.0.0.0/0 0.0.0.0/0 tcp dst eq 25 4 permit 0.0.0.0/0 0.0.0.0/0 ip Command> show filter guest.out - IP rules - 1 deny 0.0.0.0/0 0.0.0.0/0 tcp src lt 24 2 deny 0.0.0.0/0 0.0.0.0/0 tcp src eq 110 3 deny 0.0.0.0/0 0.0.0.0/0 tcp src eq 25 4 permit 0.0.0.0/0 0.0.0.0/0 ip Let me know if this does not help you and you need some more help. > > - lv > 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

Guys, there is a way to do this... See, I never use radius to assign addresses to my dedicated customers... I give them a username and password profile on the netserver itself. I haven't found any problem with this so far, and I am doing framed-routes... I'm running 3.3.28 Lots of steps to this one. And there's an interesting point at the end... Add a user to the netserver, make sure it's a netuser... type 'add netuser'... Assign him a password, and then set his address to whatever address you assign him through radius. Then go on the netserver, add an entry in the netmask table for the subnet you're trying to route down to the customer. Then, add a static route for the customer's subnet to the static IP that you assign him... Make sure that you set the netuser's subnet to 255.255.255.255.... This should do it. There's just ONE catch.... According to USR's AE department, Microsoft NT4.0 SERVER does not understand Van Jacobson compression... I don't know what the deal is exactly, but if you do this using an NT server, it DOES NOT WORK unless you turn OFF Van Jacobson Compression on the 4.0 Server. It works on NT3.5.1, it even works on NT4.0 WorkStation, but not server, unless you have the customer turn on VJ Header Compression. The most interesting things happen if you don't turn it off. The NT machine and all the machines that you route IPs to on it's network will be able to ping out, but start no services (ie telnet, ftp, whatever).... The machines will connect but then go no farther... Strange... They say that NT sends out the syn(sp?) and gets the synack(sp?) back, but from then on headers on compressed, so NT doesn't know what to do with it... (this is what they say)..... Interesting stuff.. =) Anyway, let me give you a quick example of how I set up the framed route... add netuser blah set user blah password blahblah set user blah address 10.1.1.1 set user blah netmask 255.255.255.255 add netmask 12.1.1.1 255.255.255.192 ip route add 12.1.1.1/26 10.1.1.1 1 That should do it... Just make sure your NT4.0 Server customers turn off the VJ Compression...

I noticed that radius does in fact report the above two fields when an ISDN user connects, but what about regular analog calls? It is a PRI system afterall, doesn't `ati4` keep track of it in the quad modem for all incoming calls, or is it only possible to track calls that come in from the client digitally (ISDN)... ? - lv

> I am told, by USR, that version 3.3.x of Netserver does NOT support > Framed-Route, but this is however in 3.4.x, and will be in 3.5 (3.5 will > run on netservers that dont have 16MB)...........still waiting for USR > engineers to call with a solution on this.........to see, if there is any > way to do framed-route with 3.3.x > Interesting.. any clue why 3.4.x memory requirements went up and 3.5 will be back down again? Guess I wont need to pop in a simm for a while, if at all. Framed-Route will definately be a bonus, my static route table is starting to grow large and ugly.. I hope Idle-Timeout and IP-Filter's work by then too, because they dont appear to with 3.3.28... - lv

Laszlo Vecsey <master@internexus.net> writes: > I noticed that radius does in fact report the above two fields when an > ISDN user connects, but what about regular analog calls? If you receive the ANI information as part of the call from your telco, then it will be stored by the modem, and included in the RADIUS request. This is the Calling-Station-Id. The Called-Station-Id is the number they dialed, or often referred to as DNIS information (although I think technically that term arises from channelized T1 circuits rather than PRI spans) What you may be running into is that caller id information isn't always available for analog calls depending on whether the caller id information was passed on through the network from the origination caller. It can also simply not be supplied by your telco over the PRI circuit (they may have configured it off), but if you are making ISDN calls over the same circuit then that's definitely not the case. You'll always be able to obtain ANI from an ISDN digital caller because the requirements to ensure that a digital path exists from caller to your equipment (in order to get an ISDN connection) also ensures that the proper signaling is going on to communicate that callers origination information. The same isn't necessarily true for analog calls. Oh, and from an earlier note - this information is in the RADIUS request (both authentication and accounting I believe) as well as in the modem via ATI4, but is also available via management (through the NMC) in the mdmCs (statistics) table in the MIB, which should be viewable as modem statistics if using TCM. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Brian wrote: > > On Thu, 17 Apr 1997, Pete Ashdown wrote: > > > I asked this earlier, but got no response. Is there any way to specify a > > subnet size in the TC Radius "Framed-Route" line? > > > > Right now if I do a CIDR number after the subnet number ( X.X.X.X/Y ), the > > TC rejects the route and never installs it. If I specify no CIDR, the > > route is installed as a class C. > > > > I _really_ need this for NT routing. > > I am told, by USR, that version 3.3.x of Netserver does NOT support > Framed-Route, but this is however in 3.4.x, and will be in 3.5 (3.5 will > run on netservers that dont have 16MB)...........still waiting for USR > engineers to call with a solution on this.........to see, if there is any > way to do framed-route with 3.3.x > > currently, i just manually statically route them there ip's by adding > static routes that are never taken down on the netserver. > > Brian > > > -- > Pete > > XMission > > > > 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 I also was told the same by an engineer at USR (took 4 days of calls and had to go all the way to the level below R&D to get the answer) that only the new 3.4.x (which needs 16 megs) can do framed-route.......did not know the new 3.5 coming out will work on 8 megs.......any ideas when it is due out?? thankx -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

On Thu, 17 Apr 1997, Rick wrote: > > I also was told the same by an engineer at USR (took 4 days of calls and > had to go all the way to the level below R&D to get the answer) that > only the new 3.4.x (which needs 16 megs) can do framed-route.......did > not know the new 3.5 coming out will work on 8 megs.......any ideas when > it is due out?? thankx > -- No, no word as of yet. However, If you're REALLY nice to them they might let you run a beta version of 3.5 Brian > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Rick---* http://www.monmouth.com | Serving the Central > Monmouth Internet Engineer | New Jersey Area > Operations and Technical Support | Phone: 908-224-8624 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > 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

I've substantially improved the tcview utility with some additional features (combining show session and show all stats) into one easy to interpret chart. This is a utility to quickly see who is logged onto a netserver from the unix prompt; the !root password is hardcoded into the binary at compile time. If you find any bugs, have suggestions, please let me know about them :> - lv #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)

Pete Ashdown writes: > I asked this earlier, but got no response. Is there any way to specify a > subnet size in the TC Radius "Framed-Route" line? Yes - I'm doing it all the time. > Right now if I do a CIDR number after the subnet number ( X.X.X.X/Y ), the > TC rejects the route and never installs it. If I specify no CIDR, the > route is installed as a class C. I'm returning: Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = 192.168.10.1 Framed-IP-Netmask = 255.255.255.255 Framed-Routing = None Framed-Route = 192.168.10.1.1/32 And the netsrv does its stuff fine: Command> show route Destination Gateway Flag Met Interface VPN -------------------- ---------------- ---- --- --------- --- 192.168.10.1 /32 192.168.10.1 HL 1 ptp67 0 Do you have RIPv2 turned on in the chassis? We have - so that may be a difference. I also recall early TC code being *very* broken in respect of CIDR (such as advertising the right subnet mask, but from the wrong base IP address). Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

Rick Payne said once upon a time: >I'm returning: > > Service-Type = Framed > Framed-Protocol = PPP > Framed-IP-Address = 192.168.10.1 > Framed-IP-Netmask = 255.255.255.255 > Framed-Routing = None > Framed-Route = 192.168.10.1.1/32 > >And the netsrv does its stuff fine: > >Command> show route >Destination Gateway Flag Met Interface VPN >-------------------- ---------------- ---- --- --------- --- >192.168.10.1 /32 192.168.10.1 HL 1 ptp67 0 You don't need "Framed-Route" to get this kind of result. It happens without it at all. In addition your "Framed-Route" entry is in the wrong format, so it is being ignored anyway. What I'm talking about is TWO subnets routing, not just the connected subnet. For example, with NT, I need to do something like this to route subnets: Service-Type = Framed Framed-Protocol = PPP Framed-IP-Address = 204.228.133.22 Franed-IP-Netmask = 255.255.255.255 Framed-Route = "207.135.128.128/29 204.228.133.22 1"

Rick said once upon a time: >I also was told the same by an engineer at USR (took 4 days of calls and >had to go all the way to the level below R&D to get the answer) that >only the new 3.4.x (which needs 16 megs) can do framed-route.......did >not know the new 3.5 coming out will work on 8 megs.......any ideas when >it is due out?? thankx Well, 3.3.x can do it, but with a unchangeable subnet size of 255.255.255.0. :-(

Brian said once upon a time: >Welll yeah thats just normal routing, which works. But "Framed-Route" is >RADIUS specific, and all you have to do, not very complicated, is for >example, after setting up the user as a radius user, just do: > >route add a.b.c.d/xx a.b.c.d x > >save all This is great if you have one TC and a few networks, but when you have 10 TCs and hundreds of networks, it loses its attractiveness.

I'm using Livingston radius 2.0 with a Total Control Netserver running 3.4.23. It doesn't pick up the framed routes in my Radius entry: Pbelfert Auth-Type = System, Prefix = "P" Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 206.11.209.21, Framed-Route = "206.11.209.202 206.11.209.21 1", Framed-Route = "206.11.209.203 206.11.209.21 1", Framed-Netmask = 255.255.255.255, Framed-Routing = None, Framed-MTU = 1500, US Robotics has confirmed that this is a bug in code version 3.4.23, and will be fixed in 3.5 shipping soon. Does anyone know of a workaround to get framed-route to work with 3.4.23 until 3.5 ships? Also, does anyone have a version of the pmwho program that works with Netserver 3.4.23? I use this program to collect statisitics, but it won't connect with the Netserver. Brian

Well, definatly, but I have customers who I route 64 Blocks down to, and adding 64 routes to my netserver one by one got old really fast, as I'm sure you know. There are some advantages to having it on the netserver itself. If for some reason your radius goes down, then your dedicated customers can still get on-line. It's not that much harder than the radius method and there's one less thing that can go wrong... If nothing else, it's probably not a bad temporary measure until they get 3.5 out there, so you don't have a routing table thats 10 pages long... I remember when I had a dedicated customer that wanted a temp 28.8 while his frame relay line was ordered... Trying to type in an entire class C was like... No.. =) So I did this little thing to get around it... Joe

Laszlo Vecsey said once upon a time: > >I've substantially improved the tcview utility with some additional >features (combining show session and show all stats) into one easy to >interpret chart. This is a utility to quickly see who is logged onto a >netserver from the unix prompt; the !root password is hardcoded into the >binary at compile time. > >If you find any bugs, have suggestions, please let me know about them :> Very cool, but I have many netservers with different passwords. Is there any way to make an array of hosts with passwords, then have an argument for the host?

> Laszlo Vecsey said once upon a time: > > > >I've substantially improved the tcview utility with some additional > >features (combining show session and show all stats) into one easy to > >interpret chart. This is a utility to quickly see who is logged onto a > >netserver from the unix prompt; the !root password is hardcoded into the > >binary at compile time. > > > >If you find any bugs, have suggestions, please let me know about them :> > > Very cool, but I have many netservers with different passwords. Is there > any way to make an array of hosts with passwords, then have an argument for > the host? I've thought about that, but I'm not in a situation like that and I wouldn't really be able to debug it :> I can implement some sorting routines based on port, username, and input or output activity which will be a good start for merging multiple show sessions's from different TC's. And then I guess another column could be introduced to mark which TC# it is, since all the lines would be merged. For now I would suggest using the 'tcview -q' option to get only the lines, without any header information. Compile a seperate binary for each TC, and use a script to call one after the other, creating a big chart.. ? Inefficient I know, but a quick hack. :> Actually, doing what you suggest is not a big deal at all I can make the changes in a few minutes. I was jumping to the next step, which was adding the complexity of threads and actually connecting to each TC simultaneously. Just think, regardless of how many users are online or how many TC's you have, the chart will come back in the same amount of time! Nice. - lv

On Thu, 17 Apr 1997, Brian wrote: > I am told, by USR, that version 3.3.x of Netserver does NOT support > Framed-Route, but this is however in 3.4.x, and will be in 3.5 (3.5 will > run on netservers that dont have 16MB)...........still waiting for USR > engineers to call with a solution on this.........to see, if there is any > way to do framed-route with 3.3.x I asked about framed-route in 3.4.23 today with USR support, and they said a bug in 3.4.23 prevents it from working. They said that 3.5 will be out soon, and will fix it. Brian

On Thu, 17 Apr 1997, Brian wrote: > I am told, by USR, that version 3.3.x of Netserver does NOT support > Framed-Route, but this is however in 3.4.x, and will be in 3.5 (3.5 will > run on netservers that dont have 16MB)...........still waiting for USR > engineers to call with a solution on this.........to see, if there is any > way to do framed-route with 3.3.x I asked about framed-route in 3.4.23 today with USR support, and they said a bug in 3.4.23 prevents it from working. They said that 3.5 will be out soon, and will fix it. Brian

On Fri, 18 Apr 1997, Pete Ashdown wrote: > Rick said once upon a time: > > >I also was told the same by an engineer at USR (took 4 days of calls and > >had to go all the way to the level below R&D to get the answer) that > >only the new 3.4.x (which needs 16 megs) can do framed-route.......did > >not know the new 3.5 coming out will work on 8 megs.......any ideas when > >it is due out?? thankx > > Well, 3.3.x can do it, but with a unchangeable subnet size of > 255.255.255.0. :-( > 3.4.79 fixes Framed-Route 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

Brian said once upon a time: >3.4.79 fixes Framed-Route Where did you get 3.4.79?

Laszlo Vecsey said once upon a time: >Actually, doing what you suggest is not a big deal at all I can make the >changes in a few minutes. I was jumping to the next step, which was adding >the complexity of threads and actually connecting to each TC >simultaneously. Just think, regardless of how many users are online or how >many TC's you have, the chart will come back in the same amount of time! >Nice. That would be very awesome. Another small matter is maybe encrypting the passwords stored in the binary. I just get afraid that someone would get ahold of the binary somehow and then execute a "strings" on it.

For some reason, the UNIX "sz", an rlogin session, and 3.4.23 is a bad equation. I can make "sz" hangup the Netserver port without fail, whenever it exits. Even if I do a character test with "sz -T" the program will run through all the tests, then do something to the session to hang up the port. This didn't happen under 3.3.28. I looked through the code of "sz" and the only thing I suspected is that it resets the tty mode back to its original settings. Maybe the Netserver takes this too much to heart. Is there some undocumented knob somewhere that I can set to make it stop this behavior? -- Pete XMission

On Fri, 18 Apr 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >3.4.79 fixes Framed-Route > > Where did you get 3.4.79? > try and get thru to an engineer, then bed and pleed for a solution :) or just be patient and wait :) 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

Pete Ashdown <pashdown@xmission.com> writes: > Brian said once upon a time: > > >3.4.79 fixes Framed-Route > > Where did you get 3.4.79? 3.4.79 would be one of the interim 3.4 engineering releases and is unlikely to be generally available. I don't know all the policies involved, but questions on availability should probably be directed to your USR service contact, in terms of requirements for distribution of engineering builds. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Greg Coffey <greg@coffey.com> writes: > Did you ever get an answer to this? I was gone during the thead and haven't > seen any responses yet. I too would be interested in this info. As far as I'm aware it basically turns the quad modem in to a quad I-Modem which can then be a termination point for ISDN digital calls (in lieu of the NETServer) which would allow you to use an off-board terminal server device but accept ISDN calls. I suppose you could also have an analog-only NETServer with ISDN enabled modems and accept ISDN calls on the modem and then over the packet bus to the NETServer, but it seems probably better use of the modem channels in such a configuration to leave them for analog calls and just add the ISDN daughtercard to the NETServer. I'm pretty sure (but not positive) that the system must still be fed by PRI circuits to accept the digital ISDN call that will termination on the quad card. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Pete Ashdown <pashdown@xmission.com> writes: > This didn't happen under 3.3.28. I looked through the code of "sz" and the > only thing I suspected is that it resets the tty mode back to its original > settings. Maybe the Netserver takes this too much to heart. Is there anything interesting in the NETServer syslog as to why it terminated the call? -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

When connecting to the netserver via telnet there seems to be a little over a one second delay before data is sent. I wrote a small program to time it, even though I'm not implementing the telnet protocol per se, but even with a real telnet client this delay is still apparent so I'm lead to believe that the delay is intentionally implemented in the netserver (3.3.28).. and not a side effect of not handling DO, DONT, WILL, WONT type telnet protocol messages. A second might not sound like much, but for a utility such as tcview it can make a world of a difference; the majority of program execution time is spent waiting during that second! Connection established. Connection time thus far: 121 ticks, 1 seconds Read: [... few bytes of telnet protocol messages ... ] Read: Read: U.S. Robotics Read: Total Control (tm) NETServer Card Read: Read: login: Will this be fixed in an upcoming netserver release? I certainly dont see the delay as a feature, Cisco routers for example transmit immediately; why would the delay be there? - lv

The moment I sent that message off about the 1 second delay, I ran my program again noticed it started transmitting immediately. Standard telnet from unix connected immediately as well, where as before it showed the same signs of the delay. Now the question is why this is intermittent... maybe the netserver needs to warm up with a bunch of telnet requests? :> - lv

Brian wrote: > > On Fri, 18 Apr 1997, Pete Ashdown wrote: > > > Brian said once upon a time: > > > > >3.4.79 fixes Framed-Route > > > > Where did you get 3.4.79? > > > > try and get thru to an engineer, then bed and pleed for a solution :) > > or just be patient and wait :) > > 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 Took me 4 business days of having to talk to level 1 and 2 USR technical support until I was able to get a USR engineer who did tell me about the planned new release that they are using which fixed the framed-route problem. He offered it to me but since our netserver cards do not have 16megs I had to decline. I take it the version he was referring to was 3.4.79......... -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Seems that the first time a telnet session is made to the netserver, the delay exists (regardless of where you telnet from) - but if you leave it logged in or connected, future telnet sessions will connect and start transmitting immediately -- no delay. Any idea why this would be the case? I was hoping I had some port misconfigured, but i couldn't find anything related. I'd appreciate it if some of you would check for the delay to see if this is an isolated case here or not. - lv

Is anyone using the netserver 3.4.23 with only 8 megs of ram? The other day while talking to an engineer at USR he had mentioned that the 3.4.23 he had hinted it may run on 8 megs............can anyone verify this......I have heard it can help increase dual-channel performance so we will upgrade to 3.4.23 in the near future but since we have alot of remote locations I would like to know if it is feasable to do it without having to remotely go to each location and insert more memory....??? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

We have some users who are getting "high" ping times on our quake server. in the 500-900 range. They claim if they log into ANOTHER ISP, they actually get faster times off our server. To me the only different thing would be they wouldnt be going thru the USR TC, is anyone else having any problems with online games? What do you do about it. Btw, PPP IN MODEM is on 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

Once upon a time JungSeob Lee shaped the electrons to say... > What I want to know is this. With Netserver 3.3 or high and Livingston's >Radius 2.0, to implement multiple ip pool for each group. Does anyone Neither RADIUS nor ComOS supports multiple IP pools. You would have to hack RADIUS to fake it. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

We have recently installed some new TC hubs and have them running fine using our radius server that we already had. I see that USR has their own software for security and accounting. I am a little confused with regards to which does what. I see they have a file called tsec43.zip which it says does security and accounting. I also see they have another file called tcmwac43.zip which says it does accounting. If I already have a radius server running other software do I need the tsec43.zip or can I just install the tcmwac43.zip? Also, what does the tcmwac43.zip add that the tsec43.zip does not have??? thankx -- Rick

Brian, We have experienced the very same thing on our quake server. Pete Ashdown, XMission's owner, has noticed a direct correlation between our move to the TCs and the problem. I believe he mentioned MTU traffic problems via the TCs? Perhaps he could add some details? As an avid quake player I'd very much like to hear of any _real_ solutions to this problem. Pete has lessened the effect on our quake server but many of our customers are still lagging badly. On Sat, 19 Apr 1997, Brian wrote: > We have some users who are getting "high" ping times on our quake server. > in the 500-900 range. They claim if they log into ANOTHER ISP, they > actually get faster times off our server. Grant ???????????????????????????????????????????????????????????????????????????? "He who fights monsters might take care lest he thereby become a monster." --Friedrich Nietzsche ????????????????????????????????????????????????????????????????????????????

On Sat, 19 Apr 1997, MegaZone wrote: > Once upon a time JungSeob Lee shaped the electrons to say... > > What I want to know is this. With Netserver 3.3 or high and Livingston's > >Radius 2.0, to implement multiple ip pool for each group. Does anyone > > > Neither RADIUS nor ComOS supports multiple IP pools. > > You would have to hack RADIUS to fake it. > > -MZ > -- > Livingston Enterprises - Chair, Department of Interstitial Affairs > Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com > For support requests: support@livingston.com <http://www.livingston.com/> > Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > hmm, i remember seeing in the Netserver 3.4 book, a radius entry using something like the "IP-Address-Pool-Name" attribute, and then setting a IP Address pool on the Netserver........might have been enhanced radius dont know...... 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

Brian writes: > We have some users who are getting "high" ping times on our quake server. > in the 500-900 range. They claim if they log into ANOTHER ISP, they > actually get faster times off our server. Same here. > To me the only different thing would be they wouldnt be going thru the USR > TC, is anyone else having any problems with online games? What do you do > about it. Yup - its definifely a USR problem. It appears to be a problem with latency in the USR chassis - the latency isn't consistant - and I believe thats what causes Quake to have problems. I've pressed USR for a solution - nothing yet though. Rick -- Rick Payne, Senior Network Admin | Meddle not in the affairs of NETCOM Internet Ltd. | dragons - for you are crunchy & rickp@corp.netcom.net.uk | taste great dipped in chocolate.

On Sun, 20 Apr 1997, Grant Sperry wrote: > Brian, > > We have experienced the very same thing on our quake server. Pete Ashdown, > XMission's owner, has noticed a direct correlation between our move to the > TCs and the problem. I believe he mentioned MTU traffic problems via the > TCs? Perhaps he could add some details? As an avid quake player I'd > very much like to hear of any _real_ solutions to this problem. Pete has > lessened the effect on our quake server but many of our customers are > still lagging badly. > > On Sat, 19 Apr 1997, Brian wrote: > > > We have some users who are getting "high" ping times on our quake server. > > in the 500-900 range. They claim if they log into ANOTHER ISP, they > > actually get faster times off our server. > > Grant > > ???????????????????????????????????????????????????????????????????????????? > "He who fights monsters might take care lest he thereby become a monster." > --Friedrich Nietzsche > ???????????????????????????????????????????????????????????????????????????? > What do you call "lagged". When WE dialed into OUR server from the office, we got 150-220 which is good. SOME people going thru the same rack get 700-900. I clicked the modem we were on, and the one they were on, and then did a performacne monitor. There werent too many big differences, I noticed the person with the high ping times had 166 block resends, Trelis16 vs OUR Trelis64, little bit worse signal to noice ratio...nothing I felt that was significant. When I ICMP ping him, I get good times, this is only via quake that it isnt so good. I tried changing pppmodem to off, that did nothing, what else can i mess around with? MOnday I am upgrading from netserver 3.3.x to 3.4.x and hopefully this fixes somethings. 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

Hi, all. I think this kind of question posted several time on these mailing lists, but I can't find out info that what I want. What I want to know is this. With Netserver 3.3 or high and Livingston's Radius 2.0, to implement multiple ip pool for each group. Does anyone give me some example file to me? For instance, example of users, authfile, group... Hope to hear from you soon.

Rick <rallan@monmouth.com> writes: > Is anyone using the netserver 3.4.23 with only 8 megs of ram? The other > day while talking to an engineer at USR he had mentioned that the 3.4.23 > he had hinted it may run on 8 megs............can anyone verify > this...... It will technically load but USR will not support it in that configuration (last I heard). So no problem reports, bug acceptances, etc.. My own testing has shown a tendency of 3.4.23 to reboot in an 8MB configuration. It is not yet clear if it is specifically related to the memory, or just to a problem that more memory helps hide. So it's kind of use at your risk. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Do many of you have the x2 up and running? Its been very frustrating here trying to get everything configured. Supposedly we have all we need except for a small change to the channelized T1. We need to get it changed to E&M type 2. USWest tells me that they can change it but I have to pay for a complete new install (another $3000). And my monthly line charges about triple to $72 per line. I faxed the specs to USW from USR way back when we were configuring the line and even got a USR and USW rep together on a conference call back in January. Needless to say, I'm not real thrilled. I bought a 56k external sportster and tried it from home this week and I get mediocre connects to the TC box (19200-26000). Other customers are experiencing the same results. I get better rates going to the regular analog bank of clone 33.6 modems than I do to the USR box as it sits right now. I'm no phone genius, are there other options to make it work on the T1 as is? My TC card is T1 only so PRI would only be viable if I upgrade the card (more $$$$) in the box but it looks like the monthly charge for PRI is more than the T1 too from USW. Thanks, Greg Coffey, CoffeyNet ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. Local Internet for Casper, Rawlins, Douglas, Casper, WY 82601 Wheatland, Pinedale, Lander & Lusk, WY http://www.coffey.com (307) 234-5443 ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

We had to get our T1s reengineered to support x2 BECAUSE the phone company put the circuits through a channel bank. We are currently running E&M and have x2 support. Our problem, in Ameritech terms, was that we were running in "non-integrated" mode and we needed to be in "integrated" mode or some other mumbo-jumbo Ameritech talk. Basically it brings a pure digital signal to our ENHs and it supports x2. When they switched us to the version of signalling that allowed x2 we lost the ability to dial into individual lines. Now, no matter what number we dial it hits the next available line. This is acceptable but make troubleshooting a card VERY difficult, but it works so I'm leaving it alone. I know very little about the phone company and they way their switches work but maybe this will help. Tom At 08:26 AM 4/21/97 -0600, you wrote: >Do many of you have the x2 up and running? Its been very frustrating here >trying to get everything configured. Supposedly we have all we need except >for a small change to the channelized T1. We need to get it changed to E&M >type 2. USWest tells me that they can change it but I have to pay for a >complete new install (another $3000). And my monthly line charges about >triple to $72 per line. I faxed the specs to USW from USR way back when we >were configuring the line and even got a USR and USW rep together on a >conference call back in January. Needless to say, I'm not real thrilled. I >bought a 56k external sportster and tried it from home this week and I get >mediocre connects to the TC box (19200-26000). Other customers are >experiencing the same results. I get better rates going to the regular >analog bank of clone 33.6 modems than I do to the USR box as it sits right >now. I'm no phone genius, are there other options to make it work on the T1 >as is? My TC card is T1 only so PRI would only be viable if I upgrade the >card (more $$$$) in the box but it looks like the monthly charge for PRI is >more than the T1 too from USW. >Thanks, >Greg Coffey, CoffeyNet >~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ >142 S. Center St. Local Internet for Casper, Rawlins, Douglas, >Casper, WY 82601 Wheatland, Pinedale, Lander & Lusk, WY >http://www.coffey.com (307) 234-5443 >~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ > >

Greg Coffey wrote: > > Do many of you have the x2 up and running? Its been very frustrating here > trying to get everything configured. Supposedly we have all we need except > for a small change to the channelized T1. We need to get it changed to E&M > type 2. USWest tells me that they can change it but I have to pay for a > complete new install (another $3000). And my monthly line charges about > triple to $72 per line. I faxed the specs to USW from USR way back when we > were configuring the line and even got a USR and USW rep together on a > conference call back in January. Needless to say, I'm not real thrilled. I > bought a 56k external sportster and tried it from home this week and I get > mediocre connects to the TC box (19200-26000). Other customers are > experiencing the same results. I get better rates going to the regular > analog bank of clone 33.6 modems than I do to the USR box as it sits right > now. I'm no phone genius, are there other options to make it work on the T1 > as is? My TC card is T1 only so PRI would only be viable if I upgrade the > card (more $$$$) in the box but it looks like the monthly charge for PRI is > more than the T1 too from USW. > Thanks, > Greg Coffey, CoffeyNet > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ > 142 S. Center St. Local Internet for Casper, Rawlins, Douglas, > Casper, WY 82601 Wheatland, Pinedale, Lander & Lusk, WY > http://www.coffey.com (307) 234-5443 > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ We have a bunch of boxes running with PRI's and are in the process of trying to get a new box working with a channelized T1. I hope we do not run into the problems you have had.....by the way, PRI's are cheaper here in NJ then the channelized T1's are and PRI's of course give you both voice and digital (analog and ISDN) while the T1's will only do voice (analog).........I would love to know who sets the pricing.......also I have been told by many that our $450/mo for PRI service is about the lowest around.... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

> We had to get our T1s reengineered to support x2 BECAUSE the phone company > put the circuits through a channel bank. We are currently running E&M and > have x2 support. Our problem, in Ameritech terms, was that we were running > in "non-integrated" mode and we needed to be in "integrated" mode or some > other mumbo-jumbo Ameritech talk. Basically it brings a pure digital signal > to our ENHs and it supports x2. Your old circuit was a "line side" T1, which is talked about in the USR documentation as a definate No-No when it comes to X2 connections. Basically, from the switch, your T1 goes through another piece of equipment that could add another Digital to Analog conversion into the process. The Trunk side or "integrated" T1 circuit is fed directly out of the switch, thus eliminating the chance of a D-->A conversion. > When they switched us to the version of signalling that > allowed x2 we lost the ability to dial into individual lines. Now, no matter > what number we dial it hits the next available line. This is acceptable > but make troubleshooting a card VERY difficult, but it works so I'm leaving > it alone. If you have DID circuits, you *should* be able to mimic the old way the lines came in. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Exec-PC Vice President, Information Services |

Greg wrote: > > Do many of you have the x2 up and running? Its been very frustrating here > trying to get everything configured. Supposedly we have all we need except We have 3 x2 TC-HUBs up - the ones for which we ordered PRI's. The channelized T1 has been a nightmare for us. Bell Atl. had a real bad install date on a PRI for one pop so we went with channelized T1 as an alternate plan but ordered the PRI as well. Its now a horse race even though there was originally a 3 month difference in install times. First they misinstalled ground-start instead of E&M Type II. That led to another 1.5 mos of "REBUILDING/REDESIGNING" the circuit, whatever that means. Now it just doesn't work but since the PRI is due in tommorrow I'm starting to look on it more as a curiosity (horror story?) Not that the PRI's are a picnic either - just less awful. The phone company seems not to be able to afford?/acquire? any PRI test sets and there is a fair amount that can be set wrong and the PRI won't work. We now routinely use an Ascend PL400 as a test set :) - I won't get into what that says about the USR diagnostics and setup friendliness. PRI's make sense here because Bell Atl prices them lower than Channelized T1's. Ken

Grant Sperry said once upon a time: >We have experienced the very same thing on our quake server. Pete Ashdown, >XMission's owner, has noticed a direct correlation between our move to the >TCs and the problem. I believe he mentioned MTU traffic problems via the >TCs? Perhaps he could add some details? As an avid quake player I'd >very much like to hear of any _real_ solutions to this problem. Pete has >lessened the effect on our quake server but many of our customers are >still lagging badly. I thought it was related to the MTU problems I was having with UDP streams and 3.3.28. However, with 3.4.x, the MTU/UDP problems appear to be fixed, but Quake is still lagging for some of our subscribers.

David Bolen said once upon a time: > >Pete Ashdown <pashdown@xmission.com> writes: > >> This didn't happen under 3.3.28. I looked through the code of "sz" and the >> only thing I suspected is that it resets the tty mode back to its original >> settings. Maybe the Netserver takes this too much to heart. > >Is there anything interesting in the NETServer syslog as to why it >terminated the call? Nope. It looks just like a disconnect. We found that having the UNIX term set to ANSI doesn't do the hangup, but having it set on VT100 does. Bizarre.

David Bolen said once upon a time: >I'm pretty sure (but not positive) that the system must still be fed >by PRI circuits to accept the digital ISDN call that will termination >on the quad card. It would be great if it worked off of DSS. Supposedly the Ascend equipment can terminate 56K ISDN calls from DSS. US Worst offers BRI in some areas that they don't offer PRI (go figure).

Laszlo Vecsey said once upon a time: >> We found that having the UNIX term set to ANSI doesn't do the hangup, but >> having it set on VT100 does. Bizarre. > >Could it be ctrl-s and ctrl-q characters (XON/XOFF)? These would most >definately be generated from an sz transfer, even from programs like unix >pine. It sounds like just a client side configuration problem... Nope, it isn't that. I tested it out, and I've also got my DTE settings set to "hardware flow control".

> David Bolen said once upon a time: > > > >Pete Ashdown <pashdown@xmission.com> writes: > > > >> This didn't happen under 3.3.28. I looked through the code of "sz" and the > >> only thing I suspected is that it resets the tty mode back to its original > >> settings. Maybe the Netserver takes this too much to heart. > > > >Is there anything interesting in the NETServer syslog as to why it > >terminated the call? > > Nope. It looks just like a disconnect. > > We found that having the UNIX term set to ANSI doesn't do the hangup, but > having it set on VT100 does. Bizarre. Could it be ctrl-s and ctrl-q characters (XON/XOFF)? These would most definately be generated from an sz transfer, even from programs like unix pine. It sounds like just a client side configuration problem... - lv

> And it seems when v.34 >connections are attempted, the rates are more like 21k and 26k, not 31k >and 33.6k anymore. Something has obviously changed these past few weeks >and I'm not sure what. I have PRI lines here and the local phone switch is >supposedly completely digital, perhaps there is some problem with the way >the copper lines are run around here to the customers? I even have a >customer that reports making an x2 connection to me about every 1 in 10 >attempts, where as to a competitor he gets through every single time. >USRobotics technicians tested out my TC from their location one day, and >were only able to connect sometimes.. later in the day or the next day >they were able to connect everytime. This is exactly what we're seeing with customers dialing in with analog modems. I have the latest code in the TC box and the latest in my x2 Sportster and they connect at mediocre rates (<28.8) when I call into the box. Customers call my bank of analog clones, mostly rockwell chipset modems, and get 28.8 or higher but 19.2 or 21.6 when they call the TC modems. Thanks, Greg Coffey, CoffeyNet ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ 142 S. Center St. Local Internet for Casper, Rawlins, Douglas, Casper, WY 82601 Wheatland, Pinedale, Lander & Lusk, WY http://www.coffey.com (307) 234-5443 ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Greg Coffey <greg@coffey.com> writes: > Do many of you have the x2 up and running? Its been very frustrating here > trying to get everything configured. Supposedly we have all we need except > for a small change to the channelized T1. We need to get it changed to E&M > type 2. Yes, you need to either be running a PRI circuit or a trunk-side T1 (which most E&Ms are, however, I've heard that you have to be careful with some telcos, and USWest was noted, so be sure you mention "trunk side") The problem with doing any other kind of circuit (I'm presuming you may be using ground start or (ick) loop start) is that those T1 circuits have extra analog conversions on the path, at the channel banks that the telco uses to convert their individual analog copper pairs into a single T1 to send to your equipment. That invalidates x2. > USWest tells me that they can change it but I have to pay for a > complete new install (another $3000). And my monthly line charges about > triple to $72 per line. This is up to the particular telco - yes, in many cases you'll find an E&M T1 costs significantly more than a ground start, although the reverse can sometimes be true as well. I've got circuits all over the country and there is no single rule that holds throughout. Often, you'll find PRI circuits are the cheapest - sometimes it just matters what the telco is currently "pushing". In many cases the cost for the E&M is higher due to how the telcos have tariffed it, and they throw in DID service and other stuff. If you have an alternative access provider in the area, they are often much more willing to give you the E&M/PRI for cheaper costs because they don't want to put in any analog pairs themselves, but want to stay digital. > I > bought a 56k external sportster and tried it from home this week and I get > mediocre connects to the TC box (19200-26000). Other customers are > experiencing the same results. Is this the same TC box that you are talking about above? If so, then there's no way you will be getting x2 connections if you are not using a trunk side T1 or PRI circuit. It'll be just like calling into V.34 modems. > I'm no phone genius, are there other options to make it work on the T1 > as is? No. You may wish to read the white paper on USR's x2 site (x2.usr.com) but the short answer is that you cannot suffer an extra analog to digital conversion on the channel except for the "last mile" at the user's end. You _must_ have a trunk-side circuit on your side which is either a trunk-side E&M T1 or a PRI circuit. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Rick <rallan@monmouth.com> writes: > We have a bunch of boxes running with PRI's and are in the process of > trying to get a new box working with a channelized T1. I hope we do not > run into the problems you have had..... Channelized T1 will work fine as long as you have a trunk-side line (almost all E&Ms fall into that category - ground/loop starts definitely do not). I don't think you'll have much problem with BA in that regard. The only difference you may see with a T1 termination circuit is that due to the robbed-bit you'll most likely have on the circuit (used for signaling on each DS0, as opposed to the decided D-channel on a PRI circuit) you've really only got 56K pipes for each DS0. This may result in a 'tick' or due drop in connection rates. But for x2, a 'tick' is only 1.3K and depending on the quality of the circuit, the upper bandwidth may have already had to be dropped, so the end user may not actually see a difference. If they do, it will likely be a small (1.3 or 2.6K) drop in rate. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Ken Leland <kwl@shell.monmouth.com> writes: > First they misinstalled ground-start instead of E&M Type II. That > led to another 1.5 mos of "REBUILDING/REDESIGNING" the circuit, whatever > that means. Now it just doesn't work but since the PRI is due in > tommorrow I'm starting to look on it more as a curiosity (horror story?) The need for a rebuild/redesign is because there is a big difference between how a groundstart versus an E&M is configured. Typically, a ground start (or loop start) is actually built as 24 individual pairs which carry the lines to the telco switch (e.g., just like 24 house lines - in fact a typical house line is your basic loop start, and your typical individual business trunk is ground start): Analog Digital +-------+ +-------+ +-----+ | |-------| | | | | Telco |- 24 -|Channel|========/ T1 /======| USR | |Switch |-lines-| Bank | | TC | | |-------| | | | +-------+ +-------+ +-----+ The purpose of the channel bank is to convert the individual analog pairs into a single digital T1 signal. However, this means that there is an extra analog to digital conversion (between the switch and the channel bank) along any user calling into your equipment. It also means that there are 24 individual pairs of copper that can go bad or have a problem, and yet you might not see any errors on your T1 span. The extra analog conversion means x2 will not function. Nevertheless, even though it means more gear, most telcos are well equipped to deliver such service since most locations have tons of the analog ports on their switches and channel banks as this is how they deliver typical voice service, and the channel banks are often used for carrying a bunch of circuits into a given area. Now, if you get a direct digital connection (almost all E&M and all PRI), it looks much simpler as: Digital +-------+ +-----+ | | | | | Telco |========================/ T1 /======| USR | |Switch | | TC | | | | | +-------+ +-----+ which of course (a) has no extra analog conversions which suits x2, and (b) has a single circuit and thus rarely has individual channel problems (except in interesting failure modes) but is either entirely up or down. Unfortunately, although it looks like you could just pull out the analog pairs and channel bank, to the telco this is a completely different beast. They may have to home you into a different switch which has the necessary digital ports rather than analog ports, and/or re-run the cabling and stuff, so they're going to treat this as a newly design circuit. If I had my druthers I'd never buy anything but E&M or PRI, but due to economics, ground start is simply a lot less expensive in some places. I would never recommend a loop start configuration as it provides no supervision for call processing and no advantages over ground start. > Not that the PRI's are a picnic either - just less awful. The phone company > seems not to be able to afford?/acquire? any PRI test sets and there is a > fair amount that can be set wrong and the PRI won't work. We now routinely > use an Ascend PL400 as a test set :) - I won't get into what that says > about the USR diagnostics and setup friendliness. Yeah, I'm hoping that they will break out the Q.931 messages in ASCII in a future release rather than the hex dumps that are provided now. > PRI's make sense here > because Bell Atl prices them lower than Channelized T1's. Yes, BA is one of the key carriers that has been pushing ISDN service, although they've been making a lot of rumblings lately about trying to apply new charges that they haven't in the past. We've found Ameritech and Pac Bell to be good as well, although Pac Bell is seriously trying to get out of it recently as they've just realized they aren't making any money :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Pete Ashdown <pashdown@xmission.com> writes: > Nope. It looks just like a disconnect. The next thing to verify would be the modem disconnect reason - at least it would let you know for sure that if it was the NETServer requesting the disconnect (rcvdGatewayDiscCmd from the MIB) or something else. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

> Rick <rallan@monmouth.com> writes: > > The only difference you may see with a T1 termination circuit is that > due to the robbed-bit you'll most likely have on the circuit (used for > signaling on each DS0, as opposed to the decided D-channel on a PRI > circuit) you've really only got 56K pipes for each DS0. This may > result in a 'tick' or due drop in connection rates. But for x2, a > 'tick' is only 1.3K and depending on the quality of the circuit, the > upper bandwidth may have already had to be dropped, so the end user > may not actually see a difference. If they do, it will likely be a > small (1.3 or 2.6K) drop in rate. > But x2 is currently limited to 53k by the FCC, so I guess it won't make a difference at this time. The problem I'm having right now (North eastern NJ) is that x2 connections are made sometimes, at 48k for example, and othertimes not. Customers from the local town call up with an x2 sportster and get disconnected immediately (NO CARRIER). And it seems when v.34 connections are attempted, the rates are more like 21k and 26k, not 31k and 33.6k anymore. Something has obviously changed these past few weeks and I'm not sure what. I have PRI lines here and the local phone switch is supposedly completely digital, perhaps there is some problem with the way the copper lines are run around here to the customers? I even have a customer that reports making an x2 connection to me about every 1 in 10 attempts, where as to a competitor he gets through every single time. USRobotics technicians tested out my TC from their location one day, and were only able to connect sometimes.. later in the day or the next day they were able to connect everytime. - lv

Laszlo Vecsey <master@internexus.net> writes: > But x2 is currently limited to 53k by the FCC, so I guess it won't make a > difference at this time. Um, well, please don't get pulled in too much by this phrase that USR is slapping onto each and every statement they make - it's beginning to achieve "mantra" status. Yes, the FCC has a long-standing regulation on power that the hub can generate, and yes due to the current x2 implementation that has an effective limit on x2 connections of about 53K, but that is independent of what a robbed-bit path will do to your capabilities. Also, the FCC is _not_ actually limiting connections to 53K - it is just limiting power which has a secondary impact on connection rates. There's nothing to say that improvements to the encoding scheme might not be able to achieve the higher rates within the current power restrictions eventually. But as far as the T1, the robbed bit effectively removes a portion of the bandwidth that the x2 encoding would otherwise be able to use, and the ability to reach its highest rates requires that bandwidth even with the current power requirements. Thus, you end up reducing the available working bandwidth in general, which could cause a user to drop 1.3-2.6K even if the highest rate they would have been able to achieve otherwise is only in the mid-40s. Or conversely, if a line is marginal (say it only gets x2 50% of the time) then calling into a T1 might only achieve x2 25-30% of the time. Yes, you'll also have users who see no difference if in fact their lines are great and the loss of the bit doesn't really affect what they are able to get through their line. > The problem I'm having right now (North eastern > NJ) is that x2 connections are made sometimes, at 48k for example, and > othertimes not. Customers from the local town call up with an x2 sportster > and get disconnected immediately (NO CARRIER). And it seems when v.34 > connections are attempted, the rates are more like 21k and 26k, not 31k > and 33.6k anymore. A few general suggestions are to ensure that both you and your customers are running on the latest code. (It is very important that the Sportster users be running at least the 3/21 code as it improved many things over the originally shipped 2/20 code - at least for the external/internal standard Sportsters - dates are slightly different for other models). Also, if you have just updated your hub to x2-capable code, or recently updated to later code, I would suggest that you issue a command to all modems to restore to factory defaults (probably hardware flow control version - &F1) and then reprogram them with any special settings you may run with. For those who get disconnected immediately it would be helpful to know why they are getting disconnected (what is the reason shown by the modem). > Something has obviously changed these past few weeks > and I'm not sure what. I have PRI lines here and the local phone switch is > supposedly completely digital, If you've got PRI service then yes you're going to have to be digital throughout or else the telco can't deliver digital calls. Have you verified that you are not getting any circuit level errors (framing, clock slips, errored seconds, etc...?) There might be a failing component in the circuit path which is injecting errors. > perhaps there is some problem with the way > the copper lines are run around here to the customers? I even have a > customer that reports making an x2 connection to me about every 1 in 10 > attempts, where as to a competitor he gets through every single time. Well, certainly the "last mile" has a large impact on how an x2 modem will behave. For this customer, it would be interesting to know if both you and the competitor are local calls - often making a local versus a long distance call is routed differently in the local phone network and can yield very different results. > USRobotics technicians tested out my TC from their location one day, and > were only able to connect sometimes.. later in the day or the next day > they were able to connect everytime. Hmm - it does kind of sound like something on your side then. Have you had your telco connect in at their demarc and test back to their equipment with something like a Firebird in order to stress the circuit and look for errors? -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

> This is exactly what we're seeing with customers dialing in with analog > modems. I have the latest code in the TC box and the latest in my x2 > Sportster and they connect at mediocre rates (<28.8) when I call into the > box. Customers call my bank of analog clones, mostly rockwell chipset > modems, and get 28.8 or higher but 19.2 or 21.6 when they call the TC modems. > I've been talking with some bell atlantic people this past week, and just got off the phone with another one. Basically they tell me that they can not gaurantee any type of bandwidth over analog calls.. no way of eliminating or reducing the amount of analog conversions... the customer needs to go ISDN if they want reliable, consistent speed. They tell me there are most definately conversions going on before the analog calls reach the PRI (for local calls) I've found that long distance calls (USRobotics tech people for example) seem to connect fine with x2. I supplied them with some client phone numbers and they're going to be looking into and testing some routes tomorrow to see whats up. You would think that a PRI line would provide cleaner analog calls (compared to copper lines running to courier type modems), but apparently it doesn't. Too many conversions going on locally perhaps. I've noticed the drop in connection speed (from 31k, 33.6k consistently) to 28.8 and more like 26k after upgrading the quad modem cards and netserver to newer versions to support x2. Perhaps the problem is software related? - lv

Laszlo Vecsey <master@internexus.net> writes: > I've been talking with some bell atlantic people this past week, and just > got off the phone with another one. Basically they tell me that they can > not gaurantee any type of bandwidth over analog calls.. This is basically true. Most telcos will accept complaints for analog lines that are not achieving 9600 baud, but that's it. > . no way of > eliminating or reducing the amount of analog conversions... I did hear of someone who called in specifically requesting that he be given pure copper POTS (plain old telephone service) service, which may or may not be required by tariff. In his case, they disconnected him from a mutiplexor in his building (which introduced another A/D) and instead ran him as straight copper which gave him a working circuit. Of course, your mileage may vary. > They tell me > there are most definately conversions going on before the analog calls > reach the PRI (for local calls) I've found that long distance calls > (USRobotics tech people for example) seem to connect fine with x2. This depends very much on local configurations. There will always be a single A/D which is at the end of the last mile of the customer phone circuit. But whether or not it gets converted more than once within the telco network itself is dependent on the equipment in use, how it is routed and so on. And this will differ customer by customer. > I > supplied them with some client phone numbers and they're going to be > looking into and testing some routes tomorrow to see whats up. You would > think that a PRI line would provide cleaner analog calls (compared to > copper lines running to courier type modems), but apparently it doesn't. > Too many conversions going on locally perhaps. If called from the same source number, then yes, you should certainly get better connections over the PRI than over an analog circuit at the same server location. > I've noticed the drop in connection speed (from 31k, 33.6k consistently) > to 28.8 and more like 26k after upgrading the quad modem cards and > netserver to newer versions to support x2. Perhaps the problem is software > related? Hmm, I really haven't seen much difference in my various test locations - inasmuch as the V.34 support in the current (x2-capable) modem code on the hubs behaves pretty much the same as before in general. One thing you might check - if the user's lines are close to x2 capable, such that the modem attempts to get x2, but then during the training process has to fall back to V.34, then yes I've seen problems getting as good a V.34 connection as if it was tried right in the beginning. Disabling x2 in the client modem and forcing it to be truly just a V.34 modem (S32=34 for a Sportster, some other setting for the Courier) might be worth trying. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

On Mon, 21 Apr 1997, Pete Ashdown wrote: > David Bolen said once upon a time: > > > >Pete Ashdown <pashdown@xmission.com> writes: > > > >> This didn't happen under 3.3.28. I looked through the code of "sz" and the > >> only thing I suspected is that it resets the tty mode back to its original > >> settings. Maybe the Netserver takes this too much to heart. > > > >Is there anything interesting in the NETServer syslog as to why it > >terminated the call? > > Nope. It looks just like a disconnect. > > We found that having the UNIX term set to ANSI doesn't do the hangup, but > having it set on VT100 does. Bizarre. > Trussing the shell at the moment that the sz finishes shows that it exits because it received a SIGHUP from somewhere, which it doesnt receive when the terminal is ANSI (not a lot of other terminal types have been tried, other than ansi and vt100)... Jason Kohles -- System Administrator -- XMission Internet Access robobob@xmission.com (at work) robobob@mindwell.com (at play) "We're not surrounded, we're in a target-rich environment!"

I've got two NETserver cards I'm going to be putting into production in the next few weeks and I have a few questions. One shipped with 3.4.23 and the other shipped with 3.3.28 - I want them to be running the same version, so I need to upgrade or downgrade one of the two. Most importantly, is 3.4.23 compatible with Livingston RADIUS 2.0? I've heard it both ways. Also, how do I get an accurate memory listing? Both cards show only having 4 megs of RAM, but I've pulled them out of the slots and the extra SIMM is present, so they have at least 8. This one shipped with 3.4.23, so I would hope it actually has 16: Command> version U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.4.23 Build date: Mar 6 1997 Build time: 10:12:26 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Standard Licensed for 60 ports. Command> show mem System memory 4099571 bytes - 3373984 used, 725587 available Free blocks (block_size:count): 32:1 48:0 80:0 160:0 Real Available Memory: 725619 System nbufs 500 - 11 used, 489 available What kind of memory do these cards take? Looks like an ordinary SIMM, but it doesn't say how fast, etc. -- Dave Pifke, dpifke@slip.net

Dave Pifke said once upon a time: > >I've got two NETserver cards I'm going to be putting into production in the >next few weeks and I have a few questions. One shipped with 3.4.23 and the >other shipped with 3.3.28 - I want them to be running the same version, so I >need to upgrade or downgrade one of the two. I've just downgraded my previously upgraded 3.4.23 servers to 3.3.28. The new version created more problems than it fixed.

Peter Evans <peter@gol.com> writes: > use tcm to ask the netserver how much dram it has. > > 3.2.28 seems to report it has 8mb even when it has 16 though, ^_^;; Prior to 3.4.x it incorrectly reports the memory representative of the build (e.g., 3.2.x (x<20) will report 4MB, 3.2.y (y>=20) will report 8MB). With the 3.4.x series it properly determines memory and reports it via management. I believe TCM may have a problem during an upgrade where it doesn't properly require the slot information and you'll still see old information if you've just downloaded 3.4.x. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Once upon a time Dave Pifke shaped the electrons to say... >Most importantly, is 3.4.23 compatible with Livingston RADIUS 2.0? I've heard >it both ways. Since RADIUS 2.0 is RFC compliant, if 3.4.23 isn't compatible with RADIUS 2.0 then it wouldn't be RFC compliant. I kind of doubt that. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588

All, For those of you using the Total Control Chassis with Dual T1 Cards for your phone lines, is there any special setup on the T1 card that needs to be modified from default settings or does that normally work...? While I'm asking :) are there any other caveats to setting up the chassis using the T1 option for phone lines to be aware of...? Thanks Timothy

Dave Pifke wrote: | Most importantly, is 3.4.23 compatible with Livingston RADIUS 2.0? I've heard | it both ways. should be. We are running er ... 12(?) netservers at 3.4.23 I think you need it for MPIP ^_^; | Also, how do I get an accurate memory listing? Both cards show only having 4 | megs of RAM, but I've pulled them out of the slots and the extra SIMM is | present, so they have at least 8. This one shipped with 3.4.23, so I would | hope it actually has 16: use tcm to ask the netserver how much dram it has. 3.2.28 seems to report it has 8mb even when it has 16 though, ^_^;; | What kind of memory do these cards take? Looks like an ordinary SIMM, but it | doesn't say how fast, etc. no parity. non-edo, single-sided is nice as its parallel to the m/b. P ----* -- O_u \\ Ciscomancer // \\ Global OnLine Japan U \Beh! \\ Postmonster // Ukyu? \\ Engineering Dept.

Timothy Deem said once upon a time: > For those of you using the Total Control Chassis with Dual T1 Cards >for your phone lines, is there any special setup on the T1 card that needs >to be modified from default settings or does that normally work...? You need to set the framing and format via the console or TCM. This is usually ESF/B8ZS. Ask your phone company to set it to that, and if they can't ask them what they use. > While I'm asking :) are there any other caveats to setting up the >chassis using the T1 option for phone lines to be aware of...? If the phone co. is using AT&T 5ESS switches, you'll need to get the right number of call digits programmed in each modem. If they're Nortel DMS100's, this isn't as important, but you should probably do it anyway.

Peter Evans said once upon a time: > should be. We are running er ... 12(?) netservers at 3.4.23 > I think you need it for MPIP ^_^; Where did you get the MPIP server?

On Mon, 21 Apr 1997, Pete Ashdown wrote: : >I'm pretty sure (but not positive) that the system must still be fed : >by PRI circuits to accept the digital ISDN call that will termination : >on the quad card. : : It would be great if it worked off of DSS. Supposedly the Ascend equipment : can terminate 56K ISDN calls from DSS. US Worst offers BRI in some areas : that they don't offer PRI (go figure). Yes, Ascends can do this, and so can PM3s by what I'm told. The 56K data path available via robbed-bit signaling is capable of carrying a 56,000 bps ISDN data (or Data Over Voice Bearer Service) call. ===== == Todd Vierling (Personal tv@pobox.com; Business tv@iag.net) Foo-bar-baz! == == System administrator/technician, Internet Access Group, Orlando Florida == == Dialups in Orange, Volusia, Lake, Osceola counties - http://www.iag.net ==

Brian Elfert said once upon a time: >On Tue, 22 Apr 1997, Pete Ashdown wrote: > >> I've just downgraded my previously upgraded 3.4.23 servers to 3.3.28. The >> new version created more problems than it fixed. > >What kinds of problems are you seeing with the 3.4.23? A high rate of "mystery hangups" with all protocols Hangups after ZModem and other shell programs quit (but not the shell itself) No resolution of extreme Quake lags (pings from 1000-8000!) No resolution of Framed-Route subnet size The only thing it fixed was UDP streams with an MTU of 1500. Apparently that didn't make much of a difference on Quake.

Currently I have a small local network, 10baseT switched, with a Cisco 2511 router to a Kentrox CSU/DSU to the Internet. Is it feasible to eliminate the Cisco and Kentrox, and have the TC act as a gateway to the Internet if I get a Dual T1 card? How much does one of these cost.

On Wed, 23 Apr 1997, Pete Ashdown wrote: > Brian Elfert said once upon a time: > > >On Tue, 22 Apr 1997, Pete Ashdown wrote: > > > >> I've just downgraded my previously upgraded 3.4.23 servers to 3.3.28. The > >> new version created more problems than it fixed. > > > >What kinds of problems are you seeing with the 3.4.23? > > A high rate of "mystery hangups" with all protocols > Hangups after ZModem and other shell programs quit (but not the shell > itself) > No resolution of extreme Quake lags (pings from 1000-8000!) > No resolution of Framed-Route subnet size > > The only thing it fixed was UDP streams with an MTU of 1500. Apparently > that didn't make much of a difference on Quake. > try a MTU of 576, that helped quake a bit for us. 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

Brian said once upon a time: >try a MTU of 576, that helped quake a bit for us. The problem with getting these Win95 users to set the MTU is that they put up a lot of resistance to changing their "sacred" (or scared as the case may be) registry settings. We've had a couple people leave over this issue and they never cracked the registry settings once.

Well, I think I also saw that. Does anyone know about this? I heard Netserver could do that with Merit Radius. If anyone who can use this feature with Merit, please give me example configuration file to me. For example, users, authfile,.... And when I tried to upgrade 8mb to 16mb with Netserver PRI, munich board and High Speed NIC, the led turned red. There is special ram to upgrade? I used 60nano, non-parity 16mb SIMM. From Seoul, Seob On Sun, 20 Apr 1997, Brian wrote: > On Sat, 19 Apr 1997, MegaZone wrote: > > > Once upon a time JungSeob Lee shaped the electrons to say... > > > What I want to know is this. With Netserver 3.3 or high and Livingston's > > >Radius 2.0, to implement multiple ip pool for each group. Does anyone > > > > > > Neither RADIUS nor ComOS supports multiple IP pools. > > > > You would have to hack RADIUS to fake it. > > > > -MZ > > -- > > Livingston Enterprises - Chair, Department of Interstitial Affairs > > Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951 megazone@livingston.com > > For support requests: support@livingston.com <http://www.livingston.com/> > > Snail mail: 4464 Willow Road, Pleasanton, CA 94588 > > > > > hmm, i remember seeing in the Netserver 3.4 book, a radius entry using > something like the "IP-Address-Pool-Name" attribute, and then setting a IP > Address pool on the Netserver........might have been enhanced radius dont > know...... > > 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 > > >

On Wed, 23 Apr 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >try a MTU of 576, that helped quake a bit for us. > > The problem with getting these Win95 users to set the MTU is that they put > up a lot of resistance to changing their "sacred" (or scared as the case > may be) registry settings. We've had a couple people leave over this issue > and they never cracked the registry settings once. > O, I was using RADIUS to set the MTU, I suppose the distant end connection doesnt HAVE to change to that though, and I guess by what you tell me, Win95 doesnt do what you "request" but rather you have to change via the registry 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

Is anyone else going to the USR training in Chicago beginning May 5th? Does anyone who has been to USR training have any advice? Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

I attended the installation and configuration class in Minneapolis in April. I went for 3 days and skipped the 2 days of the Netserver. It was very beneficial and very much worth the time involved. I highly recommend attending. They provide 3 manuals about 1 1/2" thick on the technical aspect of the software and hardware. Supposedly if you attend you can take the certification test at a Drake Testing Center that allows you to skip level 1 support. There is at least 1 teacher of the class lurking on this list. Maybe he wants to put in his 2 cents? At 11:12 AM 4/24/97 +0000, you wrote: >Is anyone else going to the USR training in Chicago beginning May >5th? > >Does anyone who has been to USR training have any advice? > > >Wayne Barber - barberw@tidewater.net >Internet System Administrator >Coastal Telco Services > >

: For those of you using the Total Control Chassis with Dual T1 Cards : for your phone lines, is there any special setup on the T1 card that needs : to be modified from default settings or does that normally work...? The defaults are for a particular type of phone-line setup; you have to get the details on your type of T1 (signalling types, timing stuff, &c.) from the carrier. Our configuration, with BellSouth, was completely different from the default, for example. --- Mark R. Lindsey, mark@datasys.net DSS Online Network Engineer (912) 241-0607, Fax: 241-0190

Can anyone tell me what causes the v32 cleardown as a disconnect reason? I've got a customer this is happening to, and I can't find it in any of my USR documentation. Thanks, Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

On Fri, 25 Apr 1997, Bob Purdon wrote: > Can anyone tell me how I can get a string output before a PPP session > starts? So far we look something like this: > > login: <user> > Password: <pass> > PPP Session from X to Y starting... > > but for historical reasons, we need to look like this: > > login: <user> > Password: <pass> > > > PPP Session from X to Y starting... > > Our existing user scripts look for the '>' and will fail without it. > I've yet to find a way to get it in there... Any ideas? If you're using RADIUS, you can add a challenge prompt in radiusd that is simply '>'. Anyone using a scripted login will have to send a <CR> to start PPP there, however. Regards, Charles Hill

On Fri, 25 Apr 1997, Brian wrote: > We have ALOT of available lines in our PRI's not being used, and lots of > modems not in use, on our USR TC Hub. Everyone now and then we will dial > in and get a fast busy. i am told that this means that the phone company > has placed the pri out of service for an instant. is this true? anyone > else get unexplainable fast busys (or slow even), when they have plenty of > lines to burn? should I be worried or is this typical? it goes away > within 2 minutes or so. I've heard that the DMS-100 had/has a software bug that causes this when the switch is heavily loaded. This is a possibility. Which is why we are going through our telcos GTD-5 with currently has a lower load. Just a thought... -- Aloha, Sherwood

Okie.. fixed. Bill > > > > > Our existing user scripts look for the '>' and will fail without it. > > > I've yet to find a way to get it in there... Any ideas? > > > > If you're using RADIUS, you can add a challenge prompt in radiusd that > > is simply '>'. Anyone using a scripted login will have to send a <CR> to > > start PPP there, however. > > Thanks, I'll see what I can find. I did a search for that type of thing > last week but came up empty. Don't suppose you'd have sample configs that > show how it's done? The <CR> is no problem - they send that anyway. > > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > > > -- bill@xmission.com http://www.xmission.com/~bill/ "I wish people who have trouble communicating would just shut up." ---Tom Lehrer

We have ALOT of available lines in our PRI's not being used, and lots of modems not in use, on our USR TC Hub. Everyone now and then we will dial in and get a fast busy. i am told that this means that the phone company has placed the pri out of service for an instant. is this true? anyone else get unexplainable fast busys (or slow even), when they have plenty of lines to burn? should I be worried or is this typical? it goes away within 2 minutes or so. 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

Bob Purdon <bobp@gremlin.southcom.com.au> writes: > Thanks, I'll see what I can find. I did a search for that type of thing > last week but came up empty. Don't suppose you'd have sample configs that > show how it's done? The <CR> is no problem - they send that anyway. You shouldn't need to use a challenge - just include a "Reply-Message" attribute in the authentication answer, and it should be displayed as output to the user as they are authenticated. The Reply-Message may be easier to configure for a particular RADIUS server because it's just another attribute, as opposed to requiring that the server generate a different type of packet type in the response, and then will have to actually authenticate on the second request that the response to the challenge will generate. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

On Fri, 25 Apr 1997, Brian wrote: > We have ALOT of available lines in our PRI's not being used, and lots of > modems not in use, on our USR TC Hub. Everyone now and then we will dial > in and get a fast busy. i am told that this means that the phone company > has placed the pri out of service for an instant. is this true? anyone There is no telling whether it is on your end or theirs. It could mean that their CO has no free outgoing lines available. > else get unexplainable fast busys (or slow even), when they have plenty of > lines to burn? should I be worried or is this typical? it goes away > within 2 minutes or so. If its fast, that is fone co. reorder tone and you cant do anything about that. If its slow and you have lines to use, then there is a problem. ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger 713-772-6690 jake@ams.com Advanced Medical Systems, Inc. jake@uh.edu Houston, Texas http://www.ams.com/~jake ~~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ One should not be measured by his/her ascii art ability.

"Wayne Barber" <barberw@tidewater.net> writes: > Can anyone tell me what causes the v32 cleardown as a disconnect > reason? I've got a customer this is happening to, and I can't find it > in any of my USR documentation. Taking a few liberties with the exact terminology, a v.32 "cleardown" is when the modems execute a speed shift to an invalid speed, normally used as a way to specifically force both ends to disconnect. I think it's actually a message communicating the desire to shift to a new rate where the rate is "0". One common reason for modems to do this is if the line is particularly bad and they can't come to an agreement on what rate to use over the line. This can occur either during the initial training of a call, or during the session if the modems have to retrain, or if under V.34 they are shifting around trying to settle on a better speed. It can also happen if you have speed restrictions set in one of the modems (such as using &U/&N with USR modems) which doesn't allow the desired speed to be used, and the modems have to disconnect because they can't use the speed they want to, although I believe that on the hub side you might get an "InvalidSpeed" disconnect reason in that case. Oh, it's also used if you disable modulation types that the client modem has to use (such as if you disable non-x2 modulations on an x2 node). The Sportster will indicate this failure as a "GSTN cleardown". -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Hi All, Can anyone tell me how I can get a string output before a PPP session starts? So far we look something like this: login: <user> Password: <pass> PPP Session from X to Y starting... but for historical reasons, we need to look like this: login: <user> Password: <pass> > PPP Session from X to Y starting... Our existing user scripts look for the '>' and will fail without it. I've yet to find a way to get it in there... Any ideas? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

On Fri, 25 Apr 1997, Brian wrote: > We have ALOT of available lines in our PRI's not being used, and lots of > modems not in use, on our USR TC Hub. Everyone now and then we will dial > in and get a fast busy. i am told that this means that the phone company > has placed the pri out of service for an instant. is this true? anyone > else get unexplainable fast busys (or slow even), when they have plenty of > lines to burn? should I be worried or is this typical? it goes away > within 2 minutes or so. The explanation given by Southwestern Hell is that a fast busy indicates either a full PRI or an "All Circuits are Busy" state. I would open a ticket at the telco for this problem so they are aware of it. If you don't complain they'll never fix it. Chad Scott | chad@txdirect.net Systems Administrator | Voice 210-308-9800 x206 Internet Direct, Incorporated | FAX 210-308-9240 Finger chad@txdirect.net for PGP Public Key

This netserver has a 4mb simm, and another thinner simm in it.. I'm assuming I have to replace that one with the 16mb simm. Is the netserver supposed to take longer to boot with the new ram? It seems to blink green forever... any other ram combinations show double red solid when I reinsert the card. Does the netserver require a certain type of simm? (size, parity, speed)

I used a different 16mb simm, all is well. Perhaps the netserver has a problem with parity chips?

When I dial up with 3.4.23 running, a route is no longer automatically set. I'm using merit radius and a conf file based on the example one, and it works fine with 3.3.28. What has changed? Only other thing that comes to mind is that I used to be running 3.4.23 when the netserver had only 4mb ram, and it was working ok... only difference now is that I've installed the 'required' 16mb ram, the totalservice docs mention that the extra memory is only needed to enable some new features. - lv

> > Our existing user scripts look for the '>' and will fail without it. > > I've yet to find a way to get it in there... Any ideas? > > If you're using RADIUS, you can add a challenge prompt in radiusd that > is simply '>'. Anyone using a scripted login will have to send a <CR> to > start PPP there, however. Thanks, I'll see what I can find. I did a search for that type of thing last week but came up empty. Don't suppose you'd have sample configs that show how it's done? The <CR> is no problem - they send that anyway. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

On Fri, 25 Apr 1997, Brian wrote: >We have ALOT of available lines in our PRI's not being used, and lots of >modems not in use, on our USR TC Hub. Everyone now and then we will dial >in and get a fast busy. i am told that this means that the phone company >has placed the pri out of service for an instant. is this true? anyone >else get unexplainable fast busys (or slow even), when they have plenty of >lines to burn? should I be worried or is this typical? it goes away >within 2 minutes or so. Fast busy or "network busy" means that your telco's central office switch is indicating that it is busy. Whether it is REALLY busy is up for speculation, but in either case intentionally caused or inadvertent, you need to get your telco involved, your clients won't be able to tell the difference (or care). Of course, the telco will say the problem is due to the way YOU are overloading THEIR circuits. BTW, do they have an affiliated telco supported ISP, and do their lines get fast busies. In most areas, you can and should demand equal quality of service. Good Luck.

On Sat, 26 Apr 1997, Laszlo Vecsey wrote: > When I dial up with 3.4.23 running, a route is no longer automatically > set. I'm using merit radius and a conf file based on the example one, and > it works fine with 3.3.28. What has changed? If you're trying to use a framed-route statement with Radius, it won't work. USR confirms this is a bug in 3.4.23. Rumors are that 8.4.79 (a beta) fixes this. Brian

On Sat, 26 Apr 1997, Brian Elfert wrote: > On Sat, 26 Apr 1997, Laszlo Vecsey wrote: > > > When I dial up with 3.4.23 running, a route is no longer automatically > > set. I'm using merit radius and a conf file based on the example one, and > > it works fine with 3.3.28. What has changed? > > If you're trying to use a framed-route statement with Radius, it won't > work. USR confirms this is a bug in 3.4.23. Rumors are that 8.4.79 (a > beta) fixes this. Not really using framed-route, problem occurs for even the most generic dialup user that logs in for dynamic PPP. - lv

Laszlo Vecsey wrote: | This netserver has a 4mb simm, and another thinner simm in it.. I'm ^^^^^^^ flash. | assuming I have to replace that one with the 16mb simm. Is the netserver | supposed to take longer to boot with the new ram? It seems to blink green | forever... any other ram combinations show double red solid when I | reinsert the card. you took out the flash ^_^; So the thing can't boot and goes into lost-its-mind mode. That flashing green light is the netserver crying. | Does the netserver require a certain type of simm? (size, parity, speed) 16mb, NO PARITY, 60 or 70ns. Not EDO. it helps if its single sided due to space considerations. Peter ----* -- O_u \\ Ciscomancer // \\ Global OnLine Japan U \Beh! \\ Postmonster // Ukyu? \\ Engineering Dept.

Laszlo Vecsey wrote: > > I've substantially improved the tcview utility with some additional > features (combining show session and show all stats) into one easy to > interpret chart. This is a utility to quickly see who is logged onto a > netserver from the unix prompt; the !root password is hardcoded into the > binary at compile time. > > If you find any bugs, have suggestions, please let me know about them :> > > - lv > > #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj > $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1 > lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/) First thankx for the program, works like a charm. However, what is the format in the config.h file to enable multiple boxes. Right now it works fine for just one box. I would like to know how to have it do 5 boxes...thankx -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 908-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I'm getting these errors in my syslog.. what do they mean? Apr 27 19:13:06 Total-Control S42: error -19 setting remote ACCM Apr 27 19:13:08 Total-Control last message repeated 26 times - lv

--IMA.Boundary.585572268 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part I kinda doubt it as well. It works just fine, with the exception of vendor-specific attributes (which can be added to the dictionary). Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________ Reply Separator _________________________________ Author: MegaZone <megazone@livingston.com> at Internet Once upon a time Dave Pifke shaped the electrons to say... >Most importantly, is 3.4.23 compatible with Livingston RADIUS 2.0? I've heard >it both ways. Since RADIUS 2.0 is RFC compliant, if 3.4.23 isn't compatible with RADIUS 2.0 then it wouldn't be RFC compliant. I kind of doubt that. -MZ -- Livingston Enterprises - Chair, Department of Interstitial Affairs Phone: 800-458-9966 510-737-2100 FAX: 510-737-2110 megazone@livingston.com For support requests: support@livingston.com <http://www.livingston.com/> Snail mail: 4464 Willow Road, Pleasanton, CA 94588 --IMA.Boundary.585572268 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 35E03F71; Wed, 23 Apr 97 07:43:35 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id HAA27059; Wed, 23 Apr 1997 07:25:41 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wK11a-0007Sc-00; Wed, 23 Apr 1997 06:19:50 -0600 Received: from bast.livingston.com [149.198.247.2] by mail.xmission.com with smtp (Exim 1.61 #1) id 0wK11V-0007RL-00; Wed, 23 Apr 1997 06:19:45 -0600 Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id FAA05834 for <usr-tc@mail.xmission.com>; Wed, 23 Apr 1997 05:17:06 -0700 (PDT) Received: (from megazone@localhost) by server.livingston.com (8.8.5/8.6.9) id FAA25829 for usr-tc@mail.xmission.com; Wed, 23 Apr 1997 05:17:11 -0700 (PDT) Message-Id: <199704231217.FAA25829@server.livingston.com> In-Reply-To: <E0wJmOJ-0000ZG-00@ferret.slip.net> from "Dave Pifke" at Apr 22, 97 01:44:15 pm Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me. Content-Type: text Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.585572268--

--IMA.Boundary.885572268 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Laszlo, You should leave in the thinner SIMM (yes, it's the Flash, although I've never seen the NETServer cry before :) ). The 4MB SIMM would be replaced by the 16MB SIMM, which brings the board total to 20MB. I don't know if you're aware, but USR sells a "Memory Upgrade Kit" which provides the right type of memory. The street price on those kits is basically the same as the cost for a off-the-shelf SIMM (unless you buy in Mondo-quantities), so it may be a viable -and cost effective- alternative to hunting down your own. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________ Reply Separator _________________________________ Author: Peter Evans <peter@gol.com> at Internet Laszlo Vecsey wrote: | This netserver has a 4mb simm, and another thinner simm in it.. I'm ^^^^^^^ flash. | assuming I have to replace that one with the 16mb simm. Is the netserver | supposed to take longer to boot with the new ram? It seems to blink green | forever... any other ram combinations show double red solid when I | reinsert the card. you took out the flash ^_^; So the thing can't boot and goes into lost-its-mind mode. That flashing green light is the netserver crying. | Does the netserver require a certain type of simm? (size, parity, speed) 16mb, NO PARITY, 60 or 70ns. Not EDO. it helps if its single sided due to space considerations. Peter ----* -- O_u \\ Ciscomancer // \\ Global OnLine Japan U \Beh! \\ Postmonster // Ukyu? \\ Engineering Dept. --IMA.Boundary.885572268 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 361F3640; Sat, 26 Apr 97 07:21:56 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id HAA24170; Sat, 26 Apr 1997 07:01:23 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wL5ue-0000Ac-00; Sat, 26 Apr 1997 05:45:08 -0600 Received: from gol1.gol.com [202.243.48.4] by mail.xmission.com with esmtp (Exim 1.61 #1) id 0wL5ua-0000AX-00; Sat, 26 Apr 1997 05:45:04 -0600 Received: (from peter@localhost) by gol1.gol.com (8.8.5/8.8.5) id UAA25559 for usr-tc@mail.xmission.com; Sat, 26 Apr 1997 20:45:02 +0900 (JST) Message-Id: <199704261145.UAA25559@gol1.gol.com> In-Reply-To: <Pine.LNX.3.96.970426044952.16632A-100000@micro.internexus.net> from "Laszlo Vecsey" at Apr 26, 97 04:53:15 am Organization: Global Online - Engineering Dept. +81-3-5341-8000 X-no-archive: yes X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.885572268--

--IMA.Boundary.395572268 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Ah...yes. The SIMMs must be 72-pin, 70ns or better, 4MB or 16MB NON-PARITY (and non-EDO) SIMMs. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________ Reply Separator _________________________________ Author: Laszlo Vecsey <master@internexus.net> at Internet I used a different 16mb simm, all is well. Perhaps the netserver has a problem with parity chips? --IMA.Boundary.395572268 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mailgate.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 361E5CE0; Sat, 26 Apr 97 06:23:58 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id GAA23829; Sat, 26 Apr 1997 06:03:23 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wL3z8-0003ne-00; Sat, 26 Apr 1997 03:41:38 -0600 Received: from micro.internexus.net [206.152.14.2] by mail.xmission.com with esmtp (Exim 1.61 #1) id 0wL3z5-0003nU-00; Sat, 26 Apr 1997 03:41:35 -0600 Received: from localhost (master@localhost) by micro.internexus.net (8.8.5/8.8.4) with SMTP id FAA17426 for <usr-tc@xmission.com>; Sat, 26 Apr 1997 05:41:34 -0400 In-Reply-To: <Pine.LNX.3.96.970426044952.16632A-100000@micro.internexus.net> Message-ID: <Pine.LNX.3.96.970426054030.17421A-100000@micro.internexus.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.395572268--

"Matthew S. Crocker" <matthew@crocker.com> writes: > Fast busy is sometimes know as 're-order busy' The Telco will generate a > fast busy when they cannot complete a call. This can be caaused by > several reasons. They don't have enough trunks to get from one switch to > another, Your circuit is in an error state, they have equipment problems > ... Note that it can also be caused by equipment problems or lack of resource on the total control end, particularly with a PRI circuit. Although simply being out of modems will cause the PRI card to response with a "user busy" release message (code 17), other types of problems may return other release message codes which will be interpreted by the telco as a failure to deliver the call and result in a reorder tone. If you're concerned about whether or not your equipment is seeing the call, and you are using the TCS 2.5.x release code (PRI 2.5.x and NMC 4.3.4) then you could enable the new traps on the PRI card (such as "callArriveEvent" or "callEvent") and you'll get a trap the moment the PRI card thinks it has a call regardless of whether that call will eventually get delivered to a modem or NETServer. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

--IMA.Boundary.306572268 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part On 4/19/97 @ 9:36am, MegaZone <megazone@livingston.com> said... >Once upon a time JungSeob Lee shaped the electrons to say... >> What I want to know is this. With Netserver 3.3 or high and Livingston's >>Radius 2.0, to implement multiple ip pool for each group. Does anyone > > >Neither RADIUS nor ComOS supports multiple IP pools. > >You would have to hack RADIUS to fake it. > >-MZ ...BUT, the next release of NETServer code will support multiple IP address pools locally. You may have seen a reference to added RADIUS parameters in the v3.4 release notes, although it was not included in the v3.4 code. Yet another difference between ComOS and the NETServer. :) Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --IMA.Boundary.306572268 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 359A30C0; Sun, 20 Apr 97 00:01:00 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id XAA22141; Sat, 19 Apr 1997 23:43:12 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wIoOg-0002jZ-00; Sat, 19 Apr 1997 22:38:42 -0600 Received: from bast.livingston.com (bast.livingston.com [149.198.247.2]) by mail.xmission.com (8.8.5/8.7.5) with ESMTP id WAA10467 for <usr-tc@mail.xmission.com>; Sat, 19 Apr 1997 22:38:31 -0600 (MDT) Received: from server.livingston.com (server.livingston.com [149.198.1.70]) by bast.livingston.com (8.8.5/8.6.9) with ESMTP id VAA13304 for <usr-tc@mail.xmission.com>; Sat, 19 Apr 1997 21:36:23 -0700 (PDT) Received: (from megazone@localhost) by server.livingston.com (8.8.5/8.6.9) id VAA12181; Sat, 19 Apr 1997 21:36:29 -0700 (PDT) Message-Id: <199704200436.VAA12181@server.livingston.com> Organization: WPI Discordian Society, Undocumented Cabal of the Accursed Saint Shiranto Joe X-search: If you have Atari Jaguar or Lynx HW/SW you'd like to sell, email me. Content-Type: text Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.306572268--

--IMA.Boundary.406572268 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Rick, "tsec43.zip" is the Security & Accounting Server v4.3, USR's own RADIUS server that runs on top of a relational database. If you already have a RADIUS server up and running, this isn't needed. Some of things that it adds is Resource Management, the concept of "user groups" or "user classes", scripted proxies to 3rd party authentication servers, fairly easy maintenance and support for new attributes (relational database can add fields to all users in one transaction), and pretty good reports generation (as a result of the relational database being able to crunch numbers well). The file "tcmwac43.zip" is a very stripped down version of the above server that provides only the accounting portions of the package on a Windows 95/NT operating system, and logs data to a flat file, which is included in our NMC/TCM bundles to give new TCENH users something to begin working with until they decide on a product they want to use. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ______________________________ Reply Separator _________________________________ Author: Rick <rallan@monmouth.com> at Internet We have recently installed some new TC hubs and have them running fine using our radius server that we already had. I see that USR has their own software for security and accounting. I am a little confused with regards to which does what. I see they have a file called tsec43.zip which it says does security and accounting. I also see they have another file called tcmwac43.zip which says it does accounting. If I already have a radius server running other software do I need the tsec43.zip or can I just install the tcmwac43.zip? Also, what does the tcmwac43.zip add that the tsec43.zip does not have??? thankx -- Rick --IMA.Boundary.406572268 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 3598C330; Sat, 19 Apr 97 22:23:31 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id WAA21064; Sat, 19 Apr 1997 22:05:43 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wImo3-0006I3-00; Sat, 19 Apr 1997 20:56:47 -0600 Received: from shell.monmouth.com (root@shell.monmouth.com [205.164.220.9]) by mail.xmission.com (8.8.5/8.7.5) with ESMTP id UAA24168 for <usr-tc@mail.xmission.com>; Sat, 19 Apr 1997 20:56:42 -0600 (MDT) Received: from rick.monmouth.com (rick.monmouth.com [206.62.47.45]) by shell.monmouth.com (8.8.4/8.7.3) with SMTP id WAA18626 for <usr-tc@mail.xmission.com>; Sat, 19 Apr 1997 22:54:27 -0400 (EDT) Message-ID: <335985E6.5858@monmouth.com> Organization: Monmouth Internet X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.406572268--

--IMA.Boundary.606572268 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part >He offered it to me but since our netserver cards do not have 16megs I >had to decline. I take it the version he was referring to was >3.4.79......... Yes, it was. That's the Engineering Release number for an equivalent BETA now out. It'll be releasing in a few weeks. And it DOES need 16MB RAM to run effectively. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --IMA.Boundary.606572268 Content-Type: text/plain; charset=US-ASCII; name="RFC822 message headers" Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Content-Disposition: attachment; filename="RFC822 message headers" Received: from usr.com (mail.usr.com) by robogate2.usr.com with SMTP (IMA Internet Exchange 2.02 Enterprise) id 35825780; Fri, 18 Apr 97 20:52:56 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id UAA06326; Fri, 18 Apr 1997 20:35:08 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.61 #1) id 0wIOuQ-0005j9-00; Fri, 18 Apr 1997 19:25:46 -0600 Received: from shell.monmouth.com (root@shell.monmouth.com [205.164.220.9]) by mail.xmission.com (8.8.5/8.7.5) with ESMTP id TAA21779 for <usr-tc@mail.xmission.com>; Fri, 18 Apr 1997 19:24:55 -0600 (MDT) Received: from tech1 (tech1.monmouth.com [206.250.247.2]) by shell.monmouth.com (8.8.4/8.7.3) with SMTP id VAA15321 for <usr-tc@mail.xmission.com>; Fri, 18 Apr 1997 21:22:37 -0400 (EDT) Message-ID: <33581EF4.6DED@monmouth.com> Organization: Monmouth Internet X-Mailer: Mozilla 3.0Gold (WinNT; I) MIME-Version: 1.0 References: <Pine.LNX.3.93.970418184216.12829A-100000@ns1.shreve.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-usr-tc@xmission.com Precedence: bulk Reply-To: usr-tc@mail.xmission.com --IMA.Boundary.606572268--

Laszlo Vecsey <master@internexus.net> writes: > Apr 27 19:13:06 Total-Control S42: error -19 setting remote ACCM > Apr 27 19:13:08 Total-Control last message repeated 26 times I haven't seen this message myself, but it appears to be related to using PPP framing in the modem. When you have such support enabled ('set pppmodem on') one of the things that the NETServer needs to communicate down to the modem (after it is negotiated) is the ACCM value (Async-Control-Character-Map). The ACCM is a mask that indicates which characters need to be automatically prefixed when transmitting over the line (for example, XON and XOFF when running over a software flow controlled link). Since the modem is doing the framing, it has to know which characters to construct that way, but the ACCM is an LCP negotiated option (which is handled by the NETServer). The message would at least appear to indicate that the NETServer was unable to communicate this information to the modem. It likely won't affect the session (since most everyone uses an ACCM of 0 nowadays) but it does probably give a hint that something is amiss with the modem<->NETServer communications. Could you be running a newer TCS release NETServer or modem code without the other matched up - sometimes there might be an issue with code from different system releases communicating properly, I suppose. Disabling PPP framing in the modem should also take care of this, although the NETServer will then be handling the PPP session which might result in some increased latency and/or load on the NETServer. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

------ =_NextPart_000_01BC542D.3AC6F470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, We just purchased one of the fire sale USR total control hubs. All of = the quad cards were "suppose" to have been flashed with the latest = software version and be X2 capable. The most we can get is 31K. We have = a Netserver I16 that handles our ISDN that was just loaded with the x2 = upgrade and it consistently gets 51K. How can we find out if the Quad cards have actually been upgraded to = X2? This same hub has a PRI card that was suppose to be flashed to be a T1 = card. Total Control Manger does not seem to think so however. Is there a = version number we can look at to see if knows it is a T1 card. If these seem like stupid question, I apologize in advance.. --Cindy Smith KTC - I-Net ------ =_NextPart_000_01BC542D.3AC6F470 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IgkEAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEkAYAkAEAAAEAAAAQAAAAAwAAMAIAAAAL AA8OAAAAAAIB/w8BAAAAPwAAAAAAAAD+QqoKGMcaEOiFC2UcJAAAAwAAAAQAAAAAAAAAGAAAAAAA AAA7RO6K+U3PEYhtREVTVAAAhI8hAAABCwAeAAIwAQAAAAUAAABTTVRQAAAAAB4AAzABAAAAGQAA AHVzci10Y0BtYWlsLnhtaXNzaW9uLmNvbQAAAAADABUMAQAAAAMA/g8GAAAAHgABMAEAAAAQAAAA VXNyLVRjIChFLW1haWwpAAIBCzABAAAAHgAAAFNNVFA6VVNSLVRDQE1BSUwuWE1JU1NJT04uQ09N AAAAAwAAOQAAAAALAEA6AQAAAB4A9l8BAAAAEAAAAFVzci1UYyAoRS1tYWlsKQACAfdfAQAAAD8A AAAAAAAA/kKqChjHGhDohQtlHCQAAAMAAAAEAAAAAAAAABgAAAAAAAAAO0TuivlNzxGIbURFU1QA AISPIQAAAAAAAwD9XwEAAAADAP9fAAAAAAIB9g8BAAAABAAAAAAAAALHQQEEgAEAIAAAAEhvdyB0 byB0ZWxsIGlmIFgyIGlzIGluc3RhbGxlZD8AtgoBBYADAA4AAADNBwQAHAAXABsAMQABAFgBASCA AwAOAAAAzQcEABwAFwAHADIAAQBFAQEJgAEAIQAAADYyQ0Q2MDc3Q0VCRkQwMTE4MTM2MDBBMDI0 RDFGODk2ABQHAQOQBgCUBQAAIAAAAAsAAgABAAAACwAjAAAAAAADACYAAAAAAAsAKQAAAAAAAwA2 AAAAAABAADkAMFG/sVVUvAEeAHAAAQAAACAAAABIb3cgdG8gdGVsbCBpZiBYMiBpcyBpbnN0YWxs ZWQ/AAIBcQABAAAAFgAAAAG8VFWxfHdgzWS/zhHQgTYAoCTR+JYAAB4AHgwBAAAABQAAAFNNVFAA AAAAHgAfDAEAAAAPAAAAY2luZHlvQGt0Yy5jb20AAAMABhCwVrqzAwAHECECAAAeAAgQAQAAAGUA AABIRUxMTyxXRUpVU1RQVVJDSEFTRURPTkVPRlRIRUZJUkVTQUxFVVNSVE9UQUxDT05UUk9MSFVC U0FMTE9GVEhFUVVBRENBUkRTV0VSRSJTVVBQT1NFIlRPSEFWRUJFRU5GTEFTAAAAAAIBCRABAAAA gwIAAH8CAABTAwAATFpGdYcPIBp3AAoBAwH3IAKkA+MCAGOCaArAc2V0MCAHE+UCgH0KgXVjAFAL AwtgQG5nMTAzMwumIOhIZWwJACwKogqECoBAV2UganVzBUBwZwhwD3EPsGQgAiATgG+QZiB0aBOA ZmkJcIwgcwdAE4BVU1IU8H5vAZADIAWgAjADYAMgaHB1YnMuD/AScBTGcbR1YRRwYwsRBCB3BJCB E4Aic3VwcG8PsKYiFhEW8GF2E4BiCeH7FTALYHMVEBRwA/AVABTzLQtgdAeQBUBzFNB0d68KwBOA GgAPoGkCICAAcOMUcBowIFgyGFEKsAJg+mUXQFQVEQRgE8EYwBhRFQOgZw/AIAQAIDMxWksXQCAT cRnjYQexdIUPsHIckSBJMTYU8X8boBnRHSAVsAQgCGEhQFP8RE4hhBxABCATowkAGDD1Gtp4HZAg GTAJwCPxHQMfGxAWcgCQE8AJ8HRseTcf8B9BBCA1H8ESukhv/wfgHwIe0RVAHSEIYB9hFOTMIFEY KCBEY3QYIBJwvyawGjMlFRRwGbEdgD8StP8eQB+BFZAHgBbyGdEEICCQ+FBSSRhTIugZJRmiHVHn GoYwBCCQVDEYUx4hFjObCFAWpE0RUSEhZG8Hke5uFjAVgAngbRmiFQALgG5rG/EW8ChAZRyRF0BJ nwQgFQEVYSCQHJZudQbQ9yEhHtUJAG80kCGxGbEz0fUpYmszkHcEICXRH4ExSB0SukkU4y/RM9Ns aWvzFXErEHBpFHAYEBvBHNEeLCFAHQAZUAkAZ2l60zhRHPFkdgBwYx4QJ2uYLS1DKPEmsFNtGxFB ErRLVEMgLSFALRcgsRK6EHEAQiAAAwAQEAAAAAADABEQAAAAAAMAgBD/////QAAHMFDRMudSVLwB QAAIMFDRMudSVLwBCwAPgAggBgAAAAAAwAAAAAAAAEYAAAAAA4UAAAAAAAADABGACCAGAAAAAADA AAAAAAAARgAAAAAQhQAAAAAAAAMAFIAIIAYAAAAAAMAAAAAAAABGAAAAAFKFAAC3DQAAHgA0gAgg BgAAAAAAwAAAAAAAAEYAAAAAVIUAAAEAAAAEAAAAOC4wAAMANYAIIAYAAAAAAMAAAAAAAABGAAAA AAGFAAAAAAAACwA+gAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAD+ACCAGAAAAAADAAAAA AAAARgAAAAARhQAAAAAAAAMAQYAIIAYAAAAAAMAAAAAAAABGAAAAABiFAAAAAAAAHgBQgAggBgAA AAAAwAAAAAAAAEYAAAAANoUAAAEAAAABAAAAAAAAAB4AUYAIIAYAAAAAAMAAAAAAAABGAAAAADeF AAABAAAAAQAAAAAAAAAeAFKACCAGAAAAAADAAAAAAAAARgAAAAA4hQAAAQAAAAEAAAAAAAAAHgA9 AAEAAAABAAAAAAAAAAMADTT9NwAAvzU= ------ =_NextPart_000_01BC542D.3AC6F470--

Cindy Smith said once upon a time: >We just purchased one of the fire sale USR total control hubs. All of = >the quad cards were "suppose" to have been flashed with the latest = >software version and be X2 capable. The most we can get is 31K. We have = >a Netserver I16 that handles our ISDN that was just loaded with the x2 = >upgrade and it consistently gets 51K. > >How can we find out if the Quad cards have actually been upgraded to = >X2? The Quad cards software revision should be 5.1.7. You also need to "unlock" X2 on the NMC card with a key. Does your NMC card show X2 as being enabled?