June 1997

: Some of our usr tc's seem to be spontaneously rebooting themselves. : Has anyone else observed this feature? No, but I've seen them spontaneously get mad at the LAN and refuse to talk to anybody else. --- Mark R. Lindsey, mark@datasys.net DSS Online Network Engineer (912) 241-0607, Fax: 241-0190

I am wondering where I can get some tried and true RAM for my netserver to take it from 4m to 20m or 16m or whatever. I have had some bad experiences buying RAM from 3rd parties on routers and stuff like that, so could someone give me a name or a number of someone who sells exactly what I'll need and can consistantly get me the correct RAM on the first go? Any help will be greatly appreciated. Thanks! Joe

Mark R. Lindsey said once upon a time: > >: Some of our usr tc's seem to be spontaneously rebooting themselves. >: Has anyone else observed this feature? > >No, but I've seen them spontaneously get mad at the LAN and refuse to talk >to anybody else. I had one that was doing this, readily apparent by its less than 24 hour uptimes. I sent the Netserver card back for repair.

On Saturday, May 31, 1997 10:32 PM, Stephen Corbesero [SMTP:flash@Early.com] wrote: > > Some of our usr tc's seem to be spontaneously rebooting themselves. > Has anyone else observed this feature? > > > -- > Stephen Corbesero This message has been brought to you by electrons. > flash@early.com Electrons -- The other charged particle. > Why yes. Since late last year, (3.3.28) EVERY LAST ONE of our Standard and Enhanced NETServers reboot without cause to this day. We have been working with the top dogs at USR on this for sometime, but was told that we were one of three companies that experienced the reboot issues. We placed a trouble ticket under a difference company and did not see it followed up. Just call and explain to them you know there is a problem ... and no won't do. Good luck. E-mail me if you need any help. Marshall Morgan President Internet Doorway, Inc. http://www.netdoor.com 601.969.1434 | 800.952.1570 | 601.969.3838 Fax

--IMA.Boundary.820492568 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Joe, USR sells a Memory Upgrade Kit (USR# 80-002149-0) that is tested and approved by our R&D folks. The cost to you is about the same as buying a SIMM from your favorite computer store (unless you buy in quantities larger than USR does); we don't make anything on the memory upgrade kit. So a USR Reseller in your area should be able to help you out. If you're looking for another alternative, I'd recommend a reputable SIMM vendor like Micron or Texas Instruments. I can't say that they'll always be good, but they've been doing this stuff so long that they're less likely to goof up. 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: Joseph Jones <jjones@visi.net> at Internet I am wondering where I can get some tried and true RAM for my netserver to take it from 4m to 20m or 16m or whatever. I have had some bad experiences buying RAM from 3rd parties on routers and stuff like that, so could someone give me a name or a number of someone who sells exactly what I'll need and can consistantly get me the correct RAM on the first go? Any help will be greatly appreciated. Thanks! Joe

Marshall Morgan <marshall@netdoor.com> writes: > Why yes. Since late last year, (3.3.28) EVERY LAST ONE of our > Standard and Enhanced NETServers reboot without cause to this day. One possibility is to double check that you aren't running out of memory ("show mem"). I've seen slow memory leakage (heaviest on our heavy PPP nodes) in versions up to and including the 3.3 stuff (although 3.3 is much better than 3.2) which can drain a NETServer over the course of a few weeks to a month or so depending on usage. I don't know what frequency you are seeing. At some point the NETServer keels over and reboots. You will probably get some memory allocation error logs in your syslog if you are maintaining one, or "show memory" will slowly show the available memory drop to 0. The available memory is actually a completely free block, so technically the memory in the various pools also contribute and are available, but over time something is lost. It's reasonably slow however, so we tend to monitor our NETServers and schedule them to be rebooted when they drop below a 50000 (randomly chosen) threshold for available memory. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Is there any way to find out what speed someone is connected to the X2 technology modems we have installed in the TC rack? We have Microcom ISPorte modems which we can view the speed on and would like to be able to monitor people's baud rates, considering we don't want 14.4 and 28.8 people hogging our X2 modems. Thanks, Jim MacKenzie System Administrator ErieNet, Inc.

On Tue, 3 Jun 1997, James MacKenzie wrote: > Is there any way to find out what speed someone is connected to the X2 > technology modems we have installed in the TC rack? We have Microcom > ISPorte modems which we can view the speed on and would like to be able to > monitor people's baud rates, considering we don't want 14.4 and 28.8 > people hogging our X2 modems. > I think the next release of TCS, 2.5.1, will include these changes in the netserver. The connection rates will be reported via radius (someone correct me if I'm wrong here). It would be useful to be able to see what speed people are on with a 'show all' or 'show sessions' as well, and/or when you 'show Sxx'. With current releases, I've only seen 56k and 64k reported for ISDN under a 'show all', but nothing for analog calls. - lv

On Tue, 3 Jun 1997, James MacKenzie wrote: > Is there any way to find out what speed someone is connected to the X2 > technology modems we have installed in the TC rack? We have Microcom > ISPorte modems which we can view the speed on and would like to be able to > monitor people's baud rates, considering we don't want 14.4 and 28.8 > people hogging our X2 modems. > I think the next release of TCS, 2.5.1, will include these changes in the netserver. The connection rates will be reported via radius (someone correct me if I'm wrong here). It would be useful to be able to see what speed people are on with a 'show all' or 'show sessions' as well, and/or when you 'show Sxx'. With current releases, I've only seen 56k and 64k reported for ISDN under a 'show all', but nothing for analog calls. - lv

Laszlo Vecsey <master@internexus.net> writes: > It would be useful to be able to see what speed people are on with a 'show > all' or 'show sessions' as well, and/or when you 'show Sxx'. With current > releases, I've only seen 56k and 64k reported for ISDN under a 'show all', > but nothing for analog calls. I think part of the problem with that is while the NETServer may know the speed during the initial setup with the modem, most modulations can adjust speed during the course of the call, and the NETServer doesn't get continuous updates from the modem. So such a display might be inaccurate into the call itself, although it could be used to represent an initial training rate. To get the most accurate values, you can always just ask the modem itself at any time, via the MIB objects (such as with a command line SNMP query tool): mdmCsInitialTxLinkRate \ Values at start of call for current mdmCsInitialRxLinkRate / (if online) or previous call. mdmCsFinalTxLinkRate \ Current values (if still online) mdmCsFinalRxLinkRate / or last values (for previous call) This should also be available with TCM under the statistics information for a given modem. -- David

Once upon a time James MacKenzie shaped the electrons to say... >Is there any way to find out what speed someone is connected to the X2 >technology modems we have installed in the TC rack? We have Microcom Does the TC report Connect-Info to RADIUS? (It is part of the RADIUS Extensions Draft.) -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

The TC's using RIPv2 are multicasting *all* over my network. Any ideas how I can either stop them at the Cisco, or limit the length of their mcast?

On Wed, 4 Jun 1997, Pete Ashdown wrote: > The TC's using RIPv2 are multicasting *all* over my network. Any ideas how > I can either stop them at the Cisco, or limit the length of their mcast? After we noticed a lot of ethernet broadcasts from our Netservers in cities where we have several, we put them on their own 100BT ethernet interface on the router, connected via their own 3Com Linkswitch 1000, and addressed them with an independent supernet (and a seperate subnet for the management cards because NMCs don't like /22 netmasks for class C addresses). Plus RIP and Netbeui were banned on the network at our main offices where OSPF was implemented to cut down on big broadcasts. AND the Netservers go into fits of unnecessary arp requests when they get a stream of undeliverable packets when the intended host's connection has dropped, giving us another reason to segregate the Netservers from the server farms. When they got their own segment our quake lag became less evident. Collisions on the other interface dropped from 7% to less than 1% during peak times. Broadcast traffic on the backbone was cut way down. RIP is good for small networks, so it makes sense to put RIP devices on their own small stub network and redistribute the routes to OSPF or IGRP at the router. RIP over the backbone is insane for a large network. Has anyone else ever noticed that the NMCs reboot themselves in broadcast storms? Anyone ever replace a NIC on a netserver without clearing the ARP cache in the router? :> -CH

I agree that you'll probably not get an accurate link rate, but I think that the main plus about having something like that on the netserver itself is to let you know who's connecting at X2 and who isn't. I mean, connection speeds are kinda cool to know, but everyone (just about) is going to get a different speed, so all I'm interested in is whether they should be using the X2 pool or a different pool... In any case, something like that on the netserver would be a big plus in my opinion. (Especially since I've been having so much trouble getting my command line SNMP gets to work. =) )

We have had our USR TC in action for about 3 weeks now, and its been working great- X2, non-x2 alike connect like a charm. The only complaint I have thus far (other than the quality of support from USR's 'premium' support) is the connection speeds. We can NOT ever get the maximum 'theoretical' speeds no matter what. I.e. 33.6 is un-obtainible, only 31.2 is seen (but we see 31.2 consitently). 53k is un-obtainible, but we see 50.333 consistently. First, I just want to state this is not a case of (hey the customer's lines are bad, they dont get maximum speeds). I'm a finger pointer at NYNEX just like the next guy, believe me (if its merited), but I have done tests from my home where I have a digital ISDN line. I use a USR I-courier, to make the 33.6 analog call atempts (so its digital all the way, but the USR I-courier can convert it properly to get it to analog. Doing this, I still get only 31.2 connections. I have hunt a "courier v.everything" off the back 'pots' jack of hte courier I-modem (figuring maybe the courier i-modem digital to analog conversion has some sort of overhead) and again I get 31.2 every call, but never 33.6. Customers from all over the NY state get the same thing, consistently HIGHER connections than our older analog rack systems, but never a 33.6 (with our analog modems on older terminal servers, they do get a 33.6 once our of maybe every 10-15 tries). Now, why is the USR toping out at 31.2. Our 'premium' support has done little to answer this (don't even get me started on the incompetence I have seen there in the support area) but say "no, that's normal- its the phone company's phone lines to the end user that are causing it to stay at 31.2". They can't explain why to our older 'cheaper' analog modems I CAN get a 33.6 once in a while, but NEVER to the USR TC system. I can except the x2 limitation of 50.3333, except looking at the big picture we see that our USR TC is missing the maximum throughput by one notch in both non-X2 and X2 connections. It look like some sort of signal that has a SIN wave that has it's peaks flattened out by 5% from the max in both directions. the only other 'answer' USR has for me, is that we use Channelized T1 (not PRI) and that the 'rob bit signals' use 1.7K and that is likely the problem. I laughed at her, stating a chanelized t1 is 56k per channel, so 1.7k off that still leaves room for a 31.2, but she insisted that would be hte cause. On a previous call to them (last week) they were quick to blame the phone company providing our chan t1's, so we had them out here with a T-bird yesterday to verify the Dbgain and singal/noise etc, and it came up clean (i watched the tests myself)- so now I'm back to USR for help (or lack there of) Has anyone else noticed similar problems? Do you guys actually get 33.6 incoming calls via a Chan T1 scenario? Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

> The only complaint I have thus far (other than the quality of support from > USR's 'premium' support) is the connection speeds. We can NOT ever get > the maximum 'theoretical' speeds no matter what. I.e. 33.6 is > un-obtainible, only 31.2 is seen (but we see 31.2 consitently). 53k is > un-obtainible, but we see 50.333 consistently. 33.6k and 53k initial connect speeds are rare, but clean connections usually upshift to those speeds. -CH

At 11:16 AM 6/5/97 -0500, you wrote: >> The only complaint I have thus far (other than the quality of support from >> USR's 'premium' support) is the connection speeds. We can NOT ever get >> the maximum 'theoretical' speeds no matter what. I.e. 33.6 is >> un-obtainible, only 31.2 is seen (but we see 31.2 consitently). 53k is >> un-obtainible, but we see 50.333 consistently. > >33.6k and 53k initial connect speeds are rare, but clean connections >usually upshift to those speeds. > Our channelized t-1 gets 31.2 on 33.6 modems and no higher than 44 with X2 capable modems...and we are only a few blocks from the phone company CO! 50.333 is a dream for us. USR blames US West and vice versa. I agree about USR's premium support. For the price they charge, it is usually pretty dismal.

Brian said once upon a time: >set lanwan_routing off What does this do? >anyone else have anything else to add? Did these fixes work for you?

Some things to help quake lag: Etherswitch the USR TC Hubs and the Quake server set proxyarp on set lanwan_routing off set snmp off anyone else have anything else to add? 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

Charles Hill said once upon a time: >> The TC's using RIPv2 are multicasting *all* over my network. Any ideas how >> I can either stop them at the Cisco, or limit the length of their mcast? > >After we noticed a lot of ethernet broadcasts from our Netservers in >cities where we have several, we put them on their own 100BT ethernet >interface on the router, connected via their own 3Com Linkswitch 1000, and >addressed them with an independent supernet (and a seperate subnet for the >management cards because NMCs don't like /22 netmasks for class C >addresses). Plus RIP and Netbeui were banned on the network at our main >offices where OSPF was implemented to cut down on big broadcasts. AND the >Netservers go into fits of unnecessary arp requests when they get a stream >of undeliverable packets when the intended host's connection has dropped, >giving us another reason to segregate the Netservers from the server >farms. When they got their own segment our quake lag became less evident. >Collisions on the other interface dropped from 7% to less than 1% during >peak times. Broadcast traffic on the backbone was cut way down. RIP is >good for small networks, so it makes sense to put RIP devices on their own >small stub network and redistribute the routes to OSPF or IGRP at the >router. RIP over the backbone is insane for a large network. This is fine, but I am already doing this. The only segment with RIP is the Cisco's ethernets which serve the TC's. My problem is that with RIPv2, they are multicasting past their ethernet segments onto the entire network.

--IMA.Boundary.834355568 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part Wow. Long message, Adam. I'll see what I can do with it. First, it's great news that you're having success with the Hub. We've all worked hard over here to make that happen as much as possible, and it's reasssuring to hear about cases like your's. Second, we realize that Tech Support has problems, and we're working to correct those problems. (I know, it doesn't look like it from the outside, there are a lot of internal changes that take time to pay off.) Third, the connection problems you've had are not typical, but shouldn't be considered "abnormal" either. There are a couple of things that could be contributing. Certainly, the T1 link (vs. a PRI) is a candidate for losing the highest notch for connection speed. You've heard that message from USR folks before, and you know that the T1 line is as good as it can get. So what else? Well, one thing that has been noted before (millions of times before on COMP-DCOM-MODEMS, and in many trade reviews) is that USR modems are not as aggresive in the speeds that they're willing to connect. We have taken a more conservative approach for many years with regards to line negotiation, with the goal of providing a rock-solid reliable connection over the duration of the transfer. During the connection, and if the signal is good, we will frequently speed-shift up, meaning that the remote user actually gets more speed than we originally reported. Here's a example, taken from a recent customer case we've been working on: For this site test, we called 50 times from 4 different locations with 4 different (3 non-USR) modems. # Calls Avg Connect Avg End Rx Avg End Tx ------- ------------ ------------ ------------ 200 21216 23128 25440 This is just one example (and one that is a problem situation), but you can see what I mean. So take a more in-depth look, and you may find that the USR Hub is doing a little better than you thought. And, Yes, I've seen 33.6 connections from a trunk-side T1 circuit. Not as often as PRI, but it does happen. 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: "Adam Wills (Global 2000)" <sysadmin@global2000.net> at Internet We have had our USR TC in action for about 3 weeks now, and its been working great- X2, non-x2 alike connect like a charm. The only complaint I have thus far (other than the quality of support from USR's 'premium' support) is the connection speeds. We can NOT ever get the maximum 'theoretical' speeds no matter what. I.e. 33.6 is un-obtainible, only 31.2 is seen (but we see 31.2 consitently). 53k is un-obtainible, but we see 50.333 consistently. First, I just want to state this is not a case of (hey the customer's lines are bad, they dont get maximum speeds). I'm a finger pointer at NYNEX just like the next guy, believe me (if its merited), but I have done tests from my home where I have a digital ISDN line. I use a USR I-courier, to make the 33.6 analog call atempts (so its digital all the way, but the USR I-courier can convert it properly to get it to analog. Doing this, I still get only 31.2 connections. I have hunt a "courier v.everything" off the back 'pots' jack of hte courier I-modem (figuring maybe the courier i-modem digital to analog conversion has some sort of overhead) and again I get 31.2 every call, but never 33.6. Customers from all over the NY state get the same thing, consistently HIGHER connections than our older analog rack systems, but never a 33.6 (with our analog modems on older terminal servers, they do get a 33.6 once our of maybe every 10-15 tries). Now, why is the USR toping out at 31.2. Our 'premium' support has done little to answer this (don't even get me started on the incompetence I have seen there in the support area) but say "no, that's normal- its the phone company's phone lines to the end user that are causing it to stay at 31.2". They can't explain why to our older 'cheaper' analog modems I CAN get a 33.6 once in a while, but NEVER to the USR TC system. I can except the x2 limitation of 50.3333, except looking at the big picture we see that our USR TC is missing the maximum throughput by one notch in both non-X2 and X2 connections. It look like some sort of signal that has a SIN wave that has it's peaks flattened out by 5% from the max in both directions. the only other 'answer' USR has for me, is that we use Channelized T1 (not PRI) and that the 'rob bit signals' use 1.7K and that is likely the problem. I laughed at her, stating a chanelized t1 is 56k per channel, so 1.7k off that still leaves room for a 31.2, but she insisted that would be hte cause. On a previous call to them (last week) they were quick to blame the phone company providing our chan t1's, so we had them out here with a T-bird yesterday to verify the Dbgain and singal/noise etc, and it came up clean (i watched the tests myself)- so now I'm back to USR for help (or lack there of) Has anyone else noticed similar problems? Do you guys actually get 33.6 incoming calls via a Chan T1 scenario? Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465 --IMA.Boundary.834355568 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 396CAAB0; Thu, 5 Jun 97 09:18:19 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id IAA05485; Thu, 5 Jun 1997 08:56:45 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.62 #1) id 0wZcsY-0001Il-00; Thu, 5 Jun 1997 07:47:02 -0600 Received: from mail2.global2000.net [208.133.128.5] (root) by mail.xmission.com with smtp (Exim 1.62 #1) id 0wZcsT-0001IO-00; Thu, 5 Jun 1997 07:46:59 -0600 Received: from shell.global2000.net (sysadmin@shell-sprint.global2000.net [205.247.154.34]) by mail2.global2000.net (8.9.1/SecureMode) with SMTP id JAA28215 for <usr-tc@mail.xmission.com>; Thu, 5 Jun 1997 09:46:50 -0400 Message-ID: <Pine.LNX.3.95.970605093702.15892F-100000@shell.global2000.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.834355568--

On Thu, 5 Jun 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >set lanwan_routing off > > What does this do? disables routing between the lan and wan ports. It, I beleive, reduces broadcasts to that port, and probably some overhead as well. > > >anyone else have anything else to add? > > Did these fixes work for you? yes! I still think there is room for improvment though 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

Well, I whent through 6 managers and 3 technicians (anyone think the problem at USR support might be too many chiefs, not enough indians?) calling me back on an UN-RELATED problem to the connections and brought up the conenction speed issues with the head tech guy i got. They explained that in chan t1, you have 1.7 db signal loss due to the 'rob bit' signals from the teleco to you. Then due to the analog-to-digital conversion yo uget up to another 1.1 db singal loss from the customer's end to the teleco. Long story short, they claim its near impossible to get 33.6 or 53k speeds out of a USR Tc on Chan t1. Anyone in a law suite with USR right now over the whole 53k think not working want some names and #'s from today :) This one has me grinning over the $100,000 payment for the next batch of USR Tc's we were going to put in. We were UPFRONT with our setup, working with USR and the teleco (USR works with our local RBOC in other deals) and was totally aware of what we planned to do and what we were doing- and still sold us saying it will work.. Oh well... the tell me if I get PRI I can get 33.6, and I just point to my Livingston pm2e30's with Boca Modems and laugh at the 1/3 price tag that gets 33.6's via POTS :) You know what scares me though, I am still happy with the USR TC rack, because it does do 31.2 more often than the Boca's get 28.8 or above anyway (but the fact they now tell me it wont go over 31.2 is ludicrous). We have had the tele-co out to test the db levels, and other items- and hte chan t1 is clean- but I do concur that the 'theory' behind how a chan-t1 works would likely result in the signal loss that would prevent the highest possible speeds- but why they sold me on it w/o telling me that baffles me Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465 On Thu, 5 Jun 1997, Jim Faulkner wrote: > At 11:16 AM 6/5/97 -0500, you wrote: > >> The only complaint I have thus far (other than the quality of support from > >> USR's 'premium' support) is the connection speeds. We can NOT ever get > >> the maximum 'theoretical' speeds no matter what. I.e. 33.6 is > >> un-obtainible, only 31.2 is seen (but we see 31.2 consitently). 53k is > >> un-obtainible, but we see 50.333 consistently. > > > >33.6k and 53k initial connect speeds are rare, but clean connections > >usually upshift to those speeds. > > > Our channelized t-1 gets 31.2 on 33.6 modems and no higher than 44 with X2 > capable modems...and we are only a few blocks from the phone company CO! > 50.333 is a dream for us. USR blames US West and vice versa. I agree about > USR's premium support. For the price they charge, it is usually pretty dismal. > > >

On Thu, 5 Jun 1997 kjohnson@usr.com wrote: > Wow. Long message, Adam. I'll see what I can do with it. > > Third, the connection problems you've had are not typical, but shouldn't be > considered "abnormal" either. There are a couple of things that could be > contributing. Certainly, the T1 link (vs. a PRI) is a candidate for losing the > highest notch for connection speed. You've heard that message from USR folks > before, and you know that the T1 line is as good as it can get. So what else? > Man I wish I had gotten you on the phone today as one of the many USR call backs I got (though all the call backs were due to a support issue from 2 weeks back and not the real ticket in question). From the techs I dealt with (ticket Ref# 7042872), they 'insist' that it is 'normal' and that all chan-t1's will do this. They stated that its extreemly unlikely to ever get above 31.2 (lets not even get into X2 for now, lets just stick with the norm) on a Chan T1, and my only sollution was PRI and PRI alone. I fully concur and agree that a Chan T1 should NOT be able to get 33.6, I whipped out some of my good old Engr books and brushed up on this today. I am happy that it gets 31.2 MORe often then my boca's even get 28.8, but the fact remains the bocas DO get a speed higher than the USR's can ever do :( If this was known, I would have LOVED to have been told up-front. Its hard for me to tell users "hey we just spent $100,000 more to make your lives beter at Global 2000, but you will never see 33.6 speeds again- but we know you wont mind". As to your other comments (snipped for brevity) about how hte usr 'shifts' up speeds- Yep I checked that angle too :) Via the Total Control Manager, I sit there watching the quad cards, and watch the Xfer speeds and connect speeds (incoming/outgoing) etc. In fact, I am mortified at what I am seeing on the X2 connects, speeds of 333333 xfer and others- though my personal tests of x2 showed xfer's at about 53k consistently via FTP my users dont seem to have my same results. I do have to admit, my tets of X2 are great, and I love it- but I don't know if my users are getting the same results of just how much stock I can put in the SNMP reported speeds from the quad cards. But X2 is the leaste of my worries quite frankly, If I can't at least 'match' the speed of my OLD service method, then adding X2 for my users is like handing a lollipop to a viscious pack of wolves as they chew you up- something sweet, but too late becasue they are pissed :) We are now going to try to arrange for PRI's for the TC rack, even due to the increased price between PRI and Chan T1, its going to be necessary. One thing I havent done, as stupid as it sounds, is plug a POTS line into one of hte A/D quad cards and see if that gets me a 33.6 :) Now if that does, I think I would just cry (and I think it will work too). Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

On Thu, 5 Jun 1997, David Bolen wrote: > "Adam Wills (Global 2000)" <sysadmin@global2000.net> writes: > > > We are now going to try to arrange for PRI's for the TC rack, even due to > > the increased price between PRI and Chan T1, its going to be necessary. > > One thing I havent done, as stupid as it sounds, is plug a POTS line into > > one of hte A/D quad cards and see if that gets me a 33.6 :) Now if that > > does, I think I would just cry (and I think it will work too). > > Oh, one other thing you might like to try - check to see what the > transmit signal strength is on your digital modem cards. I believe > the default may still be -11db depending on how the modem cards were > initialized, but I believe the recommendation is to run those cards > connected digitally at -13db. > Mine are set to -11db so I guess that still is the default. Everything is brought in on PRI. So I gather setting it to a bit colder signal will improve V.34 connect speeds? this is good.........are there any more tweeks that you have found helpful? > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications \ Phone: (914) 789-5327 | > / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ > \-----------------------------------------------------------------------/ > 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

"Adam Wills (Global 2000)" <sysadmin@global2000.net> writes: > Long story short, they claim its near impossible to > get 33.6 or 53k speeds out of a USR Tc on Chan t1. Well, I wouldn't quite say near impossible, but the stats are certainly in the very low percentages. As a very quick sample set, I ran stats on a few hubs at one of my channelized T1 nodes for a recent 24 hour period. Out of 17248 calls that used v.34, I saw the following for the v.34+ (31.2K and 33.6K) rates: Transmit (Hub->User) Receive (User->Hub) Initial Final Initial Final ---------------------------------------------------- 31.2K 1218 7.1% 1173 6.8% 2534 14.7% 3770 21.9% 33.6K 153 0.9% 56 0.3% 38 0.2% 172 1.0% So the numbers are small, but the one piece of information I can't account for is how many of those 17248 calls came from modems that themselves don't actually support the 31.2/33.6 rates. Also, these stats are spread over all callers, so obviously if a particular caller is on a line where the quality is the best, the odds of that particular person getting the highest rate is much higher than the overall system percentage. To be fair, here's a sample comparison from a set of racks at a site using PRI (different geographic region, but same timeframe) covering a total of 15432 v.34 calls: Transmit (Hub->User) Receive (User->Hub) Initial Final Initial Final ------------------------------------------------------ 31.2K 2368 15.3% 2270 14.7% 3298 21.3% 3459 22.4% 33.6K 593 3.8% 526 3.4% 1331 8.6% 1770 11.5% It is interesting to note that at least for this period on these nodes, the transit side to the user generally fell back a bit while the receive side from the user increased quite a bit. But even in a nice PRI case I'm only seeing about 3% of my callers get the highest rate, although it is about a 10x factor over a T1 configuration. It is only the initial transmit (according to the above numbers) that represents what a user will see in the CONNECT message. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

"Adam Wills (Global 2000)" <sysadmin@global2000.net> writes: > We are now going to try to arrange for PRI's for the TC rack, even due to > the increased price between PRI and Chan T1, its going to be necessary. > One thing I havent done, as stupid as it sounds, is plug a POTS line into > one of hte A/D quad cards and see if that gets me a 33.6 :) Now if that > does, I think I would just cry (and I think it will work too). Oh, one other thing you might like to try - check to see what the transmit signal strength is on your digital modem cards. I believe the default may still be -11db depending on how the modem cards were initialized, but I believe the recommendation is to run those cards connected digitally at -13db. Having a signal that is a bit "too hot" can affect the ability of the receiving modem to deal with it and might affect your connectivity. Of course conversely if your lines have more attentuation somewhere along the way, a hotter signal might be able to cut through it. I reset my digital modems to 13db as a standard part of our download process. (This won't affect your x2 stuff, for x2 the modem has a preset signal strength independent of the normal configured value). You can query change this using the mdmLiTransmitLevel MIB object (it's in the "line interface" group, so if you're using TCM check for that). The value is a number representing negative db. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Brian <signal@shreve.net> writes: > Mine are set to -11db so I guess that still is the default. Everything is > brought in on PRI. So I gather setting it to a bit colder signal will > improve V.34 connect speeds? I'm not sure that I've got that much solid empirical evidence that the -13db does that much better than the -11db, but I do know that every 2db or can represent a "tick" in a protocol if you're heading the wrong way. There have also been some cases where we were given circuits from a 4ESS rather than 5ESS, and because of that the attenuation along the path was different (since we were entering the network at a "higher" point) so we had to attenuate the signal a bit further, and did see noticeble results. Probably a good thing to try for your own case would be to store some stats (if you aren't already) on connection rates, then change the value and see what happens over a comparable period of time with the change. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Interesting. So, as far as you can see from your stats, that going to PRI will not really make a whole lot of difference .9% to 3.9% is not really a huge margin at all. Most of my users have 33.6 modems, but not all (like you said in your results, you never know if hte customer could even obtain them with their equpiement). I do agree, Chan T1 is not really capible of full connections due to the db limits of the tie in to the Phone Co switch and the end user a/d conversions. ACcording to USR, via phone, they states that its 'possible' to get 33.6 ver very rarely via chan t1 when you have certain configurations at the TeleCo that help minimize the end user-s a/d db loss (they said its up to 1.1 db i think) when they first reach the teleco- and in those situations you can see full 33.6 connections and 53k connections. I'm still pleased overall with the product at even 31.2 and 50.333 X2 connections (nothing yet has gone above that according to our stats)- I just wish our USR sales rep would have been more forward about that instance that we in fact 'go backwards' when going to digital with their $20/k per rack equpiqment from our older $8/k per rack POPS equipement due to limitatoins NOT in their equpiement but in the Chan T1 (they really hammered home the point 'USR works with your RBOC for state and educations sites all over, and with X2 too, you can use us AND them and get everything you want'). I'm still going to plug a 'pots' line into one of the quad cards today, and test via my courier v.everything.. If I pull a 33.6 consistently at least I can be happy in knowing its purely the chan-t1 limitations. On Thu, 5 Jun 1997, David Bolen wrote: > As a very quick sample set, I ran stats on a few hubs at one of my > channelized T1 nodes for a recent 24 hour period. > > Out of 17248 calls that used v.34, I saw the following for the v.34+ > (31.2K and 33.6K) rates: > > Transmit (Hub->User) Receive (User->Hub) > Initial Final Initial Final > ---------------------------------------------------- > 31.2K 1218 7.1% 1173 6.8% 2534 14.7% 3770 21.9% > 33.6K 153 0.9% 56 0.3% 38 0.2% 172 1.0% > > So the numbers are small, but the one piece of information I can't > account for is how many of those 17248 calls came from modems that > themselves don't actually support the 31.2/33.6 rates. > > Also, these stats are spread over all callers, so obviously if a > particular caller is on a line where the quality is the best, the odds > of that particular person getting the highest rate is much higher than > the overall system percentage. > > To be fair, here's a sample comparison from a set of racks at a site > using PRI (different geographic region, but same timeframe) covering a > total of 15432 v.34 calls: > > Transmit (Hub->User) Receive (User->Hub) > Initial Final Initial Final > ------------------------------------------------------ > 31.2K 2368 15.3% 2270 14.7% 3298 21.3% 3459 22.4% > 33.6K 593 3.8% 526 3.4% 1331 8.6% 1770 11.5% > > It is interesting to note that at least for this period on these > nodes, the transit side to the user generally fell back a bit while > the receive side from the user increased quite a bit. > > But even in a nice PRI case I'm only seeing about 3% of my callers get > the highest rate, although it is about a 10x factor over a T1 > configuration. > > It is only the initial transmit (according to the above numbers) that > represents what a user will see in the CONNECT message. > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications \ Phone: (914) 789-5327 | > / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ > \-----------------------------------------------------------------------/ >

Lanwan_routing allows routing between the Lan interface and the frame-relay interface Lan net0 to wan Wan0 or wan1. This will not help you solve the quake problem Tatai Krishnan Network Systems Engineer US Robotics On Thu, 5 Jun 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >set lanwan_routing off > > What does this do? > > >anyone else have anything else to add? > > Did these fixes work for you? >

We have some difference in here and we aren't up to the V2 but with our v.34 (33.6) we also had people complaining of not getting 33.6 despite clear connections and all the rest. We have analog modems, analog phone lines and about 189 lines, 80 of which are converted dual V.34 modems rather than quads. We did alot of checking on this and the speeds being reported did manage that, but one of the adjuctant professors here is in the Math department does stuff just for fun, such as figuring ways to test throughput and many other things, he's really been a help to me. Well he has this file that is uncompressable, therefore it should transfer at the full modem rate. He reported that when he first connected (and this was with a USR Courier) he also reported 31.2 speeds. However he ran this file transfer over the link and found out that indeed the modem had shifted up to maximum speed sometime after it reported the 31.2 connection and when the file began transferring. It also corresponds with other problems we were working with. We had just introduced service to our campus by an outside provider, with the provision they supply a program that would also work for customers dialing our modems. Their package left a bit to be desired. Had alot of connection problems, from the modem init strings to catching what was being sent back. It was predominantly with the Mac application. What I found was that it often would complete the negotiation but then before it started the PPP connect script the speeds would not match. The PPP applicaton was not adapting with the speed retrain, so would be at a different speed. Once we figured that out and changed a setting or two we found that once you had the modem init right to negotiate properly and report the true line speed (rather than DTE to Modem speed) that it started to work. I really do believe that they do retrain after their initial connection and very soon thereafter. Thanks, Ray Kopp Syracuse, New York Internet:rjkopp@mailbox.syr.edu Home Page:http://web.syr.edu/~rjkopp

On Fri, 6 Jun 1997, Tatai SV Krishnan wrote: > Lanwan_routing allows routing between the Lan interface and the > frame-relay interface Lan net0 to wan Wan0 or wan1. This will not help > you solve the quake problem > I understand it wont "solve" the problem, but it does improve performance on the chasis, at least thats what "toan" told me, he is who I talk to over at USR tech support. Brian > > > Tatai Krishnan > > Network Systems Engineer > US Robotics > > > > On Thu, 5 Jun 1997, Pete Ashdown wrote: > > > Brian said once upon a time: > > > > >set lanwan_routing off > > > > What does this do? > > > > >anyone else have anything else to add? > > > > Did these fixes work for you? > > > 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, TSV Krishnan 1705 Victoria Drive Mt. Prospect IL On Fri, 6 Jun 1997, Brian wrote: > On Fri, 6 Jun 1997, Tatai SV Krishnan wrote: > > > Lanwan_routing allows routing between the Lan interface and the > > frame-relay interface Lan net0 to wan Wan0 or wan1. This will not help > > you solve the quake problem > > > > I understand it wont "solve" the problem, but it does improve performance > on the chasis, at least thats what "toan" told me, he is who I talk to > over at USR tech support. > > Brian > Thats not true I will correct toan on this. > > > > > > > Tatai Krishnan > > > > Network Systems Engineer > > US Robotics > > > > > > > > On Thu, 5 Jun 1997, Pete Ashdown wrote: > > > > > Brian said once upon a time: > > > > > > >set lanwan_routing off > > > > > > What does this do? > > > > > > >anyone else have anything else to add? > > > > > > Did these fixes work for you? > > > > > > > > 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 > > >

Tatai SV Krishnan said once upon a time: >Thats not true I will correct toan on this. Has USR been able to isolate, or even demonstrate the Quake lag problem in their labs? Someone from USR was telling me that they couldn't replicate it.

> > There have also been some cases where we were given circuits from a 4ESS > rather than 5ESS, and because of that the attenuation along the path > was different (since we were entering the network at a "higher" point) > so we had to attenuate the signal a bit further, and did see > noticeble results. 4ESS? isn't that a long haul/long distance switch? Brian > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications \ Phone: (914) 789-5327 | > / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ > \-----------------------------------------------------------------------/ > 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 there a expected release date for TCS 2.5.1? 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

David Bolen said once upon a time: >If you're using a NETServer the setting is unimportant, since it >doesn't have any bearing on the packet bus connection to the NETServer >(which has no bps rate per se). Try dialing out. You'll note that your connection rate <= DTE rate setting. I set all my settings to 115K, fixed, and hardware flow control just to be sure.

Also, What do you all have "Default DTE Data Rate (&Bn)" set to in TCM? we have "bps38k".....should we have this set to somethign else faster? 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

"Adam Wills (Global 2000)" <sysadmin@global2000.net> writes: > Interesting. So, as far as you can see from your stats, that going to PRI > will not really make a whole lot of difference .9% to 3.9% is not really a > huge margin at all. Well, the better comparison is probably the final transmit rates, so .3 to 3.4, but yeah, in absolute terms it's not a huge margin. Of course, in relative terms it's an order of magnitude so... > I'm still pleased overall with the product at even 31.2 and 50.333 X2 > connections (nothing yet has gone above that according to our stats)- I (Minor note - it's 50.6K connections) Yeah, it's quite rare to get higher - even on my PRI sites I'm only seeing about 1% of the calls end above that range. > just wish our USR sales rep would have been more forward about that > instance that we in fact 'go backwards' when going to digital with their > $20/k per rack equpiqment from our older $8/k per rack POPS equipement due > to limitatoins NOT in their equpiement but in the Chan T1 (they really > hammered home the point 'USR works with your RBOC for state and educations > sites all over, and with X2 too, you can use us AND them and get > everything you want'). I find it interesting that you are really going backwards, since I have a hard time believing that typical POTS lines could exhibit better behavior frequency and bandwidth wise than the channelized T1 (even with the robbed-bit). You must have had really nice copper connections to a nearby telco switch, since in most of my cases my T1s are easily outperforming the typical connections I'd get over POTS lines. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Ray Kopp <rjkopp@mailbox.syr.edu> writes: > Well he has this file > that is uncompressable, therefore it should transfer at the full modem > rate. When doing this kind of test, I just suggest disabling compression on the modem. That way you don't you have to worry about a file being utterly uncompressible. > What > I found was that it often would complete the negotiation but then before > it started the PPP connect script the speeds would not match. The PPP > applicaton was not adapting with the speed retrain, so would be at a > different speed. This sounds like you weren't running the modems at a fixed DTE rate, which is definitely the preferred mode. Rather than let the modem adjust the serial port rate based on the connection (and the PC package have to adjust as well), just run the serial port as fast as you can to give the modem's compression engine the most room to work, and then fix the serial port at that rate, regardless of how fast the modems actually communicate with each other. On USR modems, using &B1 fixes the DTE rate. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Ray Kopp <rjkopp@mailbox.syr.edu> writes: > Well he has this file > that is uncompressable, therefore it should transfer at the full modem > rate. When doing this kind of test, I just suggest disabling compression on the modem. That way you don't you have to worry about a file being utterly uncompressible. > What > I found was that it often would complete the negotiation but then before > it started the PPP connect script the speeds would not match. The PPP > applicaton was not adapting with the speed retrain, so would be at a > different speed. This sounds like you weren't running the modems at a fixed DTE rate, which is definitely the preferred mode. Rather than let the modem adjust the serial port rate based on the connection (and the PC package have to adjust as well), just run the serial port as fast as you can to give the modem's compression engine the most room to work, and then fix the serial port at that rate, regardless of how fast the modems actually communicate with each other. On USR modems, using &B1 fixes the DTE rate. -- 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.590736568 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part It shouldn't matter in the least, unless you're using RS-232 out of the modems, since we ignore that line when we're using the packet bus. If you -ARE- using RS-232, then set it as high as your host will accept and lock it (Fixed DTE Rate, or &B1). 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: Brian <signal@shreve.net> at Internet Also, What do you all have "Default DTE Data Rate (&Bn)" set to in TCM? we have "bps38k".....should we have this set to somethign else faster? 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 --IMA.Boundary.590736568 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 39887910; Fri, 6 Jun 97 16:56:33 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id QAA09793; Fri, 6 Jun 1997 16:34:59 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.62 #1) id 0wa6KH-0000L2-00; Fri, 6 Jun 1997 15:13:37 -0600 Received: from www.shreve.net [208.206.76.5] (root) by mail.xmission.com with esmtp (Exim 1.62 #1) id 0wa6KC-0000KV-00; Fri, 6 Jun 1997 15:13:34 -0600 Received: from www.shreve.net (signal@www.shreve.net [208.206.76.5]) by www.shreve.net (8.8.5/8.8.5) with SMTP id QAA09162 for <usr-tc@xmission.com>; Fri, 6 Jun 1997 16:06:43 -0500 Message-ID: <Pine.LNX.3.93.970606160559.9147A-100000@www.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.590736568--

Brian <signal@shreve.net> writes: > What do you all have "Default DTE Data Rate (&Bn)" set to in TCM? Actually, &B controls how the DTE rate adjusts either fixed (&B1), floating (&B0) or fixed only for ARQ (&B2). You might mean %B. > we have "bps38k".....should we have this set to somethign else faster? If you're using a NETServer the setting is unimportant, since it doesn't have any bearing on the packet bus connection to the NETServer (which has no bps rate per se). However, if you are using the external RS232 interface to some other box for handling the user traffic, you should set the serial port as high as your external box can handle, so 115.2K if possible. The reason is that while the link rate between modems is going to be no higher than 33.6K (assuming v.34, x2 goes higher), the data is going to be compressed when possible in most cases (typically v.42bis, sometimes MNP5) and thus can achieve higher throughput than the modem link rate would otherwise allow. Having only a 38.4K DTE rate doesn't provide for much compression - or actually none at the higher rates. A 38400bps serial port is about 3840 cps (using 10-bit characters to allow for start/stop bits), which in terms of 8-bit characters on the modem line is 30720bps. Given about 5% for v.42 overhead, that means you can hold about 32336bps over the modem line with a 38400bps serial port, with no room for compression. If instead you run your serial port at 115200 then you can take the full modem rate and allow for a reasonable compression factor before you begin to hit the bottleneck of the serial port. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Brian <signal@shreve.net> writes: > What do you all have "Default DTE Data Rate (&Bn)" set to in TCM? Actually, &B controls how the DTE rate adjusts either fixed (&B1), floating (&B0) or fixed only for ARQ (&B2). You might mean %B. > we have "bps38k".....should we have this set to somethign else faster? If you're using a NETServer the setting is unimportant, since it doesn't have any bearing on the packet bus connection to the NETServer (which has no bps rate per se). However, if you are using the external RS232 interface to some other box for handling the user traffic, you should set the serial port as high as your external box can handle, so 115.2K if possible. The reason is that while the link rate between modems is going to be no higher than 33.6K (assuming v.34, x2 goes higher), the data is going to be compressed when possible in most cases (typically v.42bis, sometimes MNP5) and thus can achieve higher throughput than the modem link rate would otherwise allow. Having only a 38.4K DTE rate doesn't provide for much compression - or actually none at the higher rates. A 38400bps serial port is about 3840 cps (using 10-bit characters to allow for start/stop bits), which in terms of 8-bit characters on the modem line is 30720bps. Given about 5% for v.42 overhead, that means you can hold about 32336bps over the modem line with a 38400bps serial port, with no room for compression. If instead you run your serial port at 115200 then you can take the full modem rate and allow for a reasonable compression factor before you begin to hit the bottleneck of the serial port. -- 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: > Try dialing out. You'll note that your connection rate <= DTE rate > setting. I set all my settings to 115K, fixed, and hardware flow control > just to be sure. Interesting - my guess is you could file this as a bug with the modem folks, since it must be that the modem code still checks that internal setting when performing the training, even though it has no real bearing on actual throughput, nor is involved in the packet bus communications. However, in such a case, even a value of 38400 should allow all v.34 connection rates, but they would preclude all but the lowest x2 rates. -- David

Telco configured one of our PRI's as NFAS, which is not what we requested, but anyways, I need to make this work now. Correct me if I am wrong, but I need to call telco and get the NFAS ID # for the pri I wish to use a D Channel from. Then go into TCM, and give TCM the NFAS ID # of the pri i wish to use a D channel from and set that pri for ExtraBchannel. Is this correct? Is the NFAS ID # part of the line that actually has NFAS on it, or is it an ID # associated with whichever pri of ours I want to utilize the D channel of? all and all, I will probably run NFAS on all pri's, its just that at this point in time I was just trying to keep everything the same. Telco sold my boss into thinking "Dont run NFAS, if you lose your D channel then all the pri's slaving off it will dump too". This is true, however, since we are on a hunt group, I beleive that even without NFAS, if the first hunted pri went down we would probably lose it all anyways. Telco just trying to make a few extra $$$'s. Besides, if the pri went down, its THERE job to fix the outage ASAP...... 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

Thus spake Brian >Telco configured one of our PRI's as NFAS, which is not what we requested, >but anyways, I need to make this work now. Let me get this straight....the telco installed a line in a different way than you requested it, and you're OK with that? How about calling the Telco and chewing some butt? >all and all, I will probably run NFAS on all pri's, its just that at this >point in time I was just trying to keep everything the same. Telco sold >my boss into thinking "Dont run NFAS, if you lose your D channel then all >the pri's slaving off it will dump too". This is true, however, since we >are on a hunt group, I beleive that even without NFAS, if the first hunted >pri went down we would probably lose it all anyways. That's not correct. If you lose the first PRI in a hunt group, then the switch sees that link down, doesn't send any calls to it, and sends them to the next PRI in the hunt (the next D channel). Personally, we're planning on sticking with a D channel on each PRI to minimize downtime problems. >Telco just trying to >make a few extra $$$'s. Besides, if the pri went down, its THERE job to >fix the outage ASAP...... Agreed, but its also their job to install what you order. -- Jeff McAdams | "OK, we have enough youth... IgLou Internet Services | How about a fountain of smart?" e-mail: jeffm@iglou.com | - unknown

Mike Wronski said once upon a time: >This can't be done with the current TCM.. You can however you can querry the >netserver with a script and get the results.. I have modified versions of >PMWHO.C to do this.. Can I get a copy of this?

At 04:02 PM 6/9/97 -0400, you wrote: >Does anyone know if there is an SNMP object that can report which ports >are active on USR TC? I know with Livingston PM3's I can use SNMP to get >which user is on each port and their IP address. Can I do the same with >USR TC? > This can't be done with the current TCM.. You can however you can querry the netserver with a script and get the results.. I have modified versions of PMWHO.C to do this.. -Mike

Does anyone know if there is an SNMP object that can report which ports are active on USR TC? I know with Livingston PM3's I can use SNMP to get which user is on each port and their IP address. Can I do the same with USR TC? Corey Piggott Infinet Network Engineering

OK, it never hurts to sanity check once in a while, right? Well, let's end this discussion with this. We've tested this "DTE speed over packetbus for dial out" theory a few times to be sure we weren't running into a bug anywhere. Here's the various code releases we used: NETServer v3.4.23 Quad modem 5.1.7, fixed DTE rate of 1200bps Then we TELNET'ed to the modem, dialed the ATDT and originated out the PRI to another system, and connected at 21600 and passed data over the link. If the DTE rate really mattered for dial out, then we would either not connect at speeds higher than 1200bps, or we would have had a baud rate mismatch. So if you're up to the latest shipping code as of today, you don't need to worry about this setting when using the packet bus. 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: Brian <signal@shreve.net> at Internet Also, What do you all have "Default DTE Data Rate (&Bn)" set to in TCM? we have "bps38k".....should we have this set to somethign else faster? 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

Corey Piggott <corey@infi.net> writes: > Does anyone know if there is an SNMP object that can report which ports > are active on USR TC? I know with Livingston PM3's I can use SNMP to get > which user is on each port and their IP address. Can I do the same with > USR TC? Unfortunately, the NETServer itself isn't all that usable via SNMP, as it only supports MIB-II so much of this sort of information I tend to acquire via automated logins to the NETServer command interface (or via our own daemons which monitor the call session and thus always know what is in use, and export that information via our own agents). I believe that's really the only approach to identifying username information at this point, unless you grab and store it during the login process (either parsing syslogs or listening for accounting information). Oh, I do think that there is some support for specialized RADIUS operations in the recent releases to allow a server to query resource information, but I don't know if it includes usernames (probably not). But back on the SNMP front... Address/port usage information can be obtained somewhat via SNMP however. The NETServer supports MIB-II, so you could determine which addresses were in use by walking ipAddrTable, and although I haven't looked very carefully, it would appear that the NETServer numbers the interfaces related to the port value (it looks like offset by 2, probably to allow the ethernet port to have an interface number of 1). So walking the ipAdEntIfIndex and ipAdEntNetMask objects would give you the addresses that were in use (via the instance of the object) and the port and netmask. This would also tell you ports in use, although presumably only those in use for a SLIP/PPP sessions, since those are the only ones involving an IP interface on the NETServer. If you just want to know the channels in use, there are some other NMC based queries you can do for the input devices (rather than the NETServer). For example, if you're on an analog system (no ISDN) then you can either query the modem status (mdmCsStatus) for each modem to determine which modems are not idle. That's kind of sluggish though, so I prefer to use the chassis LED object (uchasLedFrontPanelStates and uchasLedFrontPanelColor) which is a single opaque object that quickly returns you all LED information and you can count up those modems that are active. To do this properly you'll either need to know beforehand which slots have modems or query that yourself (use the uchasSlotModuleType object). Alternatively, you can query the status of your input channels on any line cards (T1/PRI). This used to be really slow, but in recent NMC/line releases there are bulk objects that make it very fast. Using either ds0BulkAccessTable or ids0BulkAccessTable (for T1 or PRI respectively) you can with a single object get state information on every channel on the card, and immediately know which are in use, out of service/busy, or idle. None of this is probably exactly what you want, via a single source, but by combining one or two of the approaches you can probably come close. The username part is going to be the trickiest if you are trying to obtain it "after the fact" or post-login, so to speak and will probably require that you issue some commands 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 \ \-----------------------------------------------------------------------/

On Mon, 9 Jun 1997, Adam Wills (Global 2000) wrote: > I tried out your suggest, going to the quad cards and changing the > TRansmitter Level (db) from 11 to 13, but every time i do it and click on > 'ok' or 'set' it says: > > Error Type: Generic Error > Paramter: Transmitter Level (db) > Object ID: 1.3.6.1.4.1.429.1.6.2.1.1.18.2001 > > > Can you tell me where you 'found' this recomendation, was it from usr > themselves? > This is because the modem is in use, take the modem out of service, then do a set, then goto action and save to nvram. Brian > > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > > On Thu, 5 Jun 1997, David Bolen wrote: > > > "Adam Wills (Global 2000)" <sysadmin@global2000.net> writes: > > > > > We are now going to try to arrange for PRI's for the TC rack, even due to > > > the increased price between PRI and Chan T1, its going to be necessary. > > > One thing I havent done, as stupid as it sounds, is plug a POTS line into > > > one of hte A/D quad cards and see if that gets me a 33.6 :) Now if that > > > does, I think I would just cry (and I think it will work too). > > > > Oh, one other thing you might like to try - check to see what the > > transmit signal strength is on your digital modem cards. I believe > > the default may still be -11db depending on how the modem cards were > > initialized, but I believe the recommendation is to run those cards > > connected digitally at -13db. > > > > Having a signal that is a bit "too hot" can affect the ability of the > > receiving modem to deal with it and might affect your connectivity. > > Of course conversely if your lines have more attentuation somewhere > > along the way, a hotter signal might be able to cut through it. > > > > I reset my digital modems to 13db as a standard part of our download > > process. > > > > (This won't affect your x2 stuff, for x2 the modem has a preset signal > > strength independent of the normal configured value). > > > > You can query change this using the mdmLiTransmitLevel MIB object > > (it's in the "line interface" group, so if you're using TCM check for > > that). The value is a number representing negative db. > > > > -- David > > > > /-----------------------------------------------------------------------\ > > \ David Bolen \ Internet: db3l@ans.net / > > | ANS Communications \ Phone: (914) 789-5327 | > > / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ > > \-----------------------------------------------------------------------/ > > > > 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 tried out your suggest, going to the quad cards and changing the TRansmitter Level (db) from 11 to 13, but every time i do it and click on 'ok' or 'set' it says: Error Type: Generic Error Paramter: Transmitter Level (db) Object ID: 1.3.6.1.4.1.429.1.6.2.1.1.18.2001 Can you tell me where you 'found' this recomendation, was it from usr themselves? Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465 On Thu, 5 Jun 1997, David Bolen wrote: > "Adam Wills (Global 2000)" <sysadmin@global2000.net> writes: > > > We are now going to try to arrange for PRI's for the TC rack, even due to > > the increased price between PRI and Chan T1, its going to be necessary. > > One thing I havent done, as stupid as it sounds, is plug a POTS line into > > one of hte A/D quad cards and see if that gets me a 33.6 :) Now if that > > does, I think I would just cry (and I think it will work too). > > Oh, one other thing you might like to try - check to see what the > transmit signal strength is on your digital modem cards. I believe > the default may still be -11db depending on how the modem cards were > initialized, but I believe the recommendation is to run those cards > connected digitally at -13db. > > Having a signal that is a bit "too hot" can affect the ability of the > receiving modem to deal with it and might affect your connectivity. > Of course conversely if your lines have more attentuation somewhere > along the way, a hotter signal might be able to cut through it. > > I reset my digital modems to 13db as a standard part of our download > process. > > (This won't affect your x2 stuff, for x2 the modem has a preset signal > strength independent of the normal configured value). > > You can query change this using the mdmLiTransmitLevel MIB object > (it's in the "line interface" group, so if you're using TCM check for > that). The value is a number representing negative db. > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications \ Phone: (914) 789-5327 | > / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ > \-----------------------------------------------------------------------/ >

"Adam Wills (Global 2000)" <sysadmin@global2000.net> writes: > I tried out your suggest, going to the quad cards and changing the > TRansmitter Level (db) from 11 to 13, but every time i do it and click on > 'ok' or 'set' it says: Are you trying to change the setting while the modem is active or inactive? As with almost all modem settings, this can only be changed if the modem is currently idle. > Can you tell me where you 'found' this recomendation, was it from usr > themselves? Well, the actual recommendation to run at -13db was from USR a while back. I set this object all the time myself (as a stock part of our download process), so my bet is the problem isn't with the value itself, but just with something going on during the set operation, or as above, the modem being in use. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Will we ever see OSPF on the USR TC hubs? If so, is there an estimated time? 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

Whats the final word on Framed-Route? It was broken in 3.3.28 and early releases of 3.4.x, is it working yet? If so, what release? 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

We were running 3.3.28 on one of our Netservers. We changed to 3.4.23 and all the sudden we get this: Destination Gateway Flag Met Interface VPN -------------------- ---------------- ---- --- --------- --- 0.0.0.0 /0 208.214.44.1 NS 1 net0 0 208.214.44.77 /32 208.214.44.77 HL 1 ptp8 0 208.214.44.77 /32 208.214.44.77 HL 1 ptp8 0 208.214.44.77 /32 208.214.44.77 HL 16 ptp8 0 208.214.44.78 /32 208.214.44.78 HL 1 ptp18 0 208.214.44.78 /32 208.214.44.78 HL 1 ptp18 0 208.214.44.78 /32 208.214.44.78 HL 16 ptp18 0 208.206.76.0 /24 208.214.44.2 ND 2 net0 0 208.214.44.0 /24 208.214.44.53 NL 1 net0 0 Why are the routes being added 3 times?!?! Also, after about 10 minutes the hub becomes unpingable....... 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

We are having a problem with one of our TC Hubs: Netserver 3.4.23 Dual PRI 2.5.1 Non Packet Bus Clocking Chasis Whenever I reboot the netserver card, the PRI card loses its Quad Modem assignments, so I have to go into the PRI card and do: q:2,3,4,5,6,7,8,9,10,11,12,13 to make them come back. Do I have to assign these in TCM as well? Our other chasis work great, never a problem, this one keeps dumping. Also, just so you know, i DO save to NVRAM, and yes on startup the NVRAM test does pass. What could be causing this? Also, am I correct in that the PRI card should run in MASTER and the netserver should run in SLAVE whenever you have a Non packet bus clocking chasis? 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

Besides not being able to run the newer cards and having an overall less thruput, are there any other disadvantages to having a non packet bus clocking 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

Anyone here about when the new 24modem cards are to be out? it should would be nice to just buy cards instead of chasis. I assume they will have like a 100bT ethernet port on the hub, or a 10bT port per 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

We have been 'upgraded' to 3.4.79 and still no frame routes work. We have had a ticket (Ticket # 7042199) open for nearly 2 weeks now (w/o a call back in nearly 5 business days). I can't believe a product of this magnitude could not have framed routes by default built in, but the tech guys assure me 'they know its broken' but have ways around it (just havent had time to tell me how that is). When they told me I needed to put in static routes, I nearly laughed all the way out of my chair onto one of my $2,000 livingston pm30's that can do it for 1/10 th of the price :) I still havent been able to 'fully' deploy our X2 or TC rack because of this lacking feature, which is what a number of my customers use to route small lan's via dial'ups and such. I know its possible, because you couldn't possibly spend $20,000 like we and other ISP's have and NOT allow framed routes via radius... Just out of curiousity, what radius demon are you running? USR tried to blame the strictly RFC radius complaint Livingston Radius server 1.16 that we run, but quickly realized "oh yea, our netserver code is broke, sorry for pointing you in the wrong direction for the first 2 days", but I will believe just about anything some times :) Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465 On Mon, 9 Jun 1997, Brian wrote: > > Whats the final word on Framed-Route? It was broken in 3.3.28 and early > releases of 3.4.x, is it working yet? If so, what release? > > 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 > > >

We have been 'upgraded' to 3.4.79 and still no frame routes work. We have had a ticket (Ticket # 7042199) open for nearly 2 weeks now (w/o a call back in nearly 5 business days). I can't believe a product of this magnitude could not have framed routes by default built in, but the tech guys assure me 'they know its broken' but have ways around it (just havent had time to tell me how that is). When they told me I needed to put in static routes, I nearly laughed all the way out of my chair onto one of my $2,000 livingston pm30's that can do it for 1/10 th of the price :) I still havent been able to 'fully' deploy our X2 or TC rack because of this lacking feature, which is what a number of my customers use to route small lan's via dial'ups and such. I know its possible, because you couldn't possibly spend $20,000 like we and other ISP's have and NOT allow framed routes via radius... Just out of curiousity, what radius demon are you running? USR tried to blame the strictly RFC radius complaint Livingston Radius server 1.16 that we run, but quickly realized "oh yea, our netserver code is broke, sorry for pointing you in the wrong direction for the first 2 days", but I will believe just about anything some times :) Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465 On Mon, 9 Jun 1997, Brian wrote: > > Whats the final word on Framed-Route? It was broken in 3.3.28 and early > releases of 3.4.x, is it working yet? If so, what release? > > 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 Mon, 9 Jun 1997, Adam Wills (Global 2000) wrote: > We have been 'upgraded' to 3.4.79 and still no frame routes work. We have > had a ticket (Ticket # 7042199) open for nearly 2 weeks now (w/o a call > back in nearly 5 business days). I can't believe a product of this > magnitude could not have framed routes by default built in, but the tech > guys assure me 'they know its broken' but have ways around it (just havent > had time to tell me how that is). When they told me I needed to put in > static routes, I nearly laughed all the way out of my chair onto one of my > $2,000 livingston pm30's that can do it for 1/10 th of the price :) > > I still havent been able to 'fully' deploy our X2 or TC rack because of > this lacking feature, which is what a number of my customers use to route > small lan's via dial'ups and such. I know its possible, because you > couldn't possibly spend $20,000 like we and other ISP's have and NOT allow > framed routes via radius... > > Just out of curiousity, what radius demon are you running? USR tried to > blame the strictly RFC radius complaint Livingston Radius server 1.16 that > we run, but quickly realized "oh yea, our netserver code is broke, sorry > for pointing you in the wrong direction for the first 2 days", but I will > believe just about anything some times :) only 2 weeks? I opened a ticket with USR on this about 3 months ago. I was given .79, intalled it, it didn't work, so now I run 3.3.28. Framed-Route is essential I agree, it should be a priority. I run Merit, both the one they gave me and the normal distribution, neither works for Framed-Route. Adding static routes is the only way. Brian > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > > On Mon, 9 Jun 1997, Brian wrote: > > > > > Whats the final word on Framed-Route? It was broken in 3.3.28 and early > > releases of 3.4.x, is it working yet? If so, what release? > > > > Brian > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

On Mon, 9 Jun 1997, Adam Wills (Global 2000) wrote: > We have been 'upgraded' to 3.4.79 and still no frame routes work. We have > had a ticket (Ticket # 7042199) open for nearly 2 weeks now (w/o a call > back in nearly 5 business days). I can't believe a product of this > magnitude could not have framed routes by default built in, but the tech > guys assure me 'they know its broken' but have ways around it (just havent > had time to tell me how that is). When they told me I needed to put in > static routes, I nearly laughed all the way out of my chair onto one of my > $2,000 livingston pm30's that can do it for 1/10 th of the price :) > > I still havent been able to 'fully' deploy our X2 or TC rack because of > this lacking feature, which is what a number of my customers use to route > small lan's via dial'ups and such. I know its possible, because you > couldn't possibly spend $20,000 like we and other ISP's have and NOT allow > framed routes via radius... > > Just out of curiousity, what radius demon are you running? USR tried to > blame the strictly RFC radius complaint Livingston Radius server 1.16 that > we run, but quickly realized "oh yea, our netserver code is broke, sorry > for pointing you in the wrong direction for the first 2 days", but I will > believe just about anything some times :) only 2 weeks? I opened a ticket with USR on this about 3 months ago. I was given .79, intalled it, it didn't work, so now I run 3.3.28. Framed-Route is essential I agree, it should be a priority. I run Merit, both the one they gave me and the normal distribution, neither works for Framed-Route. Adding static routes is the only way. Brian > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > > On Mon, 9 Jun 1997, Brian wrote: > > > > > Whats the final word on Framed-Route? It was broken in 3.3.28 and early > > releases of 3.4.x, is it working yet? If so, what release? > > > > Brian > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > > > > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

I followed instruction on usr website to do ip dialout in netserver8. The Netserver 8 code is 3.2.5.3 and modem code is 1.0.8 and ncsi version is 1000. After installing all, it failed to open com4 port. Does anyone know about this?

On Mon, 9 Jun 1997, Brian wrote: > > only 2 weeks? I opened a ticket with USR on this about 3 months ago. I > was given .79, intalled it, it didn't work, so now I run 3.3.28. > Framed-Route is essential I agree, it should be a priority. > WOA :) We have a winner.. I thought I had it tought being on hold one day for over 7 hours, but I am pale in comparison to your 3 months w/o an answer :) If It makes you feel better (or worse) the tech on my ticket SAID he would get back to me (last week) and try to 'borrow' a TC system from developement to 'test' my setup to my radius server to find the problem with us. Still no call back, but im sure he will soon. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

On Mon, 9 Jun 1997, Brian wrote: > > only 2 weeks? I opened a ticket with USR on this about 3 months ago. I > was given .79, intalled it, it didn't work, so now I run 3.3.28. > Framed-Route is essential I agree, it should be a priority. > WOA :) We have a winner.. I thought I had it tought being on hold one day for over 7 hours, but I am pale in comparison to your 3 months w/o an answer :) If It makes you feel better (or worse) the tech on my ticket SAID he would get back to me (last week) and try to 'borrow' a TC system from developement to 'test' my setup to my radius server to find the problem with us. Still no call back, but im sure he will soon. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

Running the Dual PRI card for our x2 lines here....they're already getting full (not solely because of x2, long story), the problem I have is that once the lines get full, our users are either getting an all circuits busy message, or a fast busy signal. The fast busy signal is *better* as their modems will still redial on that, but it does still prompt them to call in to us and ask us what the problem is. I see in the PRI configuration that there are the cause codes for when certain conditions occur (including no B channels available), but they are all set to 58 I believe, which (apparently) means no circuits available. Does anyone know what the various codes that can be used here are? I didn't see them in any documentation (though I definitely could have missed it), but I would like a normal busy signal to be returned when all the B channels are used up. -- Jeff McAdams | "OK, we have enough youth... IgLou Internet Services | How about a fountain of smart?" e-mail: jeffm@iglou.com | - unknown

Jeff Mcadams said once upon a time: >I see in the PRI configuration that there are the cause codes for when >certain conditions occur (including no B channels available), but they are >all set to 58 I believe, which (apparently) means no circuits available. I'd like to see these as well. Please post them to the list.

Since going to a beta release for our netserver (V3.4.79), we have a lot of unknown attributes popping up in the RAD ACCOUNTING packets. Specifically, Attributes # 26,47,48 and 50. I run livingston's 1.16 radius server, and dictionary file. I have some add-ons to it, and the dictionary file reflects it. I can't dig up these attributes though from USR anywhere on their www page, so I figured I would ask here if anyone knows where to find the USR vendor specific attribute settings, or better yet where to find a full dictionary file that includes the new attributes used inthe not-yet released netserver 3.4.79 code. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

Brian said once upon a time: >Whenever I reboot the netserver card, the PRI card loses its Quad Modem >assignments, so I have to go into the PRI card and do: > >q:2,3,4,5,6,7,8,9,10,11,12,13 You have to go into each modem and set the "Line Interface Source" to "priTdm". I think it defaults to "t1Tdm" which is wrong for PRI. This is set via TCM under "Line Interface Options".

Jeff Mcadams said once upon a time: >>>I see in the PRI configuration that there are the cause codes for when >>>certain conditions occur (including no B channels available), but they are >>>all set to 58 I believe, which (apparently) means no circuits available. > >>I'd like to see these as well. Please post them to the list. > >How about a Dejanews URL. :) > >http://xp6.dejanews.com/getdoc.xp?recnum=%3cDG0BuK.FKG@world.std.com%3e&server=db95q4&CONTEXT=865959301.30149&hitnum=14 So based on this list, is "17" a better choice than "58"?

I got a USR tech to mail me their latest dictionary file, and I 'slapped' it in there. I still get entries like this on our Tc though: Tue Jun 10 13:52:53 1997 Acct-Session-Id = "01010100" User-Name = "egilb" Client-Id = 208.133.140.101 Client-Port-Id = 6 Acct-Status-Type = Stop Acct-Session-Time = 558 Acct-Terminate-Cause = ACCT_TERM_LOST_CARRIER Acct-Authentic = RADIUS Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" NAS-Identifier = "tc1" Acct-Input-Octets = 46607 Acct-Output-Octets = 496770 Acct-Input-Packets = 1110 Acct-Output-Packets = 959 NAS-Port-Type = Async User-Service-Type = Framed-User Framed-Protocol = PPP Framed-Address = 208.133.143.222 Acct-Delay-Time = 0 Anyone know what Vendor-Specific = "" Is? it ONLY comes from my USR's, and its Radius ACcounting Attribute #26: ATTRIBUTE Vendor-Specific 26 string Shouldn't they, USr, have some sort of sub-heading that lists the values and such for their 'Vendor-Specific' codes? I'm a bit annoyed with the 4 lines of garbage each entry now has, but further I want to know what it IS tryuing to report. If anyone wants the entire dictionary file that USR tech support mailed me, let me nkow. It even includes the connection speed and transmit speeds etc of the conection in the dictionary file (no that info does NOT appear at all, but i suspect it will in a future netserver release). Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

>>I see in the PRI configuration that there are the cause codes for when >>certain conditions occur (including no B channels available), but they are >>all set to 58 I believe, which (apparently) means no circuits available. >I'd like to see these as well. Please post them to the list. How about a Dejanews URL. :) http://xp6.dejanews.com/getdoc.xp?recnum=%3cDG0BuK.FKG@world.std.com%3e&server=db95q4&CONTEXT=865959301.30149&hitnum=14 -- Jeff McAdams | "OK, we have enough youth... IgLou Internet Services | How about a fountain of smart?" e-mail: jeffm@iglou.com | - unknown

On Tue, 10 Jun 1997, Adam Wills (Global 2000) wrote: > I got a USR tech to mail me their latest dictionary file, and I 'slapped' > it in there. I still get entries like this on our Tc though: > > Tue Jun 10 13:52:53 1997 > Acct-Session-Id = "01010100" > User-Name = "egilb" > Client-Id = 208.133.140.101 > Client-Port-Id = 6 > Acct-Status-Type = Stop > Acct-Session-Time = 558 > Acct-Terminate-Cause = ACCT_TERM_LOST_CARRIER > Acct-Authentic = RADIUS > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > NAS-Identifier = "tc1" > Acct-Input-Octets = 46607 > Acct-Output-Octets = 496770 > Acct-Input-Packets = 1110 > Acct-Output-Packets = 959 > NAS-Port-Type = Async > User-Service-Type = Framed-User > Framed-Protocol = PPP > Framed-Address = 208.133.143.222 > Acct-Delay-Time = 0 > > > Anyone know what Vendor-Specific = "" Its a rfc based Attribute -Refer to RFC 2138 page 19. It talks about attribute 26 > > Is? it ONLY comes from my USR's, and its Radius ACcounting Attribute #26: > > ATTRIBUTE Vendor-Specific 26 string > > > Shouldn't they, USr, have some sort of sub-heading that lists the values > and such for their 'Vendor-Specific' codes? I'm a bit annoyed with the 4 > lines of garbage each entry now has, but further I want to know what it IS > tryuing to report. If anyone wants the entire dictionary file that USR > tech support mailed me, let me nkow. It even includes the connection > speed and transmit speeds etc of the conection in the dictionary file (no > that info does NOT appear at all, but i suspect it will in a future > netserver release). > > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > >

Thus spake Pete Ashdown >So based on this list, is "17" a better choice than "58"? That's how I interpret it...as we haven't hit our peak time since I changed that, I'm not sure how it will behave with the 17 value rather than the 58. I'll let you know tomorrow. :) -- Jeff McAdams | "OK, we have enough youth... IgLou Internet Services | How about a fountain of smart?" e-mail: jeffm@iglou.com | - unknown

# # $Header: /var/source/cvsroot/radius/menu/raddb/dictionary,v 1.3 1997/03/28 00:01:41 vkrishna Exp $ # # $Log: dictionary,v $ # Revision 1.3 1997/03/28 00:01:41 vkrishna # Added CCA specific Termination-Action # Changed Primary and Secondary DNS types to ipaddr. The USR security server # dictionary had them as strings, but the NetServer would not work with those # values as strings. # Oh Well! # # Revision 1.2 1997/03/05 00:42:51 vkrishna # Added attributes and comments. # # Revision 1.1 1997/02/19 21:07:41 vkrishna # Added the raddb directory and its contents # # Revision 1.6 1997/02/14 20:24:13 vkrishna # *** empty log message *** # # Revision 1.5 1997/02/14 12:21:29 vkrishna # *** empty log message *** # # Revision 1.4 1997/02/14 12:17:09 vkrishna # Corrected to reflect RFCs 2058 and 2059 # # Revision 1.3 1997/02/14 10:57:05 vkrishna # Updated to RFC2058 # # # # This file contains dictionary translations for parsing # requests and generating responses. All transactions are # composed of Attribute/Value Pairs. The value of each attribute # is specified as one of 4 data types. Valid data types are: # # string - 0-253 octets # ipaddr - 4 octets in network byte order # integer - 32 bit value in big endian order (high byte first) # date - 32 bit value in big endian order - seconds since # 00:00:00 GMT, Jan. 1, 1970 # # Enumerated values are stored in the user file with dictionary # VALUE translations for easy administration. # # Example: # # ATTRIBUTE VALUE # --------------- ----- # Framed-Protocol = PPP # 7 = 1 (integer encoding) # ATTRIBUTE User-Name 1 string ATTRIBUTE Password 2 string ATTRIBUTE CHAP-Password 3 string ATTRIBUTE Client-Id 4 ipaddr ATTRIBUTE Client-Port-Id 5 integer ATTRIBUTE User-Service-Type 6 integer ATTRIBUTE Framed-Protocol 7 integer ATTRIBUTE Framed-Address 8 ipaddr ATTRIBUTE Framed-Netmask 9 ipaddr ATTRIBUTE Framed-Routing 10 integer ATTRIBUTE Framed-Filter-Id 11 string ATTRIBUTE Framed-MTU 12 integer ATTRIBUTE Framed-Compression 13 integer ATTRIBUTE Login-Host 14 ipaddr ATTRIBUTE Login-Service 15 integer ATTRIBUTE Login-TCP-Port 16 integer #ATTRIBUTE Old-Password 17 string ATTRIBUTE Port-Message 18 string ATTRIBUTE Dialback-No 19 string ATTRIBUTE Dialback-Name 20 string #ATTRIBUTE Expiration 21 date ATTRIBUTE Framed-Route 22 string ATTRIBUTE Framed-IPX-Network 23 ipaddr ATTRIBUTE Challenge-State 24 string ATTRIBUTE Class 25 string ATTRIBUTE Vendor-Specific 26 string ATTRIBUTE Session-Timeout 27 integer ATTRIBUTE Idle-Timeout 28 integer ATTRIBUTE Termination-Action 29 integer ATTRIBUTE Called-Station-Id 30 string ATTRIBUTE Calling-Station-Id 31 string ATTRIBUTE NAS-Identifier 32 string ATTRIBUTE Proxy-State 33 string ATTRIBUTE Login-LAT-Service 34 string ATTRIBUTE Login-LAT-Node 35 string ATTRIBUTE Login-LAT-Group 36 string ATTRIBUTE Framed-AppleTalk-Link 37 integer ATTRIBUTE Framed-AppleTalk-Network 38 integer ATTRIBUTE Framed-AppleTalk-Zone 39 string ATTRIBUTE Acct-Status-Type 40 integer ATTRIBUTE Acct-Delay-Time 41 integer ATTRIBUTE Acct-Input-Octets 42 integer ATTRIBUTE Acct-Output-Octets 43 integer ATTRIBUTE Acct-Session-Id 44 string ATTRIBUTE Acct-Authentic 45 integer ATTRIBUTE Acct-Session-Time 46 integer ATTRIBUTE Acct-Input-Packets 47 integer ATTRIBUTE Acct-Output-Packets 48 integer ATTRIBUTE Acct-Terminate-Cause 49 integer ATTRIBUTE Acct-Multi-Session-Id 50 string ATTRIBUTE Acct-Link-Count 51 integer ATTRIBUTE CHAP-Challenge 60 string ATTRIBUTE NAS-Port-Type 61 integer ATTRIBUTE Port-Limit 62 integer ATTRIBUTE Login-LAT-Port 63 string # Prompt value should be 1 for echo, 0 for no echo, default 1. ATTRIBUTE Prompt 64 integer # USR only attribute - set if client should hide the user typed in text ATTRIBUTE Char-Noecho 250 integer # # Integer Translations # # Termination-Action VALUE Termination-Action Default 0 VALUE Termination-Action RADIUS-Request 1 VALUE Termination-Action Manage-Resources 2 # User Types VALUE User-Service-Type Login-User 1 VALUE User-Service-Type Framed-User 2 VALUE User-Service-Type Dialback-Login-User 3 VALUE User-Service-Type Dialback-Framed-User 4 VALUE User-Service-Type Outbound-User 5 VALUE User-Service-Type Administrative-User 6 VALUE User-Service-Type NAS-Prompt-User 7 VALUE User-Service-Type Authenticate-User 8 VALUE User-Service-Type Dialback-NAS-User 9 # Framed Protocols VALUE Framed-Protocol PPP 1 VALUE Framed-Protocol SLIP 2 # Framed Routing Values VALUE Framed-Routing None 0 VALUE Framed-Routing Broadcast 1 VALUE Framed-Routing Listen 2 VALUE Framed-Routing Broadcast-Listen 3 # Framed Compression Types VALUE Framed-Compression None 0 VALUE Framed-Compression Van-Jacobsen-TCP-IP 1 # Login Services VALUE Login-Service Telnet 0 VALUE Login-Service Rlogin 1 VALUE Login-Service TCP-Clear 2 VALUE Login-Service PortMaster 3 # Status Types VALUE Acct-Status-Type Start 1 VALUE Acct-Status-Type Stop 2 VALUE Acct-Status-Type Accounting-On 7 VALUE Acct-Status-Type Accounting-Off 8 # Authentication Types VALUE Acct-Authentic None 0 VALUE Acct-Authentic RADIUS 1 VALUE Acct-Authentic Local 2 VALUE Acct-Authentic Remote 3 # # The following values are implementation and site dependent # and not transmitted as part of the protocol # # Configuration Values VALUE Server-Config Password-Expiration 30 VALUE Server-Config Password-Warning 5 # # # US Robotics specific attributes # # NMC Attributes using Vendor-Specific # ATTRIB_NMC Last-Number-Dialed-Out 0x0066 string ATTRIB_NMC Last-Number-Dialed-In-DNIS 0x00E8 string ATTRIB_NMC Last-Callers-Number-ANI 0x00E9 string ATTRIB_NMC Channel 0xBF38 integer ATTRIB_NMC Event-Id 0xBFBE integer ATTRIB_NMC Event-Date-Time 0xBF2F date ATTRIB_NMC Call-Start-Date-Time 0xBFF7 date ATTRIB_NMC Call-End-Date-Time 0xBFF6 date ATTRIB_NMC Default-DTE-Data-Rate 0x005E integer ATTRIB_NMC Initial-Rx-Link-Data-Rate 0xBF2D integer ATTRIB_NMC Final-Rx-Link-Data-Rate 0xBF2C integer ATTRIB_NMC Initial-Tx-Link-Data-Rate 0x006A integer ATTRIB_NMC Final-Tx-Link-Data-Rate 0x006B integer ATTRIB_NMC Chassis-Temperature 0xBF31 integer ATTRIB_NMC Chassis-Temp-Threshold 0xBE84 integer ATTRIB_NMC Actual-Voltage 0xBF32 integer ATTRIB_NMC Expected-Voltage 0xBF33 integer ATTRIB_NMC Power-Supply-Number 0xBF34 integer ATTRIB_NMC Card-Type 0xBE85 integer ATTRIB_NMC Chassis-Slot 0xBF39 integer ATTRIB_NMC Sync-Async-Mode 0x0067 integer ATTRIB_NMC Originate-Answer-Mode 0x0068 integer ATTRIB_NMC Modulation-Type 0x006C integer ATTRIB_NMC Connect-Term-Reason 0x009B integer ATTRIB_NMC Failure-to-Connect-Reason 0x0069 integer ATTRIB_NMC Equalization-Type 0x006F integer ATTRIB_NMC Fallback-Enabled 0x0070 integer ATTRIB_NMC Connect-Time-Limit 0xBFE7 integer ATTRIB_NMC Number-of-Rings-Limit 0xBFE6 integer ATTRIB_NMC DTE-Data-Idle-Timout 0x0048 integer ATTRIB_NMC Characters-Sent 0x0071 integer ATTRIB_NMC Characters-Received 0x0072 integer ATTRIB_NMC Blocks-Sent 0x0075 integer ATTRIB_NMC Blocks-Received 0x0076 integer ATTRIB_NMC Blocks-Resent 0x0077 integer ATTRIB_NMC Retrains-Requested 0x0078 integer ATTRIB_NMC Retrains-Granted 0x0079 integer ATTRIB_NMC Line-Reversals 0x007A integer ATTRIB_NMC Number-Of-Characters-Lost 0x007B integer ATTRIB_NMC Number-of-Blers 0x007D integer ATTRIB_NMC Number-of-Link-Timeouts 0x007E integer ATTRIB_NMC Number-of-Fallbacks 0x007F integer ATTRIB_NMC Number-of-Upshifts 0x0080 integer ATTRIB_NMC Number-of-Link-NAKs 0x0081 integer ATTRIB_NMC DTR-False-Timeout 0x00BE integer ATTRIB_NMC Fallback-Limit 0x00BF integer ATTRIB_NMC Block-Error-Count-Limit 0x00C0 integer ATTRIB_NMC DTR-True-Timeout 0x00DA integer ATTRIB_NMC Security-Login-Limit 0xBEDE integer ATTRIB_NMC Security-Resp-Limit 0xBEFA integer ATTRIB_NMC DTE-Ring-No-Answer-Limit 0xBF17 integer ATTRIB_NMC Back-Channel-Data-Rate 0x007C integer ATTRIB_NMC Simplified-MNP-Levels 0x0099 integer ATTRIB_NMC Simplified-V42bis-Usage 0x00C7 integer ATTRIB_NMC Mbi_Ct_PRI_Card_Slot 0x0184 integer ATTRIB_NMC Mbi_Ct_TDM_Time_Slot 0x0185 integer ATTRIB_NMC Mbi_Ct_PRI_Card_Span_Line 0x0186 integer ATTRIB_NMC Mbi_Ct_BChannel_Used 0x0187 integer ATTRIB_NMC Physical-State 0xBE77 integer ATTRIB_NMC Packet-Bus-Session 0xBF14 integer ATTRIB_NMC Server-Time 0xF000 date # 0xBE5D-0xBE63 sent with Event-Id 79 ATTRIB_NMC Channel-Connected-To 0xBE5D integer ATTRIB_NMC Slot-Connected-To 0xBE5E integer ATTRIB_NMC Device-Connected-To 0xBE5F integer ATTRIB_NMC NFAS-ID 0xBE60 integer ATTRIB_NMC Q931-Call-Reference-Value 0xBE61 integer ATTRIB_NMC Call-Event-Code 0xBE62 integer ATTRIB_NMC DS0 0xBE63 integer # DS0s sent with Event-Id 77,78 ATTRIB_NMC DS0s 0xBE64 string # Gateway-IP-Address sent with Event-Id 71,72 ATTRIB_NMC Gateway-IP-Address 0xBE66 ipaddr # # These are CCA Radius attributes # ATTRIB_NMC PW_USR_IFilter_IP 0x9000 string ATTRIB_NMC PW_USR_IFilter_IPX 0x9001 string ATTRIB_NMC PW_USR_OFilter_IP 0x9003 string ATTRIB_NMC PW_USR_OFilter_IPX 0x9004 string ATTRIB_NMC PW_USR_OFilter_SAP 0x9005 string ATTRIB_NMC PW_VPN_ID 0x9006 string ATTRIB_NMC PW_VPN_Name 0x9007 string ATTRIB_NMC PW_VPN_Neighbor 0x9008 string ATTRIB_NMC PW_Framed_Routing_V2 0x9009 string ATTRIB_NMC PW_VPN_Gateway 0x900a string ATTRIB_NMC PW_Tunnel_Authentication 0x900b string ATTRIB_NMC PW_Index 0x900c string ATTRIB_NMC PW_Cutoff 0x900d string ATTRIB_NMC PW_Packet 0x900e string ATTRIB_NMC Primary_DNS_Server 0x900f ipaddr ATTRIB_NMC Secondary_DNS_Server 0x9010 ipaddr ATTRIB_NMC Primary_NBNS_Server 0x9011 ipaddr ATTRIB_NMC Secondary_NBNS_Server 0x9012 ipaddr ATTRIB_NMC Syslog-Tap 0x9013 integer ATTRIB_NMC Chassis-Call-Slot 0x9019 integer ATTRIB_NMC Chassis-Call-Span 0x901A integer ATTRIB_NMC Chassis-Call-Channel 0x901B integer ATTRIB_NMC Keypress-Timeout 0x901C integer ATTRIB_NMC Unauthenticated-Time 0x901D integer # # Pilgrim attributes # ATTRIB_NMC Bearer-Capabilities 0x9800 integer ATTRIB_NMC Speed-Of-Connection 0x9801 integer ATTRIB_NMC Max-Channels 0x9802 integer ATTRIB_NMC Channel-Expansion 0x9803 integer ATTRIB_NMC Channel-Decrement 0x9804 integer ATTRIB_NMC Expansion-Algorithm 0x9805 integer ATTRIB_NMC Compression-Algorithm 0x9806 integer ATTRIB_NMC Receive-Acc-Map 0x9807 integer ATTRIB_NMC Transmit-Acc-Map 0x9808 integer ATTRIB_NMC Compression-Reset-Mode 0x980a integer ATTRIB_NMC Min-Compression-Size 0x980b integer ATTRIB_NMC IP 0x980c integer ATTRIB_NMC IPX 0x980d integer ATTRIB_NMC Filter-Zones 0x980e integer ATTRIB_NMC Appletalk 0x980f integer ATTRIB_NMC Bridging 0x9810 integer ATTRIB_NMC Spoofing 0x9811 integer ATTRIB_NMC Host-Type 0x9812 integer ATTRIB_NMC Send-Name 0x9813 string ATTRIB_NMC Send-Password 0x9814 string ATTRIB_NMC Start-Time 0x9815 integer ATTRIB_NMC End-Time 0x9816 integer ATTRIB_NMC Send-Script1 0x9817 string ATTRIB_NMC Reply-Script1 0x9818 string ATTRIB_NMC Send-Script2 0x9819 string ATTRIB_NMC Reply-Script2 0x981a string ATTRIB_NMC Send-Script3 0x981b string ATTRIB_NMC Reply-Script3 0x981c string ATTRIB_NMC Send-Script4 0x981d string ATTRIB_NMC Reply-Script4 0x981e string ATTRIB_NMC Send-Script5 0x981f string ATTRIB_NMC Reply-Script5 0x9820 string ATTRIB_NMC Send-Script6 0x9821 string ATTRIB_NMC Reply-Script6 0x9822 string ATTRIB_NMC Terminal-Type 0x9823 string ATTRIB_NMC Appletalk-Network-Range 0x9824 integer ATTRIB_NMC Local-IP-Address 0x9825 string ATTRIB_NMC Routing-Protocol 0x9826 integer ATTRIB_NMC Modem-Group 0x9827 integer # # Integer Translations # # Acct-Terminate-Cause VALUE Acct-Terminate-Cause ACCT_TERM_USER_REQUEST 1 VALUE Acct-Terminate-Cause ACCT_TERM_LOST_CARRIER 2 VALUE Acct-Terminate-Cause ACCT_TERM_LOST_SERVICE 3 VALUE Acct-Terminate-Cause ACCT_TERM_IDLE_TIMEOUT 4 VALUE Acct-Terminate-Cause ACCT_TERM_SESSION_TIMEOUT 5 VALUE Acct-Terminate-Cause ACCT_TERM_ADMIN_RESET 6 VALUE Acct-Terminate-Cause ACCT_TERM_ADMIN_REBOOT 7 VALUE Acct-Terminate-Cause ACCT_TERM_PORT_ERROR 8 VALUE Acct-Terminate-Cause ACCT_TERM_NAS_ERROR 9 VALUE Acct-Terminate-Cause ACCT_TERM_NAS_REQUEST 10 VALUE Acct-Terminate-Cause ACCT_TERM_NAS_REBOOT 11 VALUE Acct-Terminate-Cause ACCT_TERM_PORT_UNNEEDED 12 VALUE Acct-Terminate-Cause ACCT_TERM_PORT_PREEMPTED 13 VALUE Acct-Terminate-Cause ACCT_TERM_PORT_SUSPENDED 14 VALUE Acct-Terminate-Cause ACCT_TERM_SERVICE_UNAVAIL 15 VALUE Acct-Terminate-Cause ACCT_TERM_CALLBACK 16 VALUE Acct-Terminate-Cause ACCT_TERM_USER_ERROR 17 VALUE Acct-Terminate-Cause ACCT_TERM_HOST_REQUEST 18 # Event Indentifiers VALUE Event-Id Module-Inserted 6 VALUE Event-Id Module-Removed 7 VALUE Event-Id PSU-Voltage-Alarm 8 VALUE Event-Id PSU-Failed 9 VALUE Event-Id HUB-Temp-Out-of-Range 10 VALUE Event-Id Fan-Failed 11 VALUE Event-Id Watchdog-Timeout 12 VALUE Event-Id Mgmt-Bus-Failure 13 VALUE Event-Id In-Connection-Est 14 VALUE Event-Id Out-Connection-Est 15 VALUE Event-Id In-Connection-Term 16 VALUE Event-Id Out-Connection-Term 17 VALUE Event-Id Connection-Failed 18 VALUE Event-Id Connection-Timeout 19 VALUE Event-Id DTE-Transmit-Idle 20 VALUE Event-Id DTR-True 21 VALUE Event-Id DTR-False 22 VALUE Event-Id Block-Error-at-Threshold 23 VALUE Event-Id Fallbacks-at-Threshold 24 VALUE Event-Id No-Dial-Tone-Detected 25 VALUE Event-Id No-Loop-Current-Detected 26 VALUE Event-Id Yellow-Alarm 27 VALUE Event-Id Red-Alarm 28 VALUE Event-Id Loss-Of-Signal 29 VALUE Event-Id Rcv-Alrm-Ind-Signal 30 VALUE Event-Id Timing-Source-Switch 31 VALUE Event-Id Modem-Reset-by-DTE 32 VALUE Event-Id Modem-Ring-No-Answer 33 VALUE Event-Id DTE-Ring-No-Answer 34 VALUE Event-Id Pkt-Bus-Session-Active 35 VALUE Event-Id Pkt-Bus-Session-Congestion 36 VALUE Event-Id Pkt-Bus-Session-Lost 37 VALUE Event-Id Pkt-Bus-Session-Inactive 38 VALUE Event-Id User-Interface-Reset 39 VALUE Event-Id Gateway-Port-Out-of-Service 40 VALUE Event-Id Gateway-Port-Link-Active 41 VALUE Event-Id Dial-Out-Login-Failure 42 VALUE Event-Id Dial-In-Login-Failure 43 VALUE Event-Id Dial-Out-Restricted-Number 44 VALUE Event-Id Dial-Back-Restricted-Number 45 VALUE Event-Id User-Blacklisted 46 VALUE Event-Id Attempted-Login-Blacklisted 47 VALUE Event-Id Response-Attempt-Limit-Exceeded 48 VALUE Event-Id Login-Attempt-Limit-Exceeded 49 VALUE Event-Id Dial-Out-Call-Duration 50 VALUE Event-Id Dial-In-Call-Duration 51 VALUE Event-Id Pkt-Bus-Session-Err-Status 52 VALUE Event-Id NMC-AutoRespnse-Trap 53 VALUE Event-Id Acct-Server-Contact-Loss 54 VALUE Event-Id Yellow-Alarm-Clear 55 VALUE Event-Id Red-Alarm-Clear 56 VALUE Event-Id Loss-Of-Signal-Clear 57 VALUE Event-Id Rcv-Alrm-Ind-Signal-Clear 58 VALUE Event-Id Incoming-Connection-Established 59 VALUE Event-Id Outgoing-Connection-Established 60 VALUE Event-Id Incoming-Connection-Terminated 61 VALUE Event-Id Outgoing-Connection-Terminated 62 VALUE Event-Id Connection-Attempt-Failure 63 VALUE Event-Id Continuous-CRC-Alarm 64 VALUE Event-Id Continuous-CRC-Alarm-Clear 65 VALUE Event-Id Physical-State-Change 66 VALUE Event-Id Gateway-Network-Failed 71 VALUE Event-Id Gateway-Network-Restored 72 VALUE Event-Id Packet-Bus-Clock-Lost 73 VALUE Event-Id Packet-Bus-Clock-Restored 74 VALUE Event-Id D-Channel-In-Service 75 VALUE Event-Id D-Channel-Out-of-Service 76 VALUE Event-Id DS0s-In-Service 77 VALUE Event-Id DS0s-Out-of-Service 78 VALUE Event-Id T1/T1PRI/E1PRI-Call-Event 79 VALUE Event-Id Psu-Incompatible 80 VALUE Card-Type SlotEmpty 1 VALUE Card-Type SlotUnknown 2 VALUE Card-Type NetwMgtCard 3 VALUE Card-Type DualT1NAC 4 VALUE Card-Type DualModemNAC 5 VALUE Card-Type QuadModemNAC 6 VALUE Card-Type TrGatewayNAC 7 VALUE Card-Type X25GatewayNAC 8 VALUE Card-Type DualV34ModemNAC 9 VALUE Card-Type QuadV32DigitalModemNAC 10 VALUE Card-Type QuadV32AnalogModemNAC 11 VALUE Card-Type QuadV32DigAnlModemNAC 12 VALUE Card-Type QuadV34DigModemNAC 13 VALUE Card-Type QuadV34AnlModemNAC 14 VALUE Card-Type QuadV34DigAnlModemNAC 15 VALUE Card-Type SingleT1NAC 16 VALUE Card-Type EthernetGatewayNAC 17 VALUE Card-Type AccessServer 18 VALUE Card-Type 486TrGatewayNAC 19 VALUE Card-Type 486EthernetGatewayNAC 20 VALUE Card-Type DualRS232NAC 22 VALUE Card-Type 486X25GatewayNAC 23 VALUE Card-Type ApplicationServerNAC 25 VALUE Card-Type ISDNGatewayNAC 26 VALUE Card-Type ISDNpriT1NAC 27 VALUE Card-Type ClkedNetMgtCard 28 VALUE Card-Type ModemPoolManagementNAC 29 VALUE Card-Type ModemPoolNetserverNAC 30 VALUE Card-Type ModemPoolV34ModemNAC 31 VALUE Card-Type ModemPoolISDNNAC 32 VALUE Card-Type NTServerNAC 33 VALUE Card-Type QuadV34DigitalG2NAC 34 VALUE Card-Type QuadV34AnalogG2NAC 35 VALUE Card-Type QuadV34DigAnlgG2NAC 36 VALUE Card-Type NETServerFrameRelayNAC 37 VALUE Card-Type NETServerTokenRingNAC 38 VALUE Card-Type X2524ChannelNAC 39 VALUE Card-Type WirelessGatewayNac 42 VALUE Card-Type EnhancedAccessServer 44 VALUE Card-Type EnhancedISDNGatewayNAC 45 VALUE Card-Type DualT1NIC 1001 VALUE Card-Type DualAlogMdmNIC 1002 VALUE Card-Type QuadDgtlMdmNIC 1003 VALUE Card-Type QuadAlogDgtlMdmNIC 1004 VALUE Card-Type TokenRingNIC 1005 VALUE Card-Type SingleT1NIC 1006 VALUE Card-Type EthernetNIC 1007 VALUE Card-Type ShortHaulDualT1NIC 1008 VALUE Card-Type DualAlogMgdIntlMdmNIC 1009 VALUE Card-Type X25NIC 1010 VALUE Card-Type QuadAlogNonMgdMdmNIC 1011 VALUE Card-Type QuadAlogMgdIntlMdmNIC 1012 VALUE Card-Type QuadAlogNonMgdIntlMdmNIC 1013 VALUE Card-Type QuadLsdLiMgdMdmNIC 1014 VALUE Card-Type QuadLsdLiNonMgdMdmNIC 1015 VALUE Card-Type QuadLsdLiMgdIntlMdmNIC 1016 VALUE Card-Type QuadLsdLiNonMgdIntlMdmNIC 1017 VALUE Card-Type HSEthernetWithV35NIC 1018 VALUE Card-Type HSEthernetWithoutV35NIC 1019 VALUE Card-Type DualHighSpeedV35NIC 1020 VALUE Card-Type QuadV35RS232LowSpeedNIC 1021 VALUE Card-Type DualE1NIC 1022 VALUE Card-Type ShortHaulDualE1NIC 1023 VALUE Card-Type BellcoreLongHaulDualT1NIC 1025 VALUE Card-Type BellcoreShrtHaulDualT1NIC 1026 VALUE Card-Type SCSIEdgeServerNIC 1027 VALUE Default-DTE-Data-Rate 110-BPS 1 VALUE Default-DTE-Data-Rate 300-BPS 2 VALUE Default-DTE-Data-Rate 600-BPS 3 VALUE Default-DTE-Data-Rate 1200-BPS 4 VALUE Default-DTE-Data-Rate 2400-BPS 5 VALUE Default-DTE-Data-Rate 4800-BPS 6 VALUE Default-DTE-Data-Rate 7200-BPS 7 VALUE Default-DTE-Data-Rate 9600-BPS 8 VALUE Default-DTE-Data-Rate 12K-BPS 9 VALUE Default-DTE-Data-Rate 14.4K-BPS 10 VALUE Default-DTE-Data-Rate 16.8-BPS 11 VALUE Default-DTE-Data-Rate 19.2K-BPS 12 VALUE Default-DTE-Data-Rate 38.4K-BPS 13 VALUE Default-DTE-Data-Rate 75-BPS 14 VALUE Default-DTE-Data-Rate 450-BPS 15 VALUE Default-DTE-Data-Rate UNKNOWN-BPS 16 VALUE Default-DTE-Data-Rate 57.6K-BPS 17 VALUE Default-DTE-Data-Rate 21.6K-BPS 18 VALUE Default-DTE-Data-Rate 24K-BPS 19 VALUE Default-DTE-Data-Rate 26K-BPS 20 VALUE Default-DTE-Data-Rate 28K-BPS 21 VALUE Default-DTE-Data-Rate 115K-BPS 22 VALUE Initial-Rx-Link-Data-Rate 110-BPS 1 VALUE Initial-Rx-Link-Data-Rate 300-BPS 2 VALUE Initial-Rx-Link-Data-Rate 600-BPS 3 VALUE Initial-Rx-Link-Data-Rate 1200-BPS 4 VALUE Initial-Rx-Link-Data-Rate 2400-XBPS 5 VALUE Initial-Rx-Link-Data-Rate 4800-BPS 6 VALUE Initial-Rx-Link-Data-Rate 7200-BPS 7 VALUE Initial-Rx-Link-Data-Rate 9600-BPS 8 VALUE Initial-Rx-Link-Data-Rate 12K-BPS 9 VALUE Initial-Rx-Link-Data-Rate 14.4K-BPS 10 VALUE Initial-Rx-Link-Data-Rate 16.8-BPS 11 VALUE Initial-Rx-Link-Data-Rate 19.2K-BPS 12 VALUE Initial-Rx-Link-Data-Rate 38.4K-BPS 13 VALUE Initial-Rx-Link-Data-Rate 75-BPS 14 VALUE Initial-Rx-Link-Data-Rate 450-BPS 15 VALUE Initial-Rx-Link-Data-Rate UNKNOWN-BPS 16 VALUE Initial-Rx-Link-Data-Rate 57.6K-BPS 17 VALUE Initial-Rx-Link-Data-Rate 21.6K-BPS 18 VALUE Initial-Rx-Link-Data-Rate 24K-BPS 19 VALUE Initial-Rx-Link-Data-Rate 26K-BPS 20 VALUE Initial-Rx-Link-Data-Rate 28K-BPS 21 VALUE Initial-Rx-Link-Data-Rate 115K-BPS 22 VALUE Initial-Rx-Link-Data-Rate 31K-BPS 23 VALUE Initial-Rx-Link-Data-Rate 33K-BPS 24 VALUE Initial-Rx-Link-Data-Rate 32K-BPS 25 VALUE Initial-Rx-Link-Data-Rate 36K-BPS 26 VALUE Initial-Rx-Link-Data-Rate 40K-BPS 27 VALUE Initial-Rx-Link-Data-Rate 44K-BPS 28 VALUE Initial-Rx-Link-Data-Rate 48K-BPS 29 VALUE Initial-Rx-Link-Data-Rate 49333-BPS 30 VALUE Initial-Rx-Link-Data-Rate 50666-BPS 31 VALUE Initial-Rx-Link-Data-Rate 52K-BPS 32 VALUE Initial-Rx-Link-Data-Rate 53333-BPS 33 VALUE Initial-Rx-Link-Data-Rate 54666-BPS 34 VALUE Initial-Rx-Link-Data-Rate 56K-BPS 35 VALUE Initial-Rx-Link-Data-Rate 57333-BPS 36 VALUE Initial-Rx-Link-Data-Rate 58666-BPS 37 VALUE Initial-Rx-Link-Data-Rate 60K-BPS 38 VALUE Initial-Rx-Link-Data-Rate 61333-BPS 39 VALUE Initial-Rx-Link-Data-Rate 64K-BPS 40 VALUE Final-Rx-Link-Data-Rate 110-BPS 1 VALUE Final-Rx-Link-Data-Rate 300-BPS 2 VALUE Final-Rx-Link-Data-Rate 600-BPS 3 VALUE Final-Rx-Link-Data-Rate 1200-BPS 4 VALUE Final-Rx-Link-Data-Rate 2400-BPS 5 VALUE Final-Rx-Link-Data-Rate 4800-BPS 6 VALUE Final-Rx-Link-Data-Rate 7200-BPS 7 VALUE Final-Rx-Link-Data-Rate 9600-BPS 8 VALUE Final-Rx-Link-Data-Rate 12K-BPS 9 VALUE Final-Rx-Link-Data-Rate 14.4K-BPS 10 VALUE Final-Rx-Link-Data-Rate 16.8-BPS 11 VALUE Final-Rx-Link-Data-Rate 19.2K-BPS 12 VALUE Final-Rx-Link-Data-Rate 38.4K-BPS 13 VALUE Final-Rx-Link-Data-Rate 75-BPS 14 VALUE Final-Rx-Link-Data-Rate 450-BPS 15 VALUE Final-Rx-Link-Data-Rate UNKNOWN-BPS 16 VALUE Final-Rx-Link-Data-Rate 57.6K-BPS 17 VALUE Final-Rx-Link-Data-Rate 21.6K-BPS 18 VALUE Final-Rx-Link-Data-Rate 24K-BPS 19 VALUE Final-Rx-Link-Data-Rate 26K-BPS 20 VALUE Final-Rx-Link-Data-Rate 28K-BPS 21 VALUE Final-Rx-Link-Data-Rate 115K-BPS 22 VALUE Final-Rx-Link-Data-Rate 31K-BPS 23 VALUE Final-Rx-Link-Data-Rate 33K-BPS 24 VALUE Final-Rx-Link-Data-Rate 32K-BPS 25 VALUE Final-Rx-Link-Data-Rate 36K-BPS 26 VALUE Final-Rx-Link-Data-Rate 40K-BPS 27 VALUE Final-Rx-Link-Data-Rate 44K-BPS 28 VALUE Final-Rx-Link-Data-Rate 48K-BPS 29 VALUE Final-Rx-Link-Data-Rate 49333-BPS 30 VALUE Final-Rx-Link-Data-Rate 50666-BPS 31 VALUE Final-Rx-Link-Data-Rate 52K-BPS 32 VALUE Final-Rx-Link-Data-Rate 53333-BPS 33 VALUE Final-Rx-Link-Data-Rate 54666-BPS 34 VALUE Final-Rx-Link-Data-Rate 56K-BPS 35 VALUE Final-Rx-Link-Data-Rate 57333-BPS 36 VALUE Final-Rx-Link-Data-Rate 58666-BPS 37 VALUE Final-Rx-Link-Data-Rate 60K-BPS 38 VALUE Final-Rx-Link-Data-Rate 61333-BPS 39 VALUE Final-Rx-Link-Data-Rate 64K-BPS 40 VALUE Initial-Tx-Link-Data-Rate 110-BPS 1 VALUE Initial-Tx-Link-Data-Rate 300-BPS 2 VALUE Initial-Tx-Link-Data-Rate 600-BPS 3 VALUE Initial-Tx-Link-Data-Rate 1200-BPS 4 VALUE Initial-Tx-Link-Data-Rate 2400-BPS 5 VALUE Initial-Tx-Link-Data-Rate 4800-BPS 6 VALUE Initial-Tx-Link-Data-Rate 7200-BPS 7 VALUE Initial-Tx-Link-Data-Rate 9600-BPS 8 VALUE Initial-Tx-Link-Data-Rate 12K-BPS 9 VALUE Initial-Tx-Link-Data-Rate 14.4K-BPS 10 VALUE Initial-Tx-Link-Data-Rate 16.8-BPS 11 VALUE Initial-Tx-Link-Data-Rate 19.2K-BPS 12 VALUE Initial-Tx-Link-Data-Rate 38.4K-BPS 13 VALUE Initial-Tx-Link-Data-Rate 75-BPS 14 VALUE Initial-Tx-Link-Data-Rate 450-BPS 15 VALUE Initial-Tx-Link-Data-Rate UNKNOWN-BPS 16 VALUE Initial-Tx-Link-Data-Rate 57.6K-BPS 17 VALUE Initial-Tx-Link-Data-Rate 21.6K-BPS 18 VALUE Initial-Tx-Link-Data-Rate 24K-BPS 19 VALUE Initial-Tx-Link-Data-Rate 26K-BPS 20 VALUE Initial-Tx-Link-Data-Rate 28K-BPS 21 VALUE Initial-Tx-Link-Data-Rate 115K-BPS 22 VALUE Initial-Tx-Link-Data-Rate 31K-BPS 23 VALUE Initial-Tx-Link-Data-Rate 33K-BPS 24 VALUE Initial-Tx-Link-Data-Rate 32K-BPS 25 VALUE Initial-Tx-Link-Data-Rate 36K-BPS 26 VALUE Initial-Tx-Link-Data-Rate 40K-BPS 27 VALUE Initial-Tx-Link-Data-Rate 44K-BPS 28 VALUE Initial-Tx-Link-Data-Rate 48K-BPS 29 VALUE Initial-Tx-Link-Data-Rate 49333-BPS 30 VALUE Initial-Tx-Link-Data-Rate 50666-BPS 31 VALUE Initial-Tx-Link-Data-Rate 52K-BPS 32 VALUE Initial-Tx-Link-Data-Rate 53333-BPS 33 VALUE Initial-Tx-Link-Data-Rate 54666-BPS 34 VALUE Initial-Tx-Link-Data-Rate 56K-BPS 35 VALUE Initial-Tx-Link-Data-Rate 57333-BPS 36 VALUE Initial-Tx-Link-Data-Rate 58666-BPS 37 VALUE Initial-Tx-Link-Data-Rate 60K-BPS 38 VALUE Initial-Tx-Link-Data-Rate 61333-BPS 39 VALUE Initial-Tx-Link-Data-Rate 64K-BPS 40 VALUE Final-Tx-Link-Data-Rate 110-BPS 1 VALUE Final-Tx-Link-Data-Rate 300-BPS 2 VALUE Final-Tx-Link-Data-Rate 600-BPS 3 VALUE Final-Tx-Link-Data-Rate 1200-BPS 4 VALUE Final-Tx-Link-Data-Rate 2400-BPS 5 VALUE Final-Tx-Link-Data-Rate 4800-BPS 6 VALUE Final-Tx-Link-Data-Rate 7200-BPS 7 VALUE Final-Tx-Link-Data-Rate 9600-BPS 8 VALUE Final-Tx-Link-Data-Rate 12K-BPS 9 VALUE Final-Tx-Link-Data-Rate 14.4K-BPS 10 VALUE Final-Tx-Link-Data-Rate 16.8-BPS 11 VALUE Final-Tx-Link-Data-Rate 19.2K-BPS 12 VALUE Final-Tx-Link-Data-Rate 38.4K-BPS 13 VALUE Final-Tx-Link-Data-Rate 75-BPS 14 VALUE Final-Tx-Link-Data-Rate 450-BPS 15 VALUE Final-Tx-Link-Data-Rate UNKNOWN-BPS 16 VALUE Final-Tx-Link-Data-Rate 57.6K-BPS 17 VALUE Final-Tx-Link-Data-Rate 21.6K-BPS 18 VALUE Final-Tx-Link-Data-Rate 24K-BPS 19 VALUE Final-Tx-Link-Data-Rate 26K-BPS 20 VALUE Final-Tx-Link-Data-Rate 28K-BPS 21 VALUE Final-Tx-Link-Data-Rate 115K-BPS 22 VALUE Final-Tx-Link-Data-Rate 31K-BPS 23 VALUE Final-Tx-Link-Data-Rate 33K-BPS 24 VALUE Final-Tx-Link-Data-Rate 32K-BPS 25 VALUE Final-Tx-Link-Data-Rate 36K-BPS 26 VALUE Final-Tx-Link-Data-Rate 40K-BPS 27 VALUE Final-Tx-Link-Data-Rate 44K-BPS 28 VALUE Final-Tx-Link-Data-Rate 48K-BPS 29 VALUE Final-Tx-Link-Data-Rate 49333-BPS 30 VALUE Final-Tx-Link-Data-Rate 50666-BPS 31 VALUE Final-Tx-Link-Data-Rate 52K-BPS 32 VALUE Final-Tx-Link-Data-Rate 53333-BPS 33 VALUE Final-Tx-Link-Data-Rate 54666-BPS 34 VALUE Final-Tx-Link-Data-Rate 56K-BPS 35 VALUE Final-Tx-Link-Data-Rate 57333-BPS 36 VALUE Final-Tx-Link-Data-Rate 58666-BPS 37 VALUE Final-Tx-Link-Data-Rate 60K-BPS 38 VALUE Final-Tx-Link-Data-Rate 61333-BPS 39 VALUE Final-Tx-Link-Data-Rate 64K-BPS 40 # VALUE Sync-Async-Mode Asynchronous 1 VALUE Sync-Async-Mode Synchronous 2 VALUE Originate-Answer-Mode Originate_in_Originate_Mode 1 VALUE Originate-Answer-Mode Originate_in_Answer_Mode 2 VALUE Originate-Answer-Mode Answer_in_Originate_Mode 3 VALUE Originate-Answer-Mode Answer_in_Answer_Mode 4 VALUE Modulation-Type usRoboticsHST 1 VALUE Modulation-Type ccittV32 2 VALUE Modulation-Type ccittV22bis 3 VALUE Modulation-Type bell103 4 VALUE Modulation-Type ccittV21 5 VALUE Modulation-Type bell212 6 VALUE Modulation-Type ccittV32bis 7 VALUE Modulation-Type ccittV23 8 VALUE Modulation-Type negotiationFailed 9 VALUE Modulation-Type bell208b 10 VALUE Modulation-Type v21FaxClass1 11 VALUE Modulation-Type v27FaxClass1 12 VALUE Modulation-Type v29FaxClass1 13 VALUE Modulation-Type v17FaxClass1 14 VALUE Modulation-Type v21FaxClass2 15 VALUE Modulation-Type v27FaxClass2 16 VALUE Modulation-Type v29FaxClass2 17 VALUE Modulation-Type v17FaxClass2 18 VALUE Modulation-Type v32Terbo 19 VALUE Modulation-Type v34 20 VALUE Modulation-Type vFC 21 VALUE Modulation-Type v34plus 22 VALUE Connect-Term-Reason dtrDrop 1 VALUE Connect-Term-Reason escapeSequence 2 VALUE Connect-Term-Reason athCommand 3 VALUE Connect-Term-Reason carrierLoss 4 VALUE Connect-Term-Reason inactivityTimout 5 VALUE Connect-Term-Reason mnpIncompatible 6 VALUE Connect-Term-Reason undefined 7 VALUE Connect-Term-Reason remotePassword 8 VALUE Connect-Term-Reason linkPassword 9 VALUE Connect-Term-Reason retransmitLimit 10 VALUE Connect-Term-Reason linkDisconnectMsgReceived 11 VALUE Connect-Term-Reason noLoopCurrent 12 VALUE Connect-Term-Reason invalidSpeed 13 VALUE Connect-Term-Reason unableToRetrain 14 VALUE Connect-Term-Reason managementCommand 15 VALUE Connect-Term-Reason noDialTone 16 VALUE Connect-Term-Reason keyAbort 17 VALUE Connect-Term-Reason lineBusy 18 VALUE Connect-Term-Reason noAnswer 19 VALUE Connect-Term-Reason voice 20 VALUE Connect-Term-Reason noAnswerTone 21 VALUE Connect-Term-Reason noCarrier 22 VALUE Connect-Term-Reason undetermined 23 VALUE Connect-Term-Reason v42SabmeTimeout 24 VALUE Connect-Term-Reason v42BreakTimeout 25 VALUE Connect-Term-Reason v42DisconnectCmd 26 VALUE Connect-Term-Reason v42IdExchangeFail 27 VALUE Connect-Term-Reason v42BadSetup 28 VALUE Connect-Term-Reason v42InvalidCodeWord 29 VALUE Connect-Term-Reason v42StringToLong 30 VALUE Connect-Term-Reason v42InvalidCommand 31 VALUE Connect-Term-Reason none 32 VALUE Connect-Term-Reason v32Cleardown 33 VALUE Connect-Term-Reason dialSecurity 34 VALUE Connect-Term-Reason remoteAccessDenied 35 VALUE Connect-Term-Reason loopLoss 36 VALUE Connect-Term-Reason ds0Teardown 37 VALUE Connect-Term-Reason promptNotEnabled 38 VALUE Connect-Term-Reason noPromptingInSync 39 VALUE Connect-Term-Reason nonArqMode 40 VALUE Connect-Term-Reason modeIncompatible 41 VALUE Connect-Term-Reason noPromptInNonARQ 42 VALUE Connect-Term-Reason dialBackLink 43 VALUE Connect-Term-Reason linkAbort 44 VALUE Connect-Term-Reason autopassFailed 45 VALUE Connect-Term-Reason pbGenericError 46 VALUE Connect-Term-Reason pbLinkErrTxPreAck 47 VALUE Connect-Term-Reason pbLinkErrTxTardyACK 48 VALUE Connect-Term-Reason pbTransmitBusTimeout 49 VALUE Connect-Term-Reason pbReceiveBusTimeout 50 VALUE Connect-Term-Reason pbLinkErrTxTAL 51 VALUE Connect-Term-Reason pbLinkErrRxTAL 52 VALUE Connect-Term-Reason pbTransmitMasterTimeout 53 VALUE Connect-Term-Reason pbClockMissing 54 VALUE Connect-Term-Reason pbReceivedLsWhileLinkUp 55 VALUE Connect-Term-Reason pbOutOfSequenceFrame 56 VALUE Connect-Term-Reason pbBadFrame 57 VALUE Connect-Term-Reason pbAckWaitTimeout 58 VALUE Connect-Term-Reason pbReceivedAckSeqErr 59 VALUE Connect-Term-Reason pbReceiveOvrflwRNRFail 60 VALUE Connect-Term-Reason pbReceiveMsgBufOvrflw 61 VALUE Connect-Term-Reason rcvdGatewayDiscCmd 62 VALUE Connect-Term-Reason tokenPassingTimeout 63 VALUE Connect-Term-Reason dspInterruptTimeout 64 VALUE Connect-Term-Reason mnpProtocolViolation 65 VALUE Connect-Term-Reason class2FaxHangupCmd 66 VALUE Connect-Term-Reason hstSpeedSwitchTimeout 67 VALUE Failure-to-Connect-Reason dtrDrop 1 VALUE Failure-to-Connect-Reason escapeSequence 2 VALUE Failure-to-Connect-Reason athCommand 3 VALUE Failure-to-Connect-Reason carrierLoss 4 VALUE Failure-to-Connect-Reason inactivityTimout 5 VALUE Failure-to-Connect-Reason mnpIncompatible 6 VALUE Failure-to-Connect-Reason undefined 7 VALUE Failure-to-Connect-Reason remotePassword 8 VALUE Failure-to-Connect-Reason linkPassword 9 VALUE Failure-to-Connect-Reason retransmitLimit 10 VALUE Failure-to-Connect-Reason linkDisconnectMsgRec 11 VALUE Failure-to-Connect-Reason noLoopCurrent 12 VALUE Failure-to-Connect-Reason invalidSpeed 13 VALUE Failure-to-Connect-Reason unableToRetrain 14 VALUE Failure-to-Connect-Reason managementCommand 15 VALUE Failure-to-Connect-Reason noDialTone 16 VALUE Failure-to-Connect-Reason keyAbort 17 VALUE Failure-to-Connect-Reason lineBusy 18 VALUE Failure-to-Connect-Reason noAnswer 19 VALUE Failure-to-Connect-Reason voice 20 VALUE Failure-to-Connect-Reason noAnswerTone 21 VALUE Failure-to-Connect-Reason noCarrier 22 VALUE Failure-to-Connect-Reason undetermined 23 VALUE Failure-to-Connect-Reason v42SabmeTimeout 24 VALUE Failure-to-Connect-Reason v42BreakTimeout 25 VALUE Failure-to-Connect-Reason v42DisconnectCmd 26 VALUE Failure-to-Connect-Reason v42IdExchangeFail 27 VALUE Failure-to-Connect-Reason v42BadSetup 28 VALUE Failure-to-Connect-Reason v42InvalidCodeWord 29 VALUE Failure-to-Connect-Reason v42StringToLong 30 VALUE Failure-to-Connect-Reason v42InvalidCommand 31 VALUE Failure-to-Connect-Reason none 32 VALUE Failure-to-Connect-Reason v32Cleardown 33 VALUE Failure-to-Connect-Reason dialSecurity 34 VALUE Failure-to-Connect-Reason remoteAccessDenied 35 VALUE Failure-to-Connect-Reason loopLoss 36 VALUE Failure-to-Connect-Reason ds0Teardown 37 VALUE Failure-to-Connect-Reason promptNotEnabled 38 VALUE Failure-to-Connect-Reason noPromptingInSync 39 VALUE Failure-to-Connect-Reason nonArqMode 40 VALUE Failure-to-Connect-Reason modeIncompatible 41 VALUE Failure-to-Connect-Reason noPromptInNonARQ 42 VALUE Failure-to-Connect-Reason dialBackLink 43 VALUE Failure-to-Connect-Reason linkAbort 44 VALUE Failure-to-Connect-Reason autopassFailed 45 VALUE Failure-to-Connect-Reason pbGenericError 46 VALUE Failure-to-Connect-Reason pbLinkErrTxPreAck 47 VALUE Failure-to-Connect-Reason pbLinkErrTxTardyACK 48 VALUE Failure-to-Connect-Reason pbTransmitBusTimeout 49 VALUE Failure-to-Connect-Reason pbReceiveBusTimeout 50 VALUE Failure-to-Connect-Reason pbLinkErrTxTAL 51 VALUE Failure-to-Connect-Reason pbLinkErrRxTAL 52 VALUE Failure-to-Connect-Reason pbTransmitMasterTimeout 53 VALUE Failure-to-Connect-Reason pbClockMissing 54 VALUE Failure-to-Connect-Reason pbReceivedLsWhileLinkUp 55 VALUE Failure-to-Connect-Reason pbOutOfSequenceFrame 56 VALUE Failure-to-Connect-Reason pbBadFrame 57 VALUE Failure-to-Connect-Reason pbAckWaitTimeout 58 VALUE Failure-to-Connect-Reason pbReceivedAckSeqErr 59 VALUE Failure-to-Connect-Reason pbReceiveOvrflwRNRFail 60 VALUE Failure-to-Connect-Reason pbReceiveMsgBufOvrflw 61 VALUE Failure-to-Connect-Reason rcvdGatewayDiscCmd 62 VALUE Failure-to-Connect-Reason tokenPassingTimeout 63 VALUE Failure-to-Connect-Reason dspInterruptTimeout 64 VALUE Failure-to-Connect-Reason mnpProtocolViolation 65 VALUE Failure-to-Connect-Reason class2FaxHangupCmd 66 VALUE Failure-to-Connect-Reason hstSpeedSwitchTimeout 67 VALUE Simplified-MNP-Levels none 1 VALUE Simplified-MNP-Levels mnpLevel3 2 VALUE Simplified-MNP-Levels mnpLevel4 3 VALUE Simplified-MNP-Levels ccittV42 4 VALUE Simplified-MNP-Levels usRoboticsHST 5 VALUE Simplified-MNP-Levels synchronousNone 6 VALUE Simplified-MNP-Levels mnpLevel2 7 VALUE Simplified-MNP-Levels mnp10 8 VALUE Simplified-MNP-Levels v42Etc 9 VALUE Simplified-V42bis-Usage none 1 VALUE Simplified-V42bis-Usage ccittV42bis 2 VALUE Simplified-V42bis-Usage mnpLevel5 3 VALUE Equalization-Type Long 1 VALUE Equalization-Type Short 2 VALUE Fallback-Enabled Disabled 1 VALUE Fallback-Enabled Enabled 2 VALUE Back-Channel-Data-Rate 450BPS 1 VALUE Back-Channel-Data-Rate 300BPS 2 VALUE Back-Channel-Data-Rate None 3 VALUE Device-Connected-To None 1 VALUE Device-Connected-To isdnGateway 2 VALUE Device-Connected-To quadModem 3 VALUE Call-Event-Code notSupported 1 VALUE Call-Event-Code setup 2 VALUE Call-Event-Code usrSetup 3 VALUE Call-Event-Code telcoDisconnect 4 VALUE Call-Event-Code usrDisconnect 5 VALUE Call-Event-Code noFreeModem 6 VALUE Call-Event-Code modemsNotAllowed 7 VALUE Call-Event-Code modemsRejectCall 8 VALUE Call-Event-Code modemSetupTimeout 9 VALUE Call-Event-Code noFreeIGW 10 VALUE Call-Event-Code igwRejectCall 11 VALUE Call-Event-Code igwSetupTimeout 12 VALUE Call-Event-Code noFreeTdmts 13 VALUE Call-Event-Code bcReject 14 VALUE Call-Event-Code ieReject 15 VALUE Call-Event-Code chidReject 16 VALUE Call-Event-Code progReject 17 VALUE Call-Event-Code callingPartyReject 18 VALUE Call-Event-Code calledPartyReject 19 VALUE Call-Event-Code blocked 20 VALUE Call-Event-Code analogBlocked 21 VALUE Call-Event-Code digitalBlocked 22 VALUE Call-Event-Code outOfService 23 VALUE Call-Event-Code busy 24 VALUE Call-Event-Code congestion 25 VALUE Call-Event-Code protocolError 26 VALUE Call-Event-Code noFreeBchannel 27 VALUE Call-Event-Code inOutCallCollision 28 Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

On Tue, 10 Jun 1997, Adam Wills (Global 2000) wrote: > On Tue, 10 Jun 1997, Tatai SV Krishnan wrote: > > > > > Its a rfc based Attribute -Refer to RFC 2138 page 19. It talks about > > attribute 26 > > Yea, I understand how it is vendor specific- BUT shouldn't the USR > version(s) of the dictionary file interpret this into something 'useful' > rather than > > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > > For EVERY radius accoutning stop entry that is logged from a USR TC > chasis? I mean, I know its 'vendor specific', but USR chose to use it and > I can't see how they use it from the dictinoary file they provided me > with. > > > NETServer does send this attributes to the Radius, its for the Radius server to either understand and print it or not. What happens here is all USR specific attributes are send in the vendor-specific format, and your livingston radius server does not understand but knows its vendor specific. That is the reason you see anything but an entry of Vendor Specific " " krish

On Tue, 10 Jun 1997, Adam Wills (Global 2000) wrote: > > On Mon, 9 Jun 1997, Brian wrote: > > > > only 2 weeks? I opened a ticket with USR on this about 3 months ago. I > > was given .79, intalled it, it didn't work, so now I run 3.3.28. > > Framed-Route is essential I agree, it should be a priority. > > > > > WOA :) We have a winner.. I thought I had it tought being on hold one > day for over 7 hours, but I am pale in comparison to your 3 months w/o an Well, you got me beat there, the longest time I have ever been on hold was a little over 2 hours...........my lowest hold time use to be 45min, but it seems to have drastically improved lately. > answer :) If It makes you feel better (or worse) the tech on my ticket > SAID he would get back to me (last week) and try to 'borrow' a TC system > from developement to 'test' my setup to my radius server to find the > problem with us. Still no call back, but im sure he will soon. hehe, been there done that. They can use Merit, they can use there own Merit, they can use Livingston........it won't work. In fact, I told them, to show me ANY instance, where the USR TC took the Framed-Route attribute and responded in any way to it, and they couldnt. "That is not supported in our hardware". "It's not?" I said "I thought your hardware conformed to the radius standard. And since your Netserver manual has had Framed-Route listed in every edition published at least since 3.3, with a description of what it does I would expect it to work." Brian > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > > > 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, 10 Jun 1997, Adam Wills (Global 2000) wrote: > > On Mon, 9 Jun 1997, Brian wrote: > > > > only 2 weeks? I opened a ticket with USR on this about 3 months ago. I > > was given .79, intalled it, it didn't work, so now I run 3.3.28. > > Framed-Route is essential I agree, it should be a priority. > > > > > WOA :) We have a winner.. I thought I had it tought being on hold one > day for over 7 hours, but I am pale in comparison to your 3 months w/o an Well, you got me beat there, the longest time I have ever been on hold was a little over 2 hours...........my lowest hold time use to be 45min, but it seems to have drastically improved lately. > answer :) If It makes you feel better (or worse) the tech on my ticket > SAID he would get back to me (last week) and try to 'borrow' a TC system > from developement to 'test' my setup to my radius server to find the > problem with us. Still no call back, but im sure he will soon. hehe, been there done that. They can use Merit, they can use there own Merit, they can use Livingston........it won't work. In fact, I told them, to show me ANY instance, where the USR TC took the Framed-Route attribute and responded in any way to it, and they couldnt. "That is not supported in our hardware". "It's not?" I said "I thought your hardware conformed to the radius standard. And since your Netserver manual has had Framed-Route listed in every edition published at least since 3.3, with a description of what it does I would expect it to work." Brian > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > > > 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, 10 Jun 1997, Jeff Mcadams wrote: > Running the Dual PRI card for our x2 lines here....they're already getting > full (not solely because of x2, long story), the problem I have is that > once the lines get full, our users are either getting an all circuits busy > message, or a fast busy signal. The fast busy signal is *better* as their > modems will still redial on that, but it does still prompt them to call in > to us and ask us what the problem is. > > I see in the PRI configuration that there are the cause codes for when > certain conditions occur (including no B channels available), but they are > all set to 58 I believe, which (apparently) means no circuits available. > > Does anyone know what the various codes that can be used here are? I > didn't see them in any documentation (though I definitely could have missed > it), but I would like a normal busy signal to be returned when all the B > channels are used up. never messed with it, but it sounds like neat stuff. I wonder where all this is documented. Brian > -- > Jeff McAdams | "OK, we have enough youth... > IgLou Internet Services | How about a fountain of smart?" > e-mail: jeffm@iglou.com | - unknown > 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, 10 Jun 1997, Jeff Mcadams wrote: > Running the Dual PRI card for our x2 lines here....they're already getting > full (not solely because of x2, long story), the problem I have is that > once the lines get full, our users are either getting an all circuits busy > message, or a fast busy signal. The fast busy signal is *better* as their > modems will still redial on that, but it does still prompt them to call in > to us and ask us what the problem is. > > I see in the PRI configuration that there are the cause codes for when > certain conditions occur (including no B channels available), but they are > all set to 58 I believe, which (apparently) means no circuits available. > > Does anyone know what the various codes that can be used here are? I > didn't see them in any documentation (though I definitely could have missed > it), but I would like a normal busy signal to be returned when all the B > channels are used up. never messed with it, but it sounds like neat stuff. I wonder where all this is documented. Brian > -- > Jeff McAdams | "OK, we have enough youth... > IgLou Internet Services | How about a fountain of smart?" > e-mail: jeffm@iglou.com | - unknown > 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, 10 Jun 1997, Tatai SV Krishnan wrote: > > Its a rfc based Attribute -Refer to RFC 2138 page 19. It talks about > attribute 26 Yea, I understand how it is vendor specific- BUT shouldn't the USR version(s) of the dictionary file interpret this into something 'useful' rather than Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" For EVERY radius accoutning stop entry that is logged from a USR TC chasis? I mean, I know its 'vendor specific', but USR chose to use it and I can't see how they use it from the dictinoary file they provided me with.

Brian said once upon a time: >USR has LOTS of attributes that go unused unless you use THERE software >for radius. The NMC for example has the ability to log ALOT of cool stuff >like Caller ID etc. One day this will hopefully be incorporated into >Merit. So RADIUS isn't RADIUS if it is USR RADIUS? I'm confused here. If it uses a protocol, why can't another program using the same protocol read the same information. I'd love to get Caller ID, connect rate, and other things logged with my Merit server. I even tried to get the USR accounting server to function, but it didn't do any dictionary translation, so I bagged it.

> > Is? it ONLY comes from my USR's, and its Radius ACcounting Attribute #26: > > ATTRIBUTE Vendor-Specific 26 string Vender-Specific Attribute actually is an encapsulated attribute. The attribute is suppose to return an encapsulated attribute, which would then cross reference in your dictionary file. The problem with this is you have to run a Radius that is either patched or originally supports Vendor-Specific Attributes. I am thinking, that USR is actually hacking up a Merit radius to do this. Actually, they do have a hacked up merit that does this, but it is limited. I have a copy, its an older version, you may be able to get there tech support to mail it to you. Brian > > > Shouldn't they, USr, have some sort of sub-heading that lists the values > and such for their 'Vendor-Specific' codes? I'm a bit annoyed with the 4 > lines of garbage each entry now has, but further I want to know what it IS > tryuing to report. If anyone wants the entire dictionary file that USR > tech support mailed me, let me nkow. It even includes the connection > speed and transmit speeds etc of the conection in the dictionary file (no > that info does NOT appear at all, but i suspect it will in a future > netserver release). > > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > > 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? it ONLY comes from my USR's, and its Radius ACcounting Attribute #26: > > ATTRIBUTE Vendor-Specific 26 string Vender-Specific Attribute actually is an encapsulated attribute. The attribute is suppose to return an encapsulated attribute, which would then cross reference in your dictionary file. The problem with this is you have to run a Radius that is either patched or originally supports Vendor-Specific Attributes. I am thinking, that USR is actually hacking up a Merit radius to do this. Actually, they do have a hacked up merit that does this, but it is limited. I have a copy, its an older version, you may be able to get there tech support to mail it to you. Brian > > > Shouldn't they, USr, have some sort of sub-heading that lists the values > and such for their 'Vendor-Specific' codes? I'm a bit annoyed with the 4 > lines of garbage each entry now has, but further I want to know what it IS > tryuing to report. If anyone wants the entire dictionary file that USR > tech support mailed me, let me nkow. It even includes the connection > speed and transmit speeds etc of the conection in the dictionary file (no > that info does NOT appear at all, but i suspect it will in a future > netserver release). > > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465 > > 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: >Thanks for the suggestion. I do have the Quad Modems set to priTdm. Now >one thing about that card, is it was orignally set for T1 from the >factory, I downloaded PRI 2.5.1 file and reflashed it to make it PRI. > >This isn't a hit or miss thing either. If i reboot the netserver card, >the PRI WILL lose the QuadModems, and I have to go in there and reinstall >them in the PRI card. Any other ideas? Damn, I wish I remember the resolution to this problem, because I had it as well. I think it was something about telling the PRI card where the NMC (yes, the NMC) card is located or vice-versa. The NMC card is responsible for setting up the available modems in the PRI card. There may be something in the console of the PRI card that has this setting. I'm sorry I can be any more helpful than that.

On Tue, 10 Jun 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >Whenever I reboot the netserver card, the PRI card loses its Quad Modem > >assignments, so I have to go into the PRI card and do: > > > >q:2,3,4,5,6,7,8,9,10,11,12,13 > > You have to go into each modem and set the "Line Interface Source" to > "priTdm". I think it defaults to "t1Tdm" which is wrong for PRI. This is > set via TCM under "Line Interface Options". > 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, 10 Jun 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >Whenever I reboot the netserver card, the PRI card loses its Quad Modem > >assignments, so I have to go into the PRI card and do: > > > >q:2,3,4,5,6,7,8,9,10,11,12,13 > > You have to go into each modem and set the "Line Interface Source" to > "priTdm". I think it defaults to "t1Tdm" which is wrong for PRI. This is > set via TCM under "Line Interface Options". > Pete, Thanks for the suggestion. I do have the Quad Modems set to priTdm. Now one thing about that card, is it was orignally set for T1 from the factory, I downloaded PRI 2.5.1 file and reflashed it to make it PRI. This isn't a hit or miss thing either. If i reboot the netserver card, the PRI WILL lose the QuadModems, and I have to go in there and reinstall them in the PRI card. Any other ideas? 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 Tue, 10 Jun 1997, Adam Wills (Global 2000) wrote: > On Tue, 10 Jun 1997, Tatai SV Krishnan wrote: > > > > > Its a rfc based Attribute -Refer to RFC 2138 page 19. It talks about > > attribute 26 > > Yea, I understand how it is vendor specific- BUT shouldn't the USR > version(s) of the dictionary file interpret this into something 'useful' > rather than > > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > Vendor-Specific = "" > > For EVERY radius accoutning stop entry that is logged from a USR TC > chasis? I mean, I know its 'vendor specific', but USR chose to use it and > I can't see how they use it from the dictinoary file they provided me > with. > USR has LOTS of attributes that go unused unless you use THERE software for radius. The NMC for example has the ability to log ALOT of cool stuff like Caller ID etc. One day this will hopefully be incorporated into Merit. 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

David Bolen said once upon a time: > >Jeff Mcadams <jeffm@iglou.com> writes: > >> How about a Dejanews URL. :) > >Hmm - I can't seem to use that URL - DejaNews tells me it's an invalid >document request. Hit reload. I got the same error, then I hit reload and it came up. Go figure. >Is it basically a full set of cause codes? If so, then I won't bother >copying them in from my copy of the Q.931 spec :-) With descriptions.

Pete Ashdown <pashdown@xmission.com> writes: > So based on this list, is "17" a better choice than "58"? Well, 17 will normally result in a regular busy signal, but it's not clear that you really need or want to change the defaults. All of the settings for which you see the default of 58 have to do with special circumstances that aren't necessarily equivalent to a "user busy", and a lack of resource error is probably more appropriate. The hub will in fact generate a cause 17 if it is unable to find a free modem to deliver the call to (as opposed to the call being administratively blocked). Of course, if making these codes something else works better with your particular configuration or telco, that's why they're configurable :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

"Adam Wills (Global 2000)" <sysadmin@global2000.net> writes: > Yea, I understand how it is vendor specific- BUT shouldn't the USR > version(s) of the dictionary file interpret this into something 'useful' > rather than It's not the dictionary file so much that interprets the vendor specific attributes as whatever daemon is parsing the packet and displaying it in your file. You might be having a problem with the latter. The dictionary that you sent to the list does contain the definitions for these attributes, as the four values I believe you are getting are: Chassis-Call-Slot (vendor attribute 0x9019) Chassis-Call-Span ( " 0x901A) Chassis-Call-Channel ( " 0x901B) Unauthenticated-Time ( " 0x901D) which seem properly defined as an "ATTRIB_NMC" in your dictionary. I do think you need a "vendors" file to work with this dictionary for the Merit/USR Server (if you're using the Unix server) in order to identify just which vendor is supposed to be in the packet for "ATTRIB_NMC" vendor specific attributes. There may also be an issue with the encoding of the attribute. Technically the vendor-specific area of the data is encoded however the vendor wants, although the RFC suggests a TLV (type/length/value, with a byte for type/length) encoding. USR doesn't use exactly that encoding, but uses a 2 byte type (so they can use more than 255 attributes) and allows the overall packet length to determine the length of the attribute itself, rather than having an extra length field. (I think that's realistic since the extra length is somewhat redundant unless you want multiple vendor attributes in a single RADIUS vendor-specific attribute). Your server will need to be able to parse that format. You can find a description of the packet format in the RADIUS appendix to the NETServer documentation (at least as of the 3.3 release). My 3.3 documentation has the format in a section entitled "USR Vendor Specific Extensions for 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 \ \-----------------------------------------------------------------------/

On Tue, 10 Jun 1997, David Bolen wrote: > Hmm - I can't seem to use that URL - DejaNews tells me it's an invalid > document request. Make sure you cut and paste both lines of the URL. > Is it basically a full set of cause codes? If so, then I won't bother > copying them in from my copy of the Q.931 spec :-) Yes, it is a full listing of cause codes with descriptions. Brian

Brian <signal@shreve.net> writes: > USR has LOTS of attributes that go unused unless you use THERE software > for radius. Or any software that can parse vendor specific attributes. It doesn't necessarily have to be USRs. :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Jeff Mcadams <jeffm@iglou.com> writes: > How about a Dejanews URL. :) Hmm - I can't seem to use that URL - DejaNews tells me it's an invalid document request. Is it basically a full set of cause codes? If so, then I won't bother copying them in from my copy of the Q.931 spec :-) -- David PS: For a really short set of common codes, try going to the debugging screen (Ctrl-D) and checking the "Set Chassis Busy Cause" option... /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Jeff Mcadams <jeffm@iglou.com> writes: > Does anyone know what the various codes that can be used here are? I > didn't see them in any documentation (though I definitely could have missed > it), but I would like a normal busy signal to be returned when all the B > channels are used up. As far as I know, the TC gear won't have any control over what is returned to the user when all the B channels are used up, because at that point the telco switch knows that all of the channels are occupied and the call never even gets handed to the TC rack. What you have control over is what cause code the PRI card might return to the telco if the telco decides to send a call down what it believes is an idle B channel but the PRI card for one reason or another either doesn't want to or can't service the call. But when all of your input B channels fill, the PRI card is pretty much out of the game. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

In a previous note, I wrote: > The hub will in fact generate a cause 17 if it is unable to find a > free modem to deliver the call to (as opposed to the call being > administratively blocked). Whoops, should have waited for some more coffee... I think this previous comment of mine is inaccurate, since such a circumstance should be handled by the "No Modem Available" configuration. So I suppose setting that and/or the "No Gateway Available" setting to 17 might be reasonable, although from a purists point of view the problem really is a resource problem and not a user busy. My understanding of user busy is that it is a cause code which is specifically designed to indicate that a busy signal should be communicated to the caller, thus effectively terminating the call. In theory, a resource unavailable (or bearer capability not available) result code of 58 should allow the telco switch to attempt to deliver the call on other available resources (such as other spans). However, in practice, I've found few of my configurations where returning the resource cause actually gets a call routed to other equipment, rather than returning a reorder tone to the user - which is unfortunate, IMHO. -- 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: > So RADIUS isn't RADIUS if it is USR RADIUS? I'm confused here. If it uses > a protocol, why can't another program using the same protocol read the same > information. There's nothing stopping another program from reading the information, but you have to understand that the RADIUS protocol has an "out" for vendor specific additions (not to mention reserved slots in the attribute space for experimental attributes), so the "other program" has to be able to process information specific to a given vendor if you want to support it. Within this vendor specific "out", a vendor is free to implement custom functionality for specific gear. Any other gear not by that vendor will cleanly ignore such information (as per the RADIUS protocol), whereas gear from the vendor can perform the requested functions. And while the overall RADIUS protocol and attributes are well formed, the vendor-specific attribute is available for vendors to construct as they please, in order to accomplish the goal of the functionality. While it would be nice if every vendor just supported a well defined set of standard attributes, that's not very practical in a world of feature additions for a competitive advantage and a race to implement features before they are officially standardized, so without this release from the standard attributes, RADIUS would have been much harder to gain general acceptance. > I'd love to get Caller ID, connect rate, and other things logged with my > Merit server. In theory it shouldn't be too hard, but it probably would require adding some code to fully parse out the payload of the vendor-specific attributes. I've lost track of the Merit code over the last year or so but I had thought such functionality may have been added, however a glance at the web site indicates that support for a multi-vendor dictionary will be available in the next release of the Basic Merit AAA server. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

On Tue, 10 Jun 1997, Pete Ashdown wrote: > Brian said once upon a time: > > >USR has LOTS of attributes that go unused unless you use THERE software > >for radius. The NMC for example has the ability to log ALOT of cool stuff > >like Caller ID etc. One day this will hopefully be incorporated into > >Merit. > > So RADIUS isn't RADIUS if it is USR RADIUS? I'm confused here. If it uses > a protocol, why can't another program using the same protocol read the same > information. > > I'd love to get Caller ID, connect rate, and other things logged with my > Merit server. I even tried to get the USR accounting server to function, > but it didn't do any dictionary translation, so I bagged it. > You can get Called ID with any radius code, as long you have the attributes ATTRIBUTE Called-Station-Id 30 string ATTRIBUTE Calling-Station-Id 31 string This will tell you the Caller id stuff. You can modify the radius code to get the other stuff, for connect message as of today these attributes are supported only on the NMC. krish

Hi all, Is it possible to make a multiple modem connection from a usr to a livingston pm? I can get the livingston to dial my USR-TC on 2 modems and it connects fine but I only get the throughput of 1 modem the 2nd modem is rarely used? does the USR-TC do Line Balancing or EQL??? Thanks Elio Fuentes emf@agetech.net

Once upon a time Brian shaped the electrons to say... >for radius. The NMC for example has the ability to log ALOT of cool stuff >like Caller ID etc. One day this will hopefully be incorporated into Caller ID has standard RFC attributes: Called-Station-Id Calling-Station-Id -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

Once upon a time Pete Ashdown shaped the electrons to say... >I'd love to get Caller ID, connect rate, and other things logged with my >Merit server. I even tried to get the USR accounting server to function, So get USR to support: Called-Station-Id - attrib 30 Calling-Station-Id - attrib 31 both from RFC 2138 <URL:ftp://ftp.livingston.com/pub/radius/rfc2138.txt>, and Connect-Info - attrib 65 from the RADIUS Extensions Draft. <URL:ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-ext-00.txt> -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

Hi, I have recently installed 4 quad v.34+ modem cards to our usr chassiss. But TCM lite doesn't talk to them nicely. It produced error 'Data not available' everytime I try to query the modems using TCM lite. On the same chassiss are another 4 quad v.34 (not v.34+)modems, which have no problem with the software. Could it be that TCM lite is not compatible with v.34+ modems? TCM lite version in use is 4.2.2. Bye __________________________________________________________________ ****************************************************************** Ismail Faiz Phone:(960) 311412 DhivehiNet System Administrator Mailto:faiz@dhiraagu.com.mv Dhiraagu Pvt Ltd, P.O. Box: 2082 Male', Republic of Maldives http://pages.dhivehinet.net.mv

Same happened to me, Dejanews said it was an invalid URL, bt after examining the location box I found that Eudora had copied only the first part of the URL to Netscape, so I manually copied it to Netscape and it was fine. At 18:06 10-06-97 EDT, you wrote: >Jeff Mcadams <jeffm@iglou.com> writes: > >> How about a Dejanews URL. :) > >Hmm - I can't seem to use that URL - DejaNews tells me it's an invalid >document request. > >Is it basically a full set of cause codes? If so, then I won't bother >copying them in from my copy of the Q.931 spec :-) > >-- David > >PS: For a really short set of common codes, try going to the debugging >screen (Ctrl-D) and checking the "Set Chassis Busy Cause" option... > > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications \ Phone: (914) 789-5327 | > / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ >\-----------------------------------------------------------------------/ > > __________________________________________________________________ ****************************************************************** Ismail Faiz Phone:(960) 311412 DhivehiNet System Administrator Mailto:faiz@dhiraagu.com.mv Dhiraagu Pvt Ltd, P.O. Box: 2082 Male', Republic of Maldives http://pages.dhivehinet.net.mv

There is a new feature of ANI / Caller ID authenication in the New Release TC Security & Accounting Server 4.3, but seems it doesn't work as we have tried. Anybody who has tried it out? Any other method beside that for Caller ID Authenication? Pls advise. Rgds, Francis Fong / Synergy On Tue, 10 Jun 1997, Tatai SV Krishnan wrote: > > > > On Tue, 10 Jun 1997, Pete Ashdown wrote: > > > Brian said once upon a time: > > > > >USR has LOTS of attributes that go unused unless you use THERE software > > >for radius. The NMC for example has the ability to log ALOT of cool stuff > > >like Caller ID etc. One day this will hopefully be incorporated into > > >Merit. > > > > So RADIUS isn't RADIUS if it is USR RADIUS? I'm confused here. If it uses > > a protocol, why can't another program using the same protocol read the same > > information. > > > > I'd love to get Caller ID, connect rate, and other things logged with my > > Merit server. I even tried to get the USR accounting server to function, > > but it didn't do any dictionary translation, so I bagged it. > > > > You can get Called ID with any radius code, as long you have the > attributes > > ATTRIBUTE Called-Station-Id 30 string > ATTRIBUTE Calling-Station-Id 31 string > > > This will tell you the Caller id stuff. You can modify the radius code > to get the other stuff, for connect message as of today these attributes > are supported only on the NMC. > > > krish > >

At 10:46 PM 6/9/97 -0400, Adam Wills (Global 2000) wrote: ...<snip> >Just out of curiousity, what radius demon are you running? USR tried to >blame the strictly RFC radius complaint Livingston Radius server 1.16 that >we run, but quickly realized "oh yea, our netserver code is broke, sorry >for pointing you in the wrong direction for the first 2 days", but I will >believe just about anything some times :) I'm sorry, but the Livingston RADIUS Server V1.16 is NOT strictly RFC compliant. It was authored before the final draft of the RFC, (which is still open to small changes). In particular, the base source, it does not authenticate Accounting packets and therefore doesn't generate proper Accounting response authenticators. There is an easy patch for that. It also has a bunch of other quirks, which I won't go into, because they don't affect most normal operations. But it certainly cannot parse VSAs. That implementation can only display fields of the four dictionary types. Anything else like Ascend's ABINARY, or compound fields can not be externally represented. Other vendors have provided servers with the necessary functions to meet or exceed their requirements which often go beyond Livingston's original implementation, which just passed it's two year old anniversary. Dave. David Mitton 508-670-8888 Main Consulting Engineer 508-916-4570 Direct Bay Networks, Internet/Telcom BG 508-916-4789 FAX Billerica, MA 01821 dmitton@baynetworks.com

Once upon a time Adam Wills shaped the electrons to say... >(multiple login protection for one). I wonder if radius 2.0x from >livingston handles the Vendor Specific accounting records. If so I guess Nope. We don't use VSAs at all on our products. Since it is an optional feature for vendors who can't, or won't, use the standard attributes we never implemented it in our server. We probably will eventually just because, but since we have no need for it we haven't done it to date. -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

On Wed, 11 Jun 1997, Dave Mitton wrote: > > I'm sorry, but the Livingston RADIUS Server V1.16 is NOT strictly RFC > compliant. > It was authored before the final draft of the RFC, (which is still open to > small changes). > > Other vendors have provided servers with the necessary functions to meet > or exceed their requirements which often go beyond Livingston's original > implementation, which just passed it's two year old anniversary. > Interesting, but some how it doesn't suprise me after all I have been reading on this list lately. Problem is I re-wrote the original radius 1.16 livingston source severly to handle some custom stuff we have here (multiple login protection for one). I wonder if radius 2.0x from livingston handles the Vendor Specific accounting records. If so I guess I could try to make the patches over to that one. For the others on this list that can't get framed-routes working, what radius versions are you using? ANd lastly, those that DO have framed-routes working via radius, what version do you run (netserver and radius code). Thanks! Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

I have a USR DWAN hub with a PRI NAC. I'm going to be flashing it with the channelized T1 code. Does anyone have any experience with using channelized T1 that has AMI/D4 framing vs B8ZS/ESF framing? I specifically want to know if the type of framing will affect X2 and V34 connect speeds. The lines are trunk side. USR tech support says it shouldn't matter, but I'd like some real world answers if possible. I already asked this on the inet-access list, but didn't any answers other than someone insisting that AMI/D4 lines are not trunk side. Brian

Adam Wills said once upon a time: >First, to get it working you MUST use netserver code 3.4.79 (beta right >now). 2.5.1's release (maybe next week) should have 3.4.79 or newer so >that will do the trick. I hear 'older' netserver codes (3.3.x) works too >if you like going back in time. It works for 3.3.28, but only with class C sized subnets.

Everyone that I've talked to that has x2 running tells me that they're seeing <=31200 connects for regular modems and generally in the 40's for x2 connects with trunk side lines. USW is supposed to put in our trunk side lines this week, my rep finally seems to know what the difference is between line and trunk side. We have line side now and cannot connect x2 at all. The best that I'm seeing now are 28.8 and we've been screwing with the settings for months with both USW and USR. At 10:47 AM 6/11/97 -0500, you wrote: >I have a USR DWAN hub with a PRI NAC. I'm going to be flashing it with >the channelized T1 code. > >Does anyone have any experience with using channelized T1 that has AMI/D4 >framing vs B8ZS/ESF framing? > >I specifically want to know if the type of framing will affect X2 and V34 >connect speeds. The lines are trunk side. USR tech support says it >shouldn't matter, but I'd like some real world answers if possible. > >I already asked this on the inet-access list, but didn't any answers other >than someone insisting that AMI/D4 lines are not trunk side. > >Brian > > > 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

To the few of you that posted to me privately about similar problems with framed routes, I finally have things working (with the help of USR). First, to get it working you MUST use netserver code 3.4.79 (beta right now). 2.5.1's release (maybe next week) should have 3.4.79 or newer so that will do the trick. I hear 'older' netserver codes (3.3.x) works too if you like going back in time. Second, the radius entry that looks like this: testroute Password = "usrtest" User-Service-Type = Framed-User, Framed-Address = 205.247.146.111, Framed-Protocol = SLIP, Framed-MTU = 1006, Framed-Route = "205.247.159.64/28 205.247.146.111 1" Port-Limit = 0, Framed-Compression = Van-Jacobsen-TCP-IP Now, the problems the USR tech found with me were any or all of the following (note we did this all at once, so its hard to tell which 'one' might of fixed it). A) deleted any and all netmasks in your table. Your really don't need them anyway with RIP v2. - "show table netmask" - "del netmaks 205.247.146.0" B) do a save all, and reboot (prevents any broadcasts of the routes in question, we noticed the netserver broadcasting a /24 even after deleting it from the route and netmask tables for the 205.247.146.0 class-c). If you don't already, set - "set routing broadcast" - "ret ripv2 on" C) After reboot, login to the TC rack and do a "show route". Make SURE there is no "/24" (a full class-c, 255.255.255.0 netmask) in the route table for the framed-address or framed route subnet you are trying to pass through. In other words, your "show route" SHOULD not show the routes in use before you try to login- because the Netserver will reject the framed route if it has a netmask OTHER than the netmask already in the "show route" table of the netserver. -> In our case, one of our cisco routers has an ip address of 205.247.146.1 (secondary address on ethernet). I disabled that, (it was not in use any more since we moved things aroung a long time ago but I left the ip on the cisco for no good reason). Before, that made that cisco broadcast a 205.247.146.0/24 to the TC1, so the TC1 wouldn't accept 205.247.146/32 entries to login to it. Now the cisco doesnt broadcast anything in that class-c except what it 'hears' from our other TC's and terminal servers. Ok, after all this, it finally works :) Kodos to the USR tech that spent the time (his name is Krishnan) on this, and if anyone else having this problem reads the above this MIGHT help you solve the problem. I really do not know which item above actually fixed it, but it sounds like the simple fact of setting the TC to not have the netmasks already in its netmask table (statically, which is what we do with our livingston's so it seemed natural to do iti here too) and then to broadcast only (not listen) is really the key- the rest of the items were all done together. I dunno why 'Usr level 1 tech support' is stating "we do not support framed-routes" when you first call them on this problem, but they definately DO support framed-routes. Oh, your millage may vary, in case you thought I needed a disclaimer here. Now, if we had OSPF to begin with, this never would have happened, but I hear its coming in the following months- so 'yipee!'. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

B8ZS/ESF or AMI/D4 won't make a difference to PCM modems. If a real-world test shows otherwise, then there's some other difference in the test -- it's not the B8ZS itself. -- Ed Schulz edschulz@lucent.com

Tatai SV Krishnan said once upon a time: >You can get Called ID with any radius code, as long you have the >attributes > >ATTRIBUTE Called-Station-Id 30 string >ATTRIBUTE Calling-Station-Id 31 string > > >This will tell you the Caller id stuff. You can modify the radius code >to get the other stuff, for connect message as of today these attributes >are supported only on the NMC. As of 3.3.28, only ISDN connections report the Calling-Station-Id. How do I get my analog connections to do the same?

One of my customers was complaing about lag through the TC when playing quake. Read through the backlog in the mail archive, didn't see anything really useful. Turned off compression and ED&C on the modem, and now the customer reports all is well. So he turned it off in his modem, and he be happy camer. Don't know if this helps.

--IMA.Boundary.364650668 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Description: cc:Mail note part On 6-10-97 @ 10:50pm, MegaZone <megazone@livingston.com> wrote: >Once upon a time Pete Ashdown shaped the electrons to say... >>I'd love to get Caller ID, connect rate, and other things logged with my >>Merit server. I even tried to get the USR accounting server to >>function, > >So get USR to support: > >Called-Station-Id - attrib 30 >Calling-Station-Id - attrib 31 > >both from RFC 2138 <URL:ftp://ftp.livingston.com/pub/radius/rfc2138.txt>, and > >Connect-Info - attrib 65 > >from the RADIUS Extensions Draft. ><URL:ftp://ftp.livingston.com/pub/radius/draft-ietf-radius-ext-00.txt> > >-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 > USR already supports attributes #30 an #31; they are optional attributes sent in the Auth-Request when provided by the switch. There is a bug in some versions of NETServer code where we do not forward the ANI/DNIS information in the Auth-Request, which was fixed in v3.4.86 and in v3.5(BETA). If you have v3.4.2x code, you should contact tech support for the download location of v3.4.86 to resolve this issue. Kurtiss ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~ __ __ ~ ~ Kurtiss Johnson | | | | RRRRR ~ ~ Product Manager | | | | ***RR RR ~ ~ US Robotics | \_/ |*** RRRRR ~ ~ kjohnson@usr.com \___/ RR RR ~ ~ See us at www.usr.com! ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --IMA.Boundary.364650668 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 39E4C670; Wed, 11 Jun 97 01:57:43 -0500 Received: from mail.xmission.com by usr.com (8.7.5/3.1.090690-US Robotics) id BAA20973; Wed, 11 Jun 1997 01:36:06 -0500 (CDT) Received: from domo by mail.xmission.com with local (Exim 1.62 #2) id 0wbgK2-0007Tg-00; Tue, 10 Jun 1997 23:51:54 -0600 Received: from bast.livingston.com [149.198.247.2] by mail.xmission.com with smtp (Exim 1.62 #2) id 0wbgJz-0007PJ-00; Tue, 10 Jun 1997 23:51:51 -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 WAA25836 for <usr-tc@mail.xmission.com>; Tue, 10 Jun 1997 22:50:02 -0700 (PDT) Received: (from megazone@localhost) by server.livingston.com (8.8.5/8.6.9) id WAA00800 for usr-tc@mail.xmission.com; Tue, 10 Jun 1997 22:50:00 -0700 (PDT) Message-Id: <199706110550.WAA00800@server.livingston.com> In-Reply-To: <199706102239.QAA08490@slack.xmission.com> from "Pete Ashdown" at Jun 10, 97 04:39:12 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.364650668--

Yes, it just doesn't look like that when I type it... :) Specifically, my brain was doing "Error Detection and Correction"... On Wed, 11 Jun 1997, Donald Maner wrote: > ED&C? Is that v.42 error correction? > > Donald Maner, Jr. donjr@netdoor.com > Internet Doorway, Inc. ircadmin@netdoor.com > Internet Relay Chat Administrator (800)952-1570 > > On Wed, 11 Jun 1997, Jaye Mathisen wrote: > > > Turned off compression and ED&C on the modem, and now the customer reports > > all is well. So he turned it off in his modem, and he be happy camer. > >

On Wed, 11 Jun 1997 kjohnson@usr.com wrote: > Auth-Request, which was fixed in v3.4.86 and in v3.5(BETA). If you have v3.4.2x > code, you should contact tech support for the download location of v3.4.86 to > resolve this issue. Does 3.4.86 also fix the framed-route problem? I really need to have framed-route working by June 19th, when the last Portmaster at my main office goes offline. Brian

This is a multi-part message in MIME format. ------=_NextPart_000_01BC7678.5201E420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I realize that they require trunkside. I ordered that in January from = USWest but ended up with lineside. They also quoted me $26 per month = for the lines way back when but I am now staring at $72 per month per = line. USW changed reps (put me into their SPECIAL ISP group) and none = of them had any idea of what I needed or was getting. I faxed the specs = to them before I bought any of the equipment. This is a long story and = a very sore point with me right now. Regardless, I'm still very = concerned that even after getting hammered for mucho more bucks each = month for these new trunks that customers are going to perceive that = we're slower than other ISP's based upon that initial connect rate. = Even if these do step up after the connect, that's a very hard sell to = customers. How do I explain that after spending $40,000 for modem = equipment to bring in the latest and greatest, that the 31,200 or 28,800 = is really as fast as the other guy? Or our old lines for that matter? = I have some users that redial now unless they get a 33.6 connect. ---- Cc: usr-tc@mail.xmission.com Here's the scoop: x2 requires Trunkside T1 (check x2.usr.com FAQ). Line side is a grouping of analog channels sent to you over a T1 rather than a true digital connection from the switch (which is the basis of x2). The issue of lower connect speeds is explained by an email issued from Tech Support at USR: The connection problems you've had are not typical, but shouldn't be considered "abnormal" either. There are a couple of things that could be contributing. Certainly, the T1 link (vs. a PRI) is a candidate for losing the highest notch for connection speed. Well, one thing that has been noted before (millions of times before on COMP-DCOM-MODEMS, and in many trade reviews) is that USR modems are not as aggressive in the speeds that they're willing to connect. We have taken a more conservative approach for many years with regards to line negotiation, with the goal of providing a rock-solid reliable connection over the duration of the transfer.=20 During the connection, and if the signal is good, we will frequently speed-shift up, meaning that the remote user actually gets more speed than we originally reported. Summary: Initial connection speeds show up lower due to "bit robbing" by the T1, but "speed shift" up after the connection is established. I've got logs of connection speeds that prove this as well... Timothy On Wed, 11 Jun 1997, Greg Coffey wrote: > Date: Wed, 11 Jun 1997 11:26:28 -0600 > From: Greg Coffey <greg@coffey.com> > Reply-To: usr-tc@mail.xmission.com > To: usr-tc@mail.xmission.com > Subject: Re: (usr-tc) AMI/D4 vs B8ZS/ESF for CT1 > > Everyone that I've talked to that has x2 running tells me that they're > seeing <=3D31200 connects for regular modems and generally in the 40's = for x2 > connects with trunk side lines. USW is supposed to put in our trunk = side > lines this week, my rep finally seems to know what the difference is = between > line and trunk side. We have line side now and cannot connect x2 at = all. > The best that I'm seeing now are 28.8 and we've been screwing with the > settings for months with both USW and USR.=20 > > > At 10:47 AM 6/11/97 -0500, you wrote: > >I have a USR DWAN hub with a PRI NAC. I'm going to be flashing it = with > >the channelized T1 code. > > > >Does anyone have any experience with using channelized T1 that has = AMI/D4 > >framing vs B8ZS/ESF framing? > > > >I specifically want to know if the type of framing will affect X2 and = V34 > >connect speeds. The lines are trunk side. USR tech support says it > >shouldn't matter, but I'd like some real world answers if possible. > > > >I already asked this on the inet-access list, but didn't any answers = other > >than someone insisting that AMI/D4 lines are not trunk side. > > > >Brian > > > > > > > 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 > ------------------------------------------------------------- > > ------=_NextPart_000_01BC7678.5201E420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN"> <HTML> <HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR> </HEAD> <BODY><FONT face=3DArial size=3D2> <P>I realize that they require trunkside. I ordered that in January = from USWest=20 but ended up with lineside. They also quoted me $26 per month for the = lines way=20 back when but I am now staring at $72 per month per line. USW changed = reps (put=20 me into their SPECIAL ISP group) and none of them had any idea of what I = needed=20 or was getting. I faxed the specs to them before I bought any of the = equipment.=20 This is a long story and a very sore point with me right now. = Regardless, I'm=20 still very concerned that even after getting hammered for mucho more = bucks each=20 month for these new trunks that customers are going to perceive that = we're=20 slower than other ISP's based upon that initial connect rate. Even if = these do=20 step up after the connect, that's a very hard sell to customers. How do = I=20 explain that after spending $40,000 for modem equipment to bring in the = latest=20 and greatest, that the 31,200 or 28,800 is really as fast as the other = guy? Or=20 our old lines for that matter? I have some users that redial now unless = they=20 get a 33.6 connect.</P> ----<BR> <B>From: </B>Timothy Deem &lt;tdeem2@alpha.comsource.net&gt;<BR> <B>To: </B>Greg Coffey &lt;greg@coffey.com&gt;<BR> <B>Cc: </B>usr-tc@mail.xmission.com<BR> <B>Date: </B>Wednesday, June 11, 1997 2:43 PM<BR> <B>Subject: </B>Re: (usr-tc) AMI/D4 vs B8ZS/ESF for CT1<BR> <BR> <HTML><BODY><FONT size=3D2><BR> Here's the scoop:<BR> <BR> <BR> x2 requires Trunkside T1 (check x2.usr.com FAQ).&nbsp; Line side is = a<BR> grouping of analog channels sent to you over a T1 rather than a true<BR> digital connection from the switch (which is the basis of x2).<BR> <BR> The issue of lower connect speeds is explained by an email issued<BR> from Tech Support at USR:<BR> <BR> The connection problems you've had are not typical, but<BR> shouldn't be considered &quot;abnormal&quot; either.&nbsp; There are = a<BR> couple of things that could be contributing.&nbsp; Certainly,<BR> the T1 link (vs. a PRI) is a candidate for losing the<BR> highest notch for connection speed.<BR> <BR> Well, one thing that has been noted before (millions of<BR> times before on&nbsp; COMP-DCOM-MODEMS, and in many trade<BR> reviews) is that USR modems are not as aggressive in the<BR> speeds that they're willing to connect.&nbsp; We have taken<BR> a more conservative approach for many years with regards<BR> to line negotiation, with the goal of providing a rock-solid<BR> reliable connection over the duration of the transfer.&nbsp;<BR> During the connection, and if the signal is good, we will<BR> frequently speed-shift up, meaning that the remote user<BR> actually gets more speed than we originally reported.<BR> <BR> <BR> <BR> Summary:&nbsp; Initial connection speeds show up lower due to = &quot;bit<BR> robbing&quot; by the T1, but &quot;speed shift&quot; up after the = connection=20 is<BR> established.&nbsp; I've got logs of connection speeds that prove this = as<BR> well...<BR> <BR> <BR> Timothy<BR> <BR> <BR> <BR> <BR> <BR> On Wed, 11 Jun 1997, Greg Coffey wrote:<BR> <BR> &gt; Date: Wed, 11 Jun 1997 11:26:28 -0600<BR> &gt; From: Greg Coffey &lt;<A=20 href=3D"mailto:greg@coffey.com">greg@coffey.com</A>&gt;<BR> &gt; Reply-To: <A=20 href=3D"mailto:usr-tc@mail.xmission.com">usr-tc@mail.xmission.com</A><BR>= &gt; To: <A=20 href=3D"mailto:usr-tc@mail.xmission.com">usr-tc@mail.xmission.com</A><BR>= &gt; Subject: Re: (usr-tc) AMI/D4 vs B8ZS/ESF for CT1<BR> &gt;<BR> &gt; Everyone that I've talked to that has x2 running tells me that = they're<BR> &gt; seeing &lt;=3D31200 connects for regular modems and generally in = the 40's for=20 x2<BR> &gt; connects with trunk side lines.&nbsp; USW is supposed to put in our = trunk=20 side<BR> &gt; lines this week, my rep finally seems to know what the difference = is=20 between<BR> &gt; line and trunk side.&nbsp; We have line side now and cannot connect = x2 at=20 all.<BR> &gt; The best that I'm seeing now are 28.8 and we've been screwing with = the<BR> &gt; settings for months with both USW and USR.&nbsp;<BR> &gt;<BR> &gt;<BR> &gt; At 10:47 AM 6/11/97 -0500, you wrote:<BR> &gt; &gt;I have a USR DWAN hub with a PRI NAC.&nbsp; I'm going to be = flashing it=20 with<BR> &gt; &gt;the channelized T1 code.<BR> &gt; &gt;<BR> &gt; &gt;Does anyone have any experience with using channelized T1 that = has=20 AMI/D4<BR> &gt; &gt;framing vs B8ZS/ESF framing?<BR> &gt; &gt;<BR> &gt; &gt;I specifically want to know if the type of framing will affect = X2 and=20 V34<BR> &gt; &gt;connect speeds.&nbsp; The lines are trunk side.&nbsp; USR tech = support=20 says it<BR> &gt; &gt;shouldn't matter, but I'd like some real world answers if = possible.<BR> &gt; &gt;<BR> &gt; &gt;I already asked this on the inet-access list, but didn't any = answers=20 other<BR> &gt; &gt;than someone insisting that AMI/D4 lines are not trunk = side.<BR> &gt; &gt;<BR> &gt; &gt;Brian<BR> &gt; &gt;<BR> &gt; &gt;<BR> &gt; &gt;<BR> &gt; Thanks,<BR> &gt; Greg Coffey, CoffeyNet<BR> &gt; -------------------------------------------------------------<BR> &gt; 142 S. Center = St.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20 Local Internet&nbsp; for Casper, Rawlins, Douglas,<BR> &gt; Casper, WY&nbsp; 82601&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; = Wheatland,=20 Pinedale, Lander &amp; Lusk, WY<BR> &gt; <A=20 href=3D"http://www.coffey.com">http://www.coffey.com</A>&nbsp;&nbsp;&nbsp= ;&nbsp;&nbsp;=20 (307) 234-5443<BR> &gt; -------------------------------------------------------------<BR> &gt;<BR> &gt;<BR> </FONT></FONT> </BODY></HTML> ------=_NextPart_000_01BC7678.5201E420--

Here's the scoop: x2 requires Trunkside T1 (check x2.usr.com FAQ). Line side is a grouping of analog channels sent to you over a T1 rather than a true digital connection from the switch (which is the basis of x2). The issue of lower connect speeds is explained by an email issued from Tech Support at USR: The connection problems you've had are not typical, but shouldn't be considered "abnormal" either. There are a couple of things that could be contributing. Certainly, the T1 link (vs. a PRI) is a candidate for losing the highest notch for connection speed. Well, one thing that has been noted before (millions of times before on COMP-DCOM-MODEMS, and in many trade reviews) is that USR modems are not as aggressive in the speeds that they're willing to connect. We have taken a more conservative approach for many years with regards to line negotiation, with the goal of providing a rock-solid reliable connection over the duration of the transfer. During the connection, and if the signal is good, we will frequently speed-shift up, meaning that the remote user actually gets more speed than we originally reported. Summary: Initial connection speeds show up lower due to "bit robbing" by the T1, but "speed shift" up after the connection is established. I've got logs of connection speeds that prove this as well... Timothy On Wed, 11 Jun 1997, Greg Coffey wrote: > Date: Wed, 11 Jun 1997 11:26:28 -0600 > From: Greg Coffey <greg@coffey.com> > Reply-To: usr-tc@mail.xmission.com > To: usr-tc@mail.xmission.com > Subject: Re: (usr-tc) AMI/D4 vs B8ZS/ESF for CT1 > > Everyone that I've talked to that has x2 running tells me that they're > seeing <=31200 connects for regular modems and generally in the 40's for x2 > connects with trunk side lines. USW is supposed to put in our trunk side > lines this week, my rep finally seems to know what the difference is between > line and trunk side. We have line side now and cannot connect x2 at all. > The best that I'm seeing now are 28.8 and we've been screwing with the > settings for months with both USW and USR. > > > At 10:47 AM 6/11/97 -0500, you wrote: > >I have a USR DWAN hub with a PRI NAC. I'm going to be flashing it with > >the channelized T1 code. > > > >Does anyone have any experience with using channelized T1 that has AMI/D4 > >framing vs B8ZS/ESF framing? > > > >I specifically want to know if the type of framing will affect X2 and V34 > >connect speeds. The lines are trunk side. USR tech support says it > >shouldn't matter, but I'd like some real world answers if possible. > > > >I already asked this on the inet-access list, but didn't any answers other > >than someone insisting that AMI/D4 lines are not trunk side. > > > >Brian > > > > > > > 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 Tue, 10 Jun 1997, Brian wrote: > On Tue, 10 Jun 1997, Adam Wills (Global 2000) wrote: > > USR has LOTS of attributes that go unused unless you use THERE software > for radius. The NMC for example has the ability to log ALOT of cool stuff > like Caller ID etc. One day this will hopefully be incorporated into > Merit. > > Brian That's great, but I want to use it under UNIX and all that I believe I got was for NT. > 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 MacKenzie tomservo@erie.net System Administrator ErieNet, Inc.

ED&C? Is that v.42 error correction? Donald Maner, Jr. donjr@netdoor.com Internet Doorway, Inc. ircadmin@netdoor.com Internet Relay Chat Administrator (800)952-1570 On Wed, 11 Jun 1997, Jaye Mathisen wrote: > Turned off compression and ED&C on the modem, and now the customer reports > all is well. So he turned it off in his modem, and he be happy camer.

On Wed, 11 Jun 1997, Bob Purdon wrote: > > > Thanks for the suggestion. I do have the Quad Modems set to priTdm. Now > > one thing about that card, is it was orignally set for T1 from the > > factory, I downloaded PRI 2.5.1 file and reflashed it to make it PRI. > > > > This isn't a hit or miss thing either. If i reboot the netserver card, > > the PRI WILL lose the QuadModems, and I have to go in there and reinstall > > them in the PRI card. Any other ideas? > > I'm seeing the exact same thing here with our Dual-PRI card. It came > already flashed for PRI (2.5.1). I changed the modem configs to priTdm > and saved to NVRAM, configured the Quads in the PRI and saved to NVRAM. > *Every* time I reboot the PRI card this section of the config gets lost. Wierd. My PRI card just dumps the quad modem configs everytime I boot the netserver, USR has a ticket open.......... Brian > > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > 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, 11 Jun 1997, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > >You can get Called ID with any radius code, as long you have the > >attributes > > > >ATTRIBUTE Called-Station-Id 30 string > >ATTRIBUTE Calling-Station-Id 31 string > > > > > >This will tell you the Caller id stuff. You can modify the radius code > >to get the other stuff, for connect message as of today these attributes > >are supported only on the NMC. > > As of 3.3.28, only ISDN connections report the Calling-Station-Id. How do > I get my analog connections to do the same? > good question, id like to know too 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, 11 Jun 1997, Jaye Mathisen wrote: > > > One of my customers was complaing about lag through the TC when playing > quake. Read through the backlog in the mail archive, didn't see anything > really useful. > > Turned off compression and ED&C on the modem, and now the customer reports > all is well. So he turned it off in his modem, and he be happy camer. > > Don't know if this helps. > > You turned off ED&C on one of your USR modems, or the customer? You shouldnt have to turn anything off in your modems, if the customer doesnt negotiate ED&C it wont get used. With quake, yes, turning off ED&C will always help things, because of the type of data being sent, but the quake lag problem is a much more severe lag problem that I think has been narrowed down to the USR TC level. 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 said once upon a time: >> Wierd. My PRI card just dumps the quad modem configs everytime I boot the >> netserver, USR has a ticket open.......... > >Actually, I've made mine stick now. All I did was save the NMC settings >to NVRAM and it keeps the config... Bizarre. That is the solution I couldn't remember. Except I think you need to save the entire chassis to NVRAM.

> Thanks for the suggestion. I do have the Quad Modems set to priTdm. Now > one thing about that card, is it was orignally set for T1 from the > factory, I downloaded PRI 2.5.1 file and reflashed it to make it PRI. > > This isn't a hit or miss thing either. If i reboot the netserver card, > the PRI WILL lose the QuadModems, and I have to go in there and reinstall > them in the PRI card. Any other ideas? I'm seeing the exact same thing here with our Dual-PRI card. It came already flashed for PRI (2.5.1). I changed the modem configs to priTdm and saved to NVRAM, configured the Quads in the PRI and saved to NVRAM. *Every* time I reboot the PRI card this section of the config gets lost. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Mark van Wouw <vanwouw@gol.com> writes: > Does anybody know a good way to block incoming calls on a PRI? > By "good" I mean in such a way that incoming calls would just > go to the next netserver on the rotary rather than the caller > getting a busy signal. This turns out to be a very sticky problem, which was something I originally wasn't expecting back when we started using PRI circuits (as we were spoiled by channelized T1 circuits). With channelized T1 configurations (guaranteed with E&M, and it works in almost all ground start circumstances), you can place a particular A/B bit pattern on a channel to take it out of service. The telco switch sees the state and skips over that channel and in general moves on through the hunt sequence. This is equivalent to taking a modem with an analog NIC "off hook" and thus forcing the telco to consider it in use and skip over it. The T1 card is nice in that you can do soft busies and gracefully take things out of service (or hard if you don't care). The "problem" with a PRI configuration is that there are no per-channel bits, and all communication as to the state of a channel and an ongoing call setup/teardown occurs over the D channel. However, in just about all of my tests, regardless of the release code you transmit back, once a telco switch has decided that you have a B channel free and it tries to use it for a call, if the TC rack doesn't want to accept the call, some sort of busy is going to be returned to the user and the telco won't skip over to another span serviced by a different D channel. There are release cause codes (see the recent discussion on this list) that sound like the telco switch should be trying the next thing in the hunt sequence, but nobody seems to do that. It's possible that there might be some way to configure a telco switch to do what you want, and I've been meaning to spend some more time with those telcos we have a close relationship with to see if we could get it to work, but up to this point it hasn't been very promising. Now enter "service messages", which is the closest thing you can get on a PRI to the individual control of the busy state of each DS0 on a channelized T1. With service messages, either end can tell the other that it wants to take one or more B channels in or out of service (the actual messages go over the D channel). As long as both ends understand each other, this gives the switches on either end the opportunity to know up front which channels are supposed to be out of service, and to skip over them nicely. There were a variety of issues I had with USRs early support of service messages (not the least of which was if the remote end didn't understand them you could get your PRI card wedged in a state where it thought the remote end was out of service which you had to reboot to clear), but the upcoming TCS 2.5.1 release is finally not too bad. If you have a configuration where the telco switch understands service messages this works very nicely. The latest PRI code treats out of service operations as "soft" so they take effect upon the completion of the current call on that channel. (There's no explicit "hard" command like on a T1 but you can always disconnect the channel allowing the pending out-of-service operation to complete). When you're ready to use the channels again just place them back in service. The rub is that service messages are not part of any international (or national for that matter) standard, and there are multiple proprietary extensions by switch manufacturers, all to accomplish the same basic goal. In particular, the NI2 signaling standard does not support an out of service modality (just an "in service" message during startup) which I consider a major lack of functionality. What this means is to make this work right you want to be connected to a 4ESS, 5ESS or DMS-100 that are configured in "custom" mode (so that you configure your PRI card for that switch type and not NI2), and in the case of the DMS-100 ensure that the telco has service messages enabled on their end. Unfortunately this won't work for other switches implementing NI2 (and not mimicing one of the above switch types) or for various international switches. I note your signature is from Japan - this won't work on the INS-1500 (NTT) for example. I have heard that there are efforts to standardize service messages as well as supporting them on more switches, but the above is about it at this point. Thus, for our sites I've taken to having our circuit ordering folks explicitly prefer the above switches and ask for them to be configured in custom mode. It's a drag not using the NI2 standard, but I want the functionality whenever I can get it. If you have a site where you can't use service messages, your options are quite limited and unfortunately mostly destructive. About the only thing that I've been able to get working reliably in all cases is to actually take the D channel down on the span(s) that I want the telco to skip. This is destructive as it knocks off current users, and normally the simplest way I do it is to put the circuit out of frame. But once you've got the D channel down, the telco switch is going to skip over all B channels that D channel manages, so although it is destructive to existing sessions it does give you a gross level of control to free up hubs for maintenance or whatever while allowing other hubs at a number to continue to take calls. > When I use Span Line Blocking on the PRI card and select BlockAll, it > looks like the PRI card does a reset...in any case, it drops all the > current connections (undesirable) and then gives busy signals to > incoming calls. I'm not positive of the behavior of span line blocking - I thought I was able to change it on the fly without affecting current calls, but I might also not have been changing it to something that invalidated the current calls, so I'm not positive. Unfortunately, all of the block methods are implemented by receiving the call setup from the telco switch and then returning an appropriate release cause code as set on the card for the "out of resource" type of message. You'd think that when this was designed the telco switch would have been able to skip to other likely resources, but again in my experience it just doesn't happen - instead the switch treats it as a final failure and returns the busy (or reorder tone) to the user. So this falls into the above discussion about the release codes. > It is possible to do this gracefully if you have analog lines going > into the NIC. One command will busy out each channel as the users > disconnects. Yeah, it's a bummer that the most recent "best" circuit type is the hardest to get this kind of functionality on compared to the other connection methods (analog and digital)... -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

> Wierd. My PRI card just dumps the quad modem configs everytime I boot the > netserver, USR has a ticket open.......... Actually, I've made mine stick now. All I did was save the NMC settings to NVRAM and it keeps the config... Bizarre. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> That's great, but I want to use it under UNIX and all that I believe I got > was for NT. I'd really like to see USR do a port over to BSDI for their SECURITY and ACCOUNTING software. After all, they've already done an agreement with them for the EdgeServer to incorporate BSDI. It only makes sense. --I don't want to run my security/accounting on NT!!!-- One feature I requested via phone which I haven't seen or heard about yet would be the addition of a second accounting server option in the NetServer code. I'm not talking about a secondARY server, which is already there. I'm talking about designating a machine as a 2nd machine to receive a copy of radius accounting packets. If that were set up, I could envision using NT as that 2nd machine. But I don't want to trust NT (at this point) for primary accounting purposes. How about it USR? Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net When subtlety fails us we must resort to cream pies.

I'm running radius.esva (modified version of Livingston 1.16) under BSDI Unix. I've copied the attributes from the USR dictionary into the dictionary file and done a kill -HUP. I'm still not seeing the CLID reported (although the telco rep just told me that we do have it configured on our PRI). Can anyone suggest what I may be missing in this equation to get this stuff to show up? Thanks, Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net One-seventh of your life is spent on Monday.

Does anybody know a good way to block incoming calls on a PRI? By "good" I mean in such a way that incoming calls would just go to the next netserver on the rotary rather than the caller getting a busy signal. When I use Span Line Blocking on the PRI card and select BlockAll, it looks like the PRI card does a reset...in any case, it drops all the current connections (undesirable) and then gives busy signals to incoming calls. It is possible to do this gracefully if you have analog lines going into the NIC. One command will busy out each channel as the users disconnects. Mark. --- Global OnLine Japan - PPP, ISDN, x2, Web & Corporate Internet Services Mark van Wouw Network Operations Email: vanwouw@gol.com Phone: 03-5341-8000

> Wierd. My PRI card just dumps the quad modem configs everytime I boot the > netserver, USR has a ticket open.......... Speaking of PRI problems, has anyone seen the situation where calls on the first 15 B channels are fine, but on the last 15 B channels the call is answered but left dead? We're running G704-CRC, HDB3, and TS014, all of which match our Telco's specification. I'm assuming it's a PRI card configuration thing, but I'm not sure what... I've tried mapping channel X (X>16) to a specific modem and still have the problem. Any ideas anyone? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

I had a few problems a week ago, I found the solutions thanks to people on this list and would like to re-cap: If the Pri card loses your chasis card configuration each time you boot your netserver, highlight the NMC card in TCM, and do an Action/Save Chasis to NVRAM. If your running 3.4.23 and notice that it adds THREE routes for EVERY user that dials in, then you are doing nothing wrong, this is a bug in the code, and is fixed in versions >3.4.79 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 Fri, 13 Jun 1997, David Bolen wrote: > Brian <signal@shreve.net> writes: > > > If the Pri card loses your chasis card configuration each time you boot > > your netserver, highlight the NMC card in TCM, and do an Action/Save > > Chasis to NVRAM. > > I'm curious, do you also have the automatic chassis configuration > feature of the NMC enabled? If so then I guess I could see that if it > tried to reconfigure the PRI card automatically based on its stored > information that it could be causing the problem. no, I have that turned off :). > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, Inc. \ Phone: (914) 789-5327 | > / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ > \-----------------------------------------------------------------------/ > 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 <signal@shreve.net> writes: > If the Pri card loses your chasis card configuration each time you boot > your netserver, highlight the NMC card in TCM, and do an Action/Save > Chasis to NVRAM. I'm curious, do you also have the automatic chassis configuration feature of the NMC enabled? If so then I guess I could see that if it tried to reconfigure the PRI card automatically based on its stored information that it could be causing the problem. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 789-5327 | / 100 Clearbrook Road, Elmsford, NY 10523 \ Fax: (914) 789-5310 \ \-----------------------------------------------------------------------/

Does anyone know of a free SNMP MIB browser that can speak adequately with USR's Enterprise MIB? --- Mark R. Lindsey, mark@datasys.net DSS Online Network Engineer (912) 241-0607, Fax: 241-0190

On the same topic any one know why I get this from the Accounting radius Server?? Why does Radius work but Accounting doesn't ?? Fri Jun 13 21:32:53 1997: authenticateAcctReq: host.1645, id=28: bad authenticator TIA Roger Salisbury AXS4U Networking Inc. rogers@axs4u.net

> I'm curious, do you also have the automatic chassis configuration > feature of the NMC enabled? If so then I guess I could see that if it > tried to reconfigure the PRI card automatically based on its stored > information that it could be causing the problem. In our case, no, that feature is currently disabled. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

In previous messages on the list, I was informed that the download speed to the USR-TC is limited by the speed at which the data can be written to nvram, which happens to be very slow (compared to 10baseT). Yet, when sending the same version of quad code to 6 cards instead of 1, it takes six times longer! Why can't the NMC send this code to all quad cards (of the same type) simultaneously.. isn't this simple optimization feasible? - lv

What does this error message mean: BIF==NULL? Win95 just bombs when Multilink is enabled with a second modem. -- Jun 16 04:24:21 Total-Control mpip_process_request: Jun 16 04:24:21 Total-Control [BIF IS NULL] Jun 16 04:24:21 Total-Control [MPIP_LINK_REG_REQ] -- - lv

> On the same topic any one know why I get this from the Accounting=20 > radius Server?? Why does Radius work but Accounting doesn't ?? > Fri Jun 13 21:32:53 1997: authenticateAcctReq: host.1645, id=3D28: > bad authenticator =20 I've analyzed radius accounting packets coming from the netserver (as = version 3.3.28). The authenticator field is all zeros (i.e. 128-bit = number "0"). I guess this is because first versions of radius accounting = server for windows didn't care about authentication at all. I haven't = checked this with latest codes yet. > TIA > Roger Salisbury =09 > AXS4U Networking Inc.=09 > rogers@axs4u.net Kamil Kukura UNICOM CZ

> On the same topic any one know why I get this from the Accounting=20 > radius Server?? Why does Radius work but Accounting doesn't ?? > Fri Jun 13 21:32:53 1997: authenticateAcctReq: host.1645, id=3D28: > bad authenticator =20 I've analyzed radius accounting packets coming from the netserver (as = version 3.3.28). The authenticator field is all zeros (i.e. 128-bit = number "0"). I guess this is because first versions of radius accounting = server for windows didn't care about authentication at all. I haven't = checked this with latest codes yet. > TIA > Roger Salisbury =09 > AXS4U Networking Inc.=09 > rogers@axs4u.net Kamil Kukura UNICOM CZ

Hi, since last week we own an USR Total Control Network Hub with 3 Quad Modem Cards. Our users have no problems when connection via ISDN, but Modem-Connects are terminated by an "LOST-CARRIER" after 2 or 5 minutes. Has anybody of you an idea how to configure the Modem Cards to improve stability of the connections? Thanx for help, Bye, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: lars@forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

We recently purchased a 16meg, 60 ns, non-parity, 72-pin SIMM so we could upgrade the Netserver in our rack. The problem is that when we install the SIMM, the Netserver stops talking to its ethernet port. I can connect via the console port and ifconfig shows ip as up, but nothing gets through. Show mem shows there are 16 meg in the card and I know the memory is good. Anyone have any ideas why it won't work? The firmware is at 3.3.3 (which is the latest for the standard netserver). Thanks Wayne Barber - barberw@tidewater.net Internet System Administrator Coastal Telco Services

Well, I can't speak to the problem, but I can relate to USR's apparent inability to function as tech support unless they have access to the box, and I'm sorry, I'm not giving out access to any joe schmuck out there who somehow thinks he can read better than I can. If you get it figured out, I'd like to see the answer as well. Thanks. On Fri, 20 Jun 1997, Jeff Mcadams wrote: > USR Total Control rack...dual pri card, 12 quad digital modem cards, > netserver pri card with 16 MB RAM 3.4.23.... > > taking, answering, and handling analog calls with *no* problem whatsoever > across the PRI...working like a charm...even our definitely non-standard > port configuration...couldn't be happier in that arena. > > Call in with an ISDN line...(default protocol is default-sync), call gets > answered...goes through LCP configuration without a hitch (according to > linux pppd with debug flag), starts sending auth PAP packets (with correct > userid and password), and never gets any responses....netserver Ix ports > all show as idle...no CONNECTING, no ESTABLISHED or anything of the > sort...seemingly, the call is being answered by the PRI card, but the call > data is never getting passed to the netserver card for authentication and > processing of the call. > > Anyone run into this at all? USR tech support was practically worthless > (giving the explanation that if they couldn't dial-in or telnet-in to the > netserver that they couldn't do much with it at all)....so I'm turning to > the experiences of other USR-TC users out there. > > Thanks > -- > Jeff McAdams | "OK, we have enough youth... > IgLou Internet Services | How about a fountain of smart?" > e-mail: jeffm@iglou.com | - unknown >

Well, I can't speak to the problem, but I can relate to USR's apparent inability to function as tech support unless they have access to the box, and I'm sorry, I'm not giving out access to any joe schmuck out there who somehow thinks he can read better than I can. If you get it figured out, I'd like to see the answer as well. Thanks. On Fri, 20 Jun 1997, Jeff Mcadams wrote: > USR Total Control rack...dual pri card, 12 quad digital modem cards, > netserver pri card with 16 MB RAM 3.4.23.... > > taking, answering, and handling analog calls with *no* problem whatsoever > across the PRI...working like a charm...even our definitely non-standard > port configuration...couldn't be happier in that arena. > > Call in with an ISDN line...(default protocol is default-sync), call gets > answered...goes through LCP configuration without a hitch (according to > linux pppd with debug flag), starts sending auth PAP packets (with correct > userid and password), and never gets any responses....netserver Ix ports > all show as idle...no CONNECTING, no ESTABLISHED or anything of the > sort...seemingly, the call is being answered by the PRI card, but the call > data is never getting passed to the netserver card for authentication and > processing of the call. > > Anyone run into this at all? USR tech support was practically worthless > (giving the explanation that if they couldn't dial-in or telnet-in to the > netserver that they couldn't do much with it at all)....so I'm turning to > the experiences of other USR-TC users out there. > > Thanks > -- > Jeff McAdams | "OK, we have enough youth... > IgLou Internet Services | How about a fountain of smart?" > e-mail: jeffm@iglou.com | - unknown >

USR Total Control rack...dual pri card, 12 quad digital modem cards, netserver pri card with 16 MB RAM 3.4.23.... taking, answering, and handling analog calls with *no* problem whatsoever across the PRI...working like a charm...even our definitely non-standard port configuration...couldn't be happier in that arena. Call in with an ISDN line...(default protocol is default-sync), call gets answered...goes through LCP configuration without a hitch (according to linux pppd with debug flag), starts sending auth PAP packets (with correct userid and password), and never gets any responses....netserver Ix ports all show as idle...no CONNECTING, no ESTABLISHED or anything of the sort...seemingly, the call is being answered by the PRI card, but the call data is never getting passed to the netserver card for authentication and processing of the call. Anyone run into this at all? USR tech support was practically worthless (giving the explanation that if they couldn't dial-in or telnet-in to the netserver that they couldn't do much with it at all)....so I'm turning to the experiences of other USR-TC users out there. Thanks -- Jeff McAdams | "OK, we have enough youth... IgLou Internet Services | How about a fountain of smart?" e-mail: jeffm@iglou.com | - unknown

Is there a debug mask in netserver to show everything that is sent to the syslog on the console? Regards, Charles Hill

On Sun, 22 Jun 1997, Lars Freund wrote: > Hi Charles Hill, > > > Is there a debug mask in netserver to show everything that is sent to the > > syslog on the console? > > there ist: > > set consoloe > set debug 0x71 > > and to finisch: > > set debug 0x00 > reset console > > an there is ptrace, but there you must specify a filter. > > > Antoher Question: how can I see the Firmware Version of the Modems? > > > Greetings, > > Lars > > -- > +-----------------------------------------------------------------+ > | Lars Freund lars@forchheim.com | > | FOnLine Buergernetzverein: lars@forchheim.baynet.de | > | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | > +-----------------------------------------------------------------+ > > Using the NMC you can tell the frim ware of the modem or you can reverse telnet to the modem and type ati7. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec

Hi Charles Hill, > Is there a debug mask in netserver to show everything that is sent to the > syslog on the console? there ist: set consoloe set debug 0x71 and to finisch: set debug 0x00 reset console an there is ptrace, but there you must specify a filter. Antoher Question: how can I see the Firmware Version of the Modems? Greetings, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: lars@forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Hi Tatai SV Krishnan, > > Antoher Question: how can I see the Firmware Version of the Modems? > > > Using the NMC you can tell the frim ware of the modem or you can reverse > telnet to the modem and type ati7. Thanks for your response, but... - what is NMC? I only use telnet access by unix/linux. - how can I talk directly to the modem? When I type a command "dial" the USR responses something about a missing location table and I don't want to make one because our USR TC is only considered for Dial-In-Acess - or ist that no problem? Thanks again for any help. Greetings, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: lars@forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Hi out there, we have the same problem as Wayne described. We followed the USR specs of 16meg modules and tried all kinds of tricks. Such as downgrading to 3.2.x before exchanging the memory module and upgrading (to 3.3.28) after that. We also tried a version for the new netserver hardware (3.4.23) which didn't work any better. We can't ping the netserver from the LAN nor the LAN from the netserver (connected via the console port). I just opened a call in Dublin. Wayne, did you find anything out meanwhile? Stefan Virsik mailto:virsik@metronet.de Metronet Postfach 510 869 phone: (+49) 221 3091 272 50944 Cologne, Germany fax: (+49) 221 3091 298 Wayne Barber wrote: > > We recently purchased a 16meg, 60 ns, non-parity, 72-pin SIMM so we > could upgrade the Netserver in our rack. The problem is that when we > install the SIMM, the Netserver stops talking to its ethernet port. I > can connect via the console port and ifconfig shows ip as up, but > nothing gets through. Show mem shows there are 16 meg in the card and > I know the memory is good. Anyone have any ideas why it won't work? > The firmware is at 3.3.3 (which is the latest for the standard > netserver). > Thanks > > Wayne Barber - barberw@tidewater.net > Internet System Administrator > Coastal Telco Services

From: "Kamil Kukura" <KAMIL@nw3.unicom.cz> Subject: Re: (usr-tc) latest USR challenge Date: 24 Jun 1997 10:56:43 +0100

Is anyone using a PD version of RADIUS on SCO Unix 3.2.v5.0.2 with a USR TC? We are just getting started and have a lot of dumb questions.

Are you talking about the USR Total Control chassis? I know of one available, he has some 14.4 modems and other things in it. I think he'd sell it for $1,000 as is. Dual 45 amp power supplies, looks like new. I'll check into it further if you are interested. At 12:09 PM 6/24/97 -0500, you wrote: >We have been looking for a USR 477 Chassis ... a simple request it would seem, but >no one can get us the product. > > ... (2) 45Amp Power Supplies and a box wrapped around it. > >Got any ideas or phone numbers anyone? > >Marshall Morgan >President > >Internet Doorway, Inc. >http://www.netdoor.com >601.969.1434 | 800.952.1570 | 601.969.3838 Fax > > > 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 been looking for a USR 477 Chassis ... a simple request it would seem, but no one can get us the product. ... (2) 45Amp Power Supplies and a box wrapped around it. Got any ideas or phone numbers anyone? Marshall Morgan President Internet Doorway, Inc. http://www.netdoor.com 601.969.1434 | 800.952.1570 | 601.969.3838 Fax

We have a customer who cannot establish a MultiLink PPP connection to Chassis A, but can to Chassis B. I have tried to set up both indentically. Both run TCS v2.5, does anyone know what could be the problem? Brian oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

Use the following command on your Netserver in chassis A set mp_adv on This will cause the NETServer to advertise multilink during lcp negotiation krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 24 Jun 1997, Brian wrote: > We have a customer who cannot establish a MultiLink PPP connection to > Chassis A, but can to Chassis B. I have tried to set up both > indentically. > > Both run TCS v2.5, does anyone know what could be the problem? > > Brian > > > > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > Brian Feeny oo ShreveNet, Inc. oo Phone: (318) 222-2NET > UNIX Administrator oo 333 Texas St #619 oo FAX: (318) 221-6612 > signal@shreve.net oo Shreveport, LA 71101 oo http://www.shreve.net/ > oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo > > >

At 11:10 AM 6/24/97 PDT, you wrote: >Is anyone using a PD version of RADIUS on SCO Unix 3.2.v5.0.2 with a >USR TC? We are just getting started and have a lot of dumb questions. > > I have run it on everything but SCO.. Any reason for choosing SCO?? For the PD version LINUX is quite robust and of course free.. What kind of questions do you have.. If they are more UNIX based and not particular to SCO I can probably help.. -Mike ======================================================================== Michael Wronski (michaelw@fiu.edu)

On Tue, 24 Jun 1997, Peter Black wrote: > Is anyone using a PD version of RADIUS on SCO Unix 3.2.v5.0.2 with a Is there a PD version availible? I only know about the radius-source from Livingston, but this is NOT PD, even if they distribute this one public. > USR TC? We are just getting started and have a lot of dumb questions. MUST run :-) Check the logfiles, they will tell a lot!

On Tue, 24 Jun 1997, Peter Black wrote: > Is anyone using a PD version of RADIUS on SCO Unix 3.2.v5.0.2 with a Is there a PD version availible? I only know about the radius-source from Livingston, but this is NOT PD, even if they distribute this one public. > USR TC? We are just getting started and have a lot of dumb questions. MUST run :-) Check the logfiles, they will tell a lot!

If I configure a group of Netservers with a /22 supernet of Clas C addresses and a user logs into one and is assigned an IP by RADIUS in the same /22 network, but not in the assigned pool of the answering Netserver, the Netserver (v3.4.23) doesn't answer ARP requests for that user's IP; it does not receive his traffic. User has a dead connection that you can ping from the Netserver console. . . only. Is this addressed in Netserver 3.5? (pun unintentional) What I am trying to do is devise a method for assigning a few particular users a static IP without having them dial into a specific Netserver, but a group of 14 Netservers. The routing is a challenge, but I don't think it should be. I really really want to avoid RIPv2. Regards, Charles Hill _/~\_/~\_/~\_/~\_/~\_/~\_/~\_ email: chill@ionet.net pager: 405/559.6697 http://www.ionet.net/~chill _/~\_/~\_/~\_/~\_/~\_/~\_/~\_

Unlike other servers, the USR-TC does not appear to have a finger daemon available. We are using SCO Unix/RADIUS and would like to be able to see who is logged on from a Unix prompt. Has anyone done this? Thanks.

> we have the same problem as Wayne described. We followed the USR > specs of 16meg modules and tried all kinds of tricks. Such as > downgrading to 3.2.x before exchanging the memory module and upgrading > (to 3.3.28) after that. Odd. We just bought 16mb 70ns non-EDO SIMM modules, as per the USR spec, plugged them in, and away it went. We had 3.3.28 on the card at the time. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

How does the USR TC handle Full Duplex Ethernet. I was told by one of the engineers that the netserver NIC can indeed handle FD 10baseT, but that the NMC NIC probably couldn't on a heavily loaded system. Is there a setting to enable FD, or is it autodetecting? Any experiences in running 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

I can't seem to get any of our hubs to log to syslog on any of our UNIX machines, here is what I have: On the USR TC hub: Sys Loghosts: 208.206.76.5 0.0.0.0 Command> sh facility Syslog facility: auth Syslog priority: info that should be it on the USR TC hub right? Now, 208.206.76.5 is a UNIX host, running syslog, and here is whats on there: # USR TC auth.info /usr/adm/authlog Any ideas? 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

We are on a DMS 100, and have noticed the following: Sometimes I find that the DS0 status's on the PRI card are "OOS". This happens not all the time, but every once in a great while. Then I go into PRI card, place entire span back in service and thats that. What would cause them to just go OOS? I thought one of the USR engineers had told me once, that the DMS 100 has a problem with the USR TC. If the lines are placed OOS, even for a second, then once they "come back" the usr does not get the "restart" command from the DMS 100, so they sit there until you manually restart them. This supposedly doesnt happen on AT&T 5 ESS switches. Can anyone confirm/comment on this? I am assuming, since it was a OOS and not a LOOS that the action came from the phone company and not our end, is this an accurate assumption? 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, 26 Jun 1997, Dave Mitton wrote: > At 09:10 PM 6/25/97 PDT, Peter Black wrote: > >Unlike other servers, the USR-TC does not appear to have a finger daemon > >available. We are using SCO Unix/RADIUS and would like to be able to > >see who is logged on from a Unix prompt. Has anyone done this? > > > >Thanks. > > I'm curious; What vendors _DO_ have finger support? > > I don't believe that Livingston, Ascend, nor we do. But I could be wrong. > > Dave. Xylogics Annex servers do Brian > -------------------------------------------------------------- > David Mitton 508-670-8888 Main > Consulting Engineer 508-916-4570 Direct > Bay Networks, Internet/Telcom BG 508-916-4789 FAX > Billerica, MA 01821 dmitton@baynetworks.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

At 09:10 PM 6/25/97 PDT, Peter Black wrote: >Unlike other servers, the USR-TC does not appear to have a finger daemon >available. We are using SCO Unix/RADIUS and would like to be able to >see who is logged on from a Unix prompt. Has anyone done this? > >Thanks. I'm curious; What vendors _DO_ have finger support? I don't believe that Livingston, Ascend, nor we do. But I could be wrong. Dave. David Mitton 508-670-8888 Main Consulting Engineer 508-916-4570 Direct Bay Networks, Internet/Telcom BG 508-916-4789 FAX Billerica, MA 01821 dmitton@baynetworks.com

FYI, perhaps a bit of good news from USW for a change? Comments? >> A bit of good news. I spoke with the T1 product manager at US West today. >> He said that US West was introducing a new, lower tariff for trunk side T1 >> lines (called ADSS service by US West). For ISPs/corporations wanting to >> offer 56K modem connectivity, this is very good news since it will save >> them over $7000/yr >> >> The new pricing is approximately $1200/mth and will be effective in July. >> The old price was about $1850/mth. >> >> One of the stipulations with this new tariff is there can only be one >> "lead" number for the channels you would like on the T/1. In other >> words, you could not mix modem (with one group of channels) and ISDN calls >> (with another group of channels) on this T/1 line. The MAX differentiates >> ISDN callers from modem callers by the channels the calls come in on. >> >> For all modem callers (including 56k) this will be a great benefit to have >> these all on the same T/1 with the same #. >> >> At the central site or ISP a PRI should be used to process calls from >> remote site ISDN BRI callers. PRIs cost about $2,300 per month however are >> 2-4 times more efficient than standard trunks. Therefore, PRI for ISDN is >> more cost effective (and profitable for ISPs) then ADSS for Analog. 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 Thu, 26 Jun 1997, Brian wrote: > > I can't seem to get any of our hubs to log to syslog on any of our UNIX > machines, here is what I have: > > On the USR TC hub: > > Sys Loghosts: 208.206.76.5 0.0.0.0 > > Command> sh facility > Syslog facility: auth > Syslog priority: info > > > that should be it on the USR TC hub right? Now, 208.206.76.5 is a UNIX > host, running syslog, and here is whats on there: > > # USR TC > auth.info /usr/adm/authlog > touch a file called authlog on your unix machine and then restart your syslog demon. Then you will be able to get the syslog information to the file authlog krish > > Any ideas? > > 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 can't seem to get any of our hubs to log to syslog on any of our UNIX : machines; here is what I have: : : On the USR TC hub: : : Sys Loghosts: 208.206.76.5 0.0.0.0 : : Command> sh facility : Syslog facility: auth : Syslog priority: info Verify that the syslog hosts have the TC hubs in the /etc/hosts table; under some versions of syslogd, that's the only method of controlling the hosts from which logs can come.

On Thu, 26 Jun 1997, Greg Coffey wrote: > FYI, perhaps a bit of good news from USW for a change? Comments? > > >> A bit of good news. I spoke with the T1 product manager at US West today. > >> He said that US West was introducing a new, lower tariff for trunk side T1 > >> lines (called ADSS service by US West). For ISPs/corporations wanting to > >> offer 56K modem connectivity, this is very good news since it will save > >> them over $7000/yr > >> > >> The new pricing is approximately $1200/mth and will be effective in July. > >> The old price was about $1850/mth. It's still one heck of a lot of a money per channel. MCI Metro is doing the same thing her in Minneapolis, MN for $21.90 a month per channel. MCI is alos not charging ISPs the federal access charge. T1 trunks are inbound only with one number if it's trunk side. Line side you can have multiple #s per hunt group. MCI Metro has their own switch here, and delivers dial tone via either fiber or T1s leased from US West. I got my first T1 up and running, and it appears to work fairly well. Brian

Apparently, Mindspring posted the following message in response to problems their users were having establishing X2 connections at a few of their POPs.

On Thu, 26 Jun 1997, Russ Panula wrote: > Do you know if MCI Metro is offering PRI service? Yes, MCI Metro just started offering PRI service. $900 a month for two way data service on a year contract. Can't remember the voice/data pricing, but it wasn't nearly as good as the Channelized T1 pricing. I wish MCI would offer inbound only PRI for around $32 a channel. They do not plan to sell inbound only PRI, at least not now. I'd highly recommend checking into MCI Metro for anyone in a large metro area, particularly if you have US West as the your primary LEC. Brian

Ok, I admit, I should of saved the post when I saw it 2 weeks ago on here- but could whoever posted hte SNMP veriable to 'get' connection speeds off the tc post it again. I have done SNMPWALK's to both the netserver snmp module and the NMC snmp and can't see anything that looks like conection speeds- so either its not showing up in a walk, or I am not looking in the right place to monitor for connection speeds (basically x2 or not x2 is all i care about) Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

I bought one of USR's 2059 bundles back in April. I started doing X2 with a MP/8I back on March 22nd when the X2 code for this box came out. I probably have 100 users with X2 capable modems. About every other day, a customer complains that either they can't connect period, or they get a X2 connection, but it drops anywhere from 2 minutes to 2 hours later. I just got my Total Control Hub up and running two days ago. I was hoping it would help the problem, but it hasn't. I still get the same complaints. Right now, the Total Control hub has one T1 hooked up to 24 modems, and the other 24 modems are hooked to POTS lines. The digital side is really only for X2, the analog side is for 33.6 callers. I almost never get a dropped connection complaint about the 33.6 modems, but I get a number of complaints about the X2 modems. (I also have racks of MP/16s that I don't get complaints about) Any ideas on anything I can change so that users don't have so many problems with X2 calls? Brian

Hi all, you should check the modem mib for the call statistics table. There you can find entries like the following. mdmCsFinalRxLinkRate OBJECT-TYPE SYNTAX INTEGER{ bps110(1), [...] bps56K(35), bps57333(36), bps58666(37), bps60K(38), bps61333(39), bps64K(40) } ACCESS read-only STATUS mandatory DESCRIPTION "The current receive link rate of a connection, or the last link rate of the last connection." ::= { mdmCsEntry 13 } mdmCsModulationType OBJECT-TYPE SYNTAX INTEGER{ [...] v32Terbo(19), v34(20), vFC(21), v34plus(22), x2Type(23) <--- check this one! } ACCESS read-only STATUS mandatory DESCRIPTION "Specifies the modulation type of the current or last call." ::= { mdmCsEntry 14 } Stefan Stefan Virsik mailto:virsik@metronet.de Metronet Postfach 510 869 phone: (+49) 221 3091 272 50944 Cologne, Germany fax: (+49) 221 3091 298 Adam Wills (Global 2000) wrote: > > Ok, I admit, I should of saved the post when I saw it 2 weeks ago on here- > but could whoever posted hte SNMP veriable to 'get' connection speeds off > the tc post it again. > > I have done SNMPWALK's to both the netserver snmp module and the NMC snmp > and can't see anything that looks like conection speeds- so either its not > showing up in a walk, or I am not looking in the right place to monitor > for connection speeds (basically x2 or not x2 is all i care about) > > Adam Wills Global 2000 Communications > Director of Networking Systems 1840 Western Ave. > sysadmin@global2000.net Albany, NY, 12203 > http://www.global2000.net (518) 452-1465

Can you put the 70 amp PSU in the older chassis? If so, other than the fan tray, whats the difference between the two? mrw@netdirect.net

Hi all, you might have a problem with your netserver card like running it with less than 16mb ram. After having upgraded to tcs2.5 respectively X2 we became attentive on connection drops after a couple of minutes as well as failing ISDN connects due to memory shortage, too: Jun 2 15:55:53 aaa.bbb.ccc.ddd *** ISDN WARNING ***: DNIS: ANI: 3412xxxxxx Type: B : I0 Call rejected for lack of resources Therefore we're upgrading the netservers to 16mb these days. BTW we needed a more current firmware version than 3.3.28. Stefan Stefan Virsik mailto:virsik@metronet.de Metronet Postfach 510 869 phone: (+49) 221 3091 272 50944 Cologne, Germany fax: (+49) 221 3091 298 Brian Elfert wrote: > > I bought one of USR's 2059 bundles back in April. > > I started doing X2 with a MP/8I back on March 22nd when the X2 code for > this box came out. > > I probably have 100 users with X2 capable modems. About every other > day, a customer complains that either they can't connect period, or they > get a X2 connection, but it drops anywhere from 2 minutes to 2 hours > later. > > I just got my Total Control Hub up and running two days ago. I was hoping > it would help the problem, but it hasn't. I still get the same > complaints. > > Right now, the Total Control hub has one T1 hooked up to 24 modems, and > the other 24 modems are hooked to POTS lines. The digital side is really > only for X2, the analog side is for 33.6 callers. > > I almost never get a dropped connection complaint about the 33.6 modems, > but I get a number of complaints about the X2 modems. (I also have racks > of MP/16s that I don't get complaints about) > > Any ideas on anything I can change so that users don't have so many > problems with X2 calls? > > Brian

This error message indicated that all available b-channels are in Use. It is not related to amount of memory avialble. The number of b-channels default to 60. Please check the number of B-channles you have set on the NETServer. krish ----------------------------------------- \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 27 Jun 1997, Stefan Virsik wrote: > Hi all, > > you might have a problem with your netserver card like running it > with less than 16mb ram. > > After having upgraded to tcs2.5 respectively X2 we became attentive > on connection drops after a couple of minutes as well as failing ISDN > connects due to memory shortage, too: > > Jun 2 15:55:53 aaa.bbb.ccc.ddd *** ISDN WARNING ***: DNIS: ANI: > 3412xxxxxx Type: B : I0 Call rejected for lack of resources > > Therefore we're upgrading the netservers to 16mb these days. BTW we > needed > a more current firmware version than 3.3.28. > > Stefan > > ----------------------------------------------------------------------- > Stefan Virsik mailto:virsik@metronet.de > Metronet > Postfach 510 869 phone: (+49) 221 3091 272 > 50944 Cologne, Germany fax: (+49) 221 3091 298 > > > Brian Elfert wrote: > > > > I bought one of USR's 2059 bundles back in April. > > > > I started doing X2 with a MP/8I back on March 22nd when the X2 code for > > this box came out. > > > > I probably have 100 users with X2 capable modems. About every other > > day, a customer complains that either they can't connect period, or they > > get a X2 connection, but it drops anywhere from 2 minutes to 2 hours > > later. > > > > I just got my Total Control Hub up and running two days ago. I was hoping > > it would help the problem, but it hasn't. I still get the same > > complaints. > > > > Right now, the Total Control hub has one T1 hooked up to 24 modems, and > > the other 24 modems are hooked to POTS lines. The digital side is really > > only for X2, the analog side is for 33.6 callers. > > > > I almost never get a dropped connection complaint about the 33.6 modems, > > but I get a number of complaints about the X2 modems. (I also have racks > > of MP/16s that I don't get complaints about) > > > > Any ideas on anything I can change so that users don't have so many > > problems with X2 calls? > > > > Brian >

I am new to the USR TC's and would like some guidance with regard to Radius. We get Radius 1.16 with our BSDI 3.0 Unix and I can get RADIUS 2.0.1 for BSDI 2.0 (Checking if it will work with 3.0), but my questions are, 1.how does it work with the TC 2.Is there a gui front end for the user file maintenance and or a unix server password maintenance 3.how have the TC's been working for you and how about the x2 Thanks in advance Bill Sheeler William M Sheeler, Sr www.talon.net ceo TCRA Computers and voice 610.670.6491 TALON Network Services, Inc voice 610.670.4923 Fax for both fax 610.670.6495 ( Total Area Linked Online Nationwide Network Services, Inc) " Live with Passion " " It's in your moments of decision that your destiny is shaped " ANTHONY ROBBINS

At 01:52 PM 6/26/97 -0600, you wrote: >FYI, perhaps a bit of good news from USW for a change? Comments? > >>> A bit of good news. I spoke with the T1 product manager at US West today. ... lines removed >>> At the central site or ISP a PRI should be used to process calls from >>> remote site ISDN BRI callers. PRIs cost about $2,300 per month however are >>> 2-4 times more efficient than standard trunks. Therefore, PRI for ISDN is >>> more cost effective (and profitable for ISPs) then ADSS for Analog. I'm new to most of this, and I "thought" I knew the differences between PRI and chanellized T-1, and I was wondering if you could clarify that last statement. In what way are PRI's more efficient? I thought both types offer 23 or 24 incoming lines. PRI's support both analog and ISDN where the other supports only analog. If you could explain or send me a URL or something that may enlighten me further I would be very gratefull! We recently moved our business over to USR-TC with chanellized T-1's from the carrier TCG. We're looking into switching to USW, but are unsure of the advantages. This sounds like it might be a great advantage. We're also now 56k enabled (boy, the upgrade was a major pain)! THANKS! Craig Nelson, Jet City Online Seattle, WA <.>-----------------------------------------------<.> The thing about Crayons is, They can take take you more places than Starships -Guinan <.>-----------------------------------------------<.>

Help!!! Just point me in the right direction (Documentation) We are seeing a bunch of dropped calls recently. They are trapped as "ReTransmitLimit", a few unknowns, and "DS0Teardowns". It seems that the higher the call is on the TDM channel the larger chance it will be dropped. I can find the list of events but no descrition or truth tables of thier causes. The only one I find obvious are the ModemDiscCmd type's Our chassis was purchased as a PRI ready but came with the T1 code that we flash upgraded. I have heard that the PRI card is shipped with more memory. Could this be part of the problem? And what type and size of memories--both flash and RAM--SHOULD be on a a unit with 2-Pri Spans 46 modems. (Though only 1/23 are in use now)

I will be out of the office until the 7th. I have redirected the majordomo@xmission.com alias to a staff member here who is capable enough to fix any problems that happen with the lists. Anything directed to police-owner or usr-tc-owner will still land in my mailbox and will be taken care of upon my return. Excuse this message. It would be far too complicated for me to setup a vacation program that wouldn't respond to all the non-human email I get now. Have a happy 4th o' July. -- Pete XMission

On Fri, 27 Jun 1997, Mark Wilson wrote: > Can you put the 70 amp PSU in the older chassis? If so, other than the fan > tray, whats the difference between the two? > > mrw@netdirect.net > > > The newer chasis has a high density backplane that will support all the new cards USR plans on releasing, including the rumored 24modem cards. The older chasis cannot. The newer chasis have a packet bus clock, so your pri, netserver cards, etc can operate in slave from that. 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 Fri, 27 Jun 1997, Mark Wilson wrote: > Can you put the 70 amp PSU in the older chassis? If so, other than the fan > tray, whats the difference between the two? > > mrw@netdirect.net > > > The newer chasis has a high density backplane that will support all the new cards USR plans on releasing, including the rumored 24modem cards. The older chasis cannot. The newer chasis have a packet bus clock, so your pri, netserver cards, etc can operate in slave from that. 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

Hello Does anyone know, which are the best usable parameters for ipppd in 'isdn for Linux' to get a faster Connect with Linux? I use PAP and the following parameters: +mp ( My provider allows :-) ) -vj, -vjcomp ( playing with it doesn't Change anything) -detach mru 1524 -bsdcomp with this parameters it works fine, but it takes around 20-30 sec to login. I get some rejects ( CCP ConfRej id=0x1) but I don't find what that means. If someone knows how to login from Netserver to Linux ( Dialout ) let me know too please. It is not so easy cause the Netserver doesn't support PAP on dialout so far. so long Ralf

Hi, our USR TC doesn't make anything than problems. Reset every hour, Modem Connects only for some minutes... I telephoned with the Irish Hotline today and the idea was: not enough memory. We have 4 MB Memory, 700k free, for 3 Quad Modem Cards, a Dual Pri Card and a NetServer Card. Modem-Firmare 3.5.6, USR NetServer Firmware 3.4.23. Could another Firmware Version or/and a 16 MB Memory resolve our problems? Greetings, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

Hi, > We're also now > 56k enabled (boy, the upgrade was a major pain)! what sort of update is needed and what does this cost? Bye, Lars -- +-----------------------------------------------------------------+ | Lars Freund lars@forchheim.com | | FOnLine Buergernetzverein: http://www.forchheim.baynet.de | | http://cip2.e-technik.uni-erlangen.de:8080/hyplan/lafreund.html | +-----------------------------------------------------------------+

On Thursday, June 26, 1997 9:15 AM, Dave Mitton [SMTP:dmitton@baynetworks.com] wrote: > At 09:10 PM 6/25/97 PDT, Peter Black wrote: > >Unlike other servers, the USR-TC does not appear to have a finger daemon > >available. We are using SCO Unix/RADIUS and would like to be able to > >see who is logged on from a Unix prompt. Has anyone done this? > > > >Thanks. > > I'm curious; What vendors _DO_ have finger support? > > I don't believe that Livingston, Ascend, nor we do. But I could be wrong. > > Dave. > -------------------------------------------------------------- > David Mitton 508-670-8888 Main > Consulting Engineer 508-916-4570 Direct > Bay Networks, Internet/Telcom BG 508-916-4789 FAX > Billerica, MA 01821 dmitton@baynetworks.com What about pmwho? I can't remember where we got the original source, but we modified it to work with the NETServers? We use it on Livingston and USR terminal servers without a problem. Marshall Morgan Internet Doorway, Inc. http://www.netdoor.com 601.969.1434 | 800.952.1570 | 601.969.3838 Fax

Before we go through a "painless" install of TCS 2.5.1, we want to know if anyone is using it yet and if they have seen any "features" or know issues. Please report as I am sure we all would like to know. Marshall Morgan Internet Doorway, Inc. http://www.netdoor.com 601.969.1434 | 800.952.1570 | 601.969.3838 Fax

On Thursday, June 26, 1997 3:54 PM, Brian Elfert [SMTP:brian@citilink.com] wrote: > Apparently, Mindspring posted the following message in response to > problems their users were having establishing X2 connections at a few of > their POPs. > > ----- > We have received numerous complaints from customers in the Daytona Beach > and Chapel Hill areas of problems establishing X2 connections. We have > consulted with BellSouth and USR (who have both consulted with each other, > and with Nortel) and have found that the central offices in both cities > are simply not capable of providing X2 connections -- to customers in the > same CO as our POP -- at this time. > > The problem is an incompatiblity between USR's X2 client modem code, and > line cards (cards that go into the telephone company switch to provide you > dialtone) in certain Nortel DMS-100 switches, including the ones in these > areas. The bug is USR's, not Nortel's (the modems can't compensate for > the characteristics of these line cards), and USR has stated they hope to > fix the incompatibility as soon as they can. > ----- > > Has anyone else seen this type of problem? Mindspring is saying that > anyone connecting through a DMS100 to an X2 server on the same switch will > have X2 problems. Can't say this is true. We had a few chassis connected to a DMS-100 and PRI and x2 worked fine. Connects from an regular business line to our PRI Chassis with x2 worked around 49k consistently. > How could this affect only calls originating and terminating on the same > switch, and not affect everyone doing an X2 call through a DMS-100 as the > originating switch that terminates at another switch? > Good question. Marshall Morgan Internet Doorway, Inc. http://www.netdoor.com 601.969.1434 | 800.952.1570 | 601.969.3838 Fax

On Sat, 28 Jun 1997, Marshall Morgan wrote: > > Has anyone else seen this type of problem? Mindspring is saying that > > anyone connecting through a DMS100 to an X2 server on the same switch will > > have X2 problems. > > Can't say this is true. We had a few chassis connected to a DMS-100 and PRI and x2 worked > fine. Connects from an regular business line to our PRI Chassis with x2 worked around 49k > consistently. It does say that specific DMS-100 switches are affected. That would indicate that not all DMS-100s would be affected. Maybe there is a specific rev of the switch or line cards affected. Brian

Since the NMC is rarely used (in my case I dont do logging from it, only purpose it really serves is to do a software download) its pointless to keep an additional 10baseT cable connected to the nic card behind it. Can the IP traffic for the NMC be routed through the netservers (10baseT) connection to the lan? - lv

On Sat, 28 Jun 1997, Marshall Morgan wrote: > Before we go through a "painless" install of TCS 2.5.1, we want > to know if anyone is using it yet and if they have seen any > "features" or know issues. > > Please report as I am sure we all would like to know. > > Marshall Morgan > > Internet Doorway, Inc. > http://www.netdoor.com > 601.969.1434 | 800.952.1570 | 601.969.3838 Fax > > 2.5.1 is released? 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 Sat, 28 Jun 1997, Marshall Morgan wrote: > Before we go through a "painless" install of TCS 2.5.1, we want > to know if anyone is using it yet and if they have seen any > "features" or know issues. > > Please report as I am sure we all would like to know. > > Marshall Morgan > > Internet Doorway, Inc. > http://www.netdoor.com > 601.969.1434 | 800.952.1570 | 601.969.3838 Fax > > 2.5.1 is released? 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 Saturday, June 28, 1997 5:51 PM, Brian [SMTP:signal@shreve.net] wrote: > On Sat, 28 Jun 1997, Marshall Morgan wrote: > > > Before we go through a "painless" install of TCS 2.5.1, we want > > to know if anyone is using it yet and if they have seen any > > "features" or know issues. > > > > Please report as I am sure we all would like to know. > > > > Marshall Morgan > > > > Internet Doorway, Inc. > > http://www.netdoor.com > > 601.969.1434 | 800.952.1570 | 601.969.3838 Fax > > > > > > 2.5.1 is released? > > 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 > > The "totalservice" site says so. Seems as though a USR guy monitoring the list would have announced it though. Marshall Morgan Internet Doorway, Inc. http://www.netdoor.com 601.969.1434 | 800.952.1570 | 601.969.3838 Fax

Looking for any feedback regarding the newly relased 2.51 TC firmware. Does it provide any improvement over 2.50 that would make the upgrading feasable? We have quite afew boxes we would have to upgrade so I want to make certain the upgrade is worth the trouble.... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Rick---* http://www.monmouth.com | Serving the Central Monmouth Internet Engineer | New Jersey Area Operations and Technical Support | Phone: 732-224-8624 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

On Sat, 28 Jun 1997, Rick wrote: > Looking for any feedback regarding the newly relased 2.51 TC firmware. > Does it provide any improvement over 2.50 that would make the upgrading > feasable? We have quite afew boxes we would have to upgrade so I want to > make certain the upgrade is worth the trouble.... > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Rick---* http://www.monmouth.com | Serving the Central > Monmouth Internet Engineer | New Jersey Area > Operations and Technical Support | Phone: 732-224-8624 > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > I am running newer netserver code (3.5.33) which is not the final release version for tcs2.5.1 (that netserver code is 3.5.34), however, i can say Framed-Route works great, and Quake lag is gone. 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, 29 Jun 1997, Brian wrote: > I am running newer netserver code (3.5.33) which is not the final release > version for tcs2.5.1 (that netserver code is 3.5.34), however, i can say > Framed-Route works great, and Quake lag is gone. Are you running PPP in the modems, or in the Netserver? Brian

My understanding is that you can't just run one piece of TCS 2.5.1. Is this correct? What is the proper procedure for upgrading from TCS 2.5 to 2.5.1? The NMC, Netserver, and modems all have to be upgraded. Does this have to be done in any particular order? Brian

Hello Brian Nomally you should upgrade the NMC as the first. That is sometimes very important. You can use most parts without others. So far I found no Configuration, which not worked, exept the wrong NMC version. Important: TCM must be the last version! Otherwise it can happen, that you cannot access some Cards after upgrading. regards Ralf At 11:07 29.06.97 -0500, Brian Elfert wrote: >My understanding is that you can't just run one piece of TCS 2.5.1. Is >this correct? > >What is the proper procedure for upgrading from TCS 2.5 to 2.5.1? > >The NMC, Netserver, and modems all have to be upgraded. Does this have to >be done in any particular order? > >Brian > > > >

On Sun, 29 Jun 1997, Brian Elfert wrote: > > > On Sun, 29 Jun 1997, Brian wrote: > > > I am running newer netserver code (3.5.33) which is not the final release > > version for tcs2.5.1 (that netserver code is 3.5.34), however, i can say > > Framed-Route works great, and Quake lag is gone. > > Are you running PPP in the modems, or in the Netserver? > > Brian > modems, and I am using the old 5.1.7 code, havent upgraded yet 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, 29 Jun 1997, Brian Elfert wrote: > My understanding is that you can't just run one piece of TCS 2.5.1. Is > this correct? > > What is the proper procedure for upgrading from TCS 2.5 to 2.5.1? > > The NMC, Netserver, and modems all have to be upgraded. Does this have to > be done in any particular order? > > Brian > > The USR TCS families are compatible one level deep. So any peice of 2.5.1 should work with 2.5, and if the next version to come out is say 2.6, then it should be compatible with 2.5.1, that is how it works 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, 29 Jun 1997, Rick wrote: > I see that USR now offers Netserver 8/16 Plus units. I also see they > come with Netserver code 4.0. Can someone enlighten me as to what the > PLUS offers over the standard Netserver 16 and also if the 4.0 firmware > can be used in standard Netserver 16's? The Plus units have X2 already loaded. The Netserver/8 Plus is also only 1 RU high instead of the old 2 RU units. I don't know if you can run 4.0 on a old Netserver, but I don't think you'd want to. The big thing about 4.0 is that it is no longer based on Livingston's ComOS. 4.0 appears to me to actually go backwards from the 3.x release for the Netserver/8 and /16. Automatic DNS assignment for Win 95 is not supported, and the RADIUS implementation sends accounting packets to port 1645 instead of 1646 like the RFC calls for. Please note that I've never tried release 4.0. I just looked at the documentation. Brian

I see that USR now offers Netserver 8/16 Plus units. I also see they come with Netserver code 4.0. Can someone enlighten me as to what the PLUS offers over the standard Netserver 16 and also if the 4.0 firmware can be used in standard Netserver 16's? -- Rick

On Sun, 29 Jun 1997, Brian Elfert wrote: > My understanding is that you can't just run one piece of TCS 2.5.1. Is > this correct? > > What is the proper procedure for upgrading from TCS 2.5 to 2.5.1? > > The NMC, Netserver, and modems all have to be upgraded. Does this have to > be done in any particular order? The only thing to remember is, that you should upgrade the NMC first. But that's all.

On Sun, 29 Jun 1997, Brian Elfert wrote: > My understanding is that you can't just run one piece of TCS 2.5.1. Is > this correct? > > What is the proper procedure for upgrading from TCS 2.5 to 2.5.1? > > The NMC, Netserver, and modems all have to be upgraded. Does this have to > be done in any particular order? The only thing to remember is, that you should upgrade the NMC first. But that's all.

Also, I think the false password entry needs to precede the Default entry in the /etc/raddb/users file. Dave Keal On Mon, 30 Jun 1997, Robert Hiltibidal wrote: > Howdy, > > The quick and dirty solution would be to define a an entry in the radius > users file with a false password. This way they could never login via > modem but they could telnet to the box > > Rob > > > On Mon, 30 Jun 1997, Brian wrote: > > > If I am using Unix-PW (/etc/passwd) to authenticate users in my DEFAULT > > entry, and I have a user in the /etc/passwd who I DO NOT want to allow > > access into the nas, but I DO want that user to have a valid shell > > on the Unix machine, how can I deny access to the user? > > > > I thought creating a entry in the users file like: > > > > > > foobar Authentication-Type = None > > > > would work, but it seems like when that fails, it tries DEFAULT, then > > succeeds. Anyone have a "recipe" that will keep users out? > > > > 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 > > > > >

At 10:22 AM 6/30/97 -0500, Brian wrote: >If I am using Unix-PW (/etc/passwd) to authenticate users in my DEFAULT >entry, and I have a user in the /etc/passwd who I DO NOT want to allow >access into the nas, but I DO want that user to have a valid shell >on the Unix machine, how can I deny access to the user? > >I thought creating a entry in the users file like: > > >foobar Authentication-Type = None > >would work, but it seems like when that fails, it tries DEFAULT, then >succeeds. Anyone have a "recipe" that will keep users out? Put a bogus password entry into the radius users file. Instead of having none, just enter one that they will never guess. Not elegant, but it will work. ********************************************************* Justin W. Newton voice: +1-415-482-2840 Senior Network Architect fax: +1-415-482-2844 PRIORI NETWORKS, INC. http://www.priori.net Director At Large, ISP/C http://www.ispc.org "The People You Know. The People You Trust." *********************************************************

Brian: You are nearly correct in your thinking, but need to make one thing different in that entry. You should NOT need to create bogus passwords. Simply add the following line to you users file: foobar Service-Type = None This will not let the person login - it will keep saying invalid login and asking for username password, just like they didn't exist. Ryan C. Braun (Voice) 319-557-8463 Network Systems Engineer (Fax) 319-557-9771 Network Operations Center MidWest Communications, Inc. 241 Main St. noc@mwci.net Dubuque, IA 52001 rbraun@mwci.net On Mon, 30 Jun 1997, Brian wrote: > If I am using Unix-PW (/etc/passwd) to authenticate users in my DEFAULT > entry, and I have a user in the /etc/passwd who I DO NOT want to allow > access into the nas, but I DO want that user to have a valid shell > on the Unix machine, how can I deny access to the user? > > I thought creating a entry in the users file like: > > > foobar Authentication-Type = None > > would work, but it seems like when that fails, it tries DEFAULT, then > succeeds. Anyone have a "recipe" that will keep users out? > > 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 Mon, 30 Jun 1997, Brian wrote: >foobar Authentication-Type = None Should be: foobar Auth-Type = Reject Michael J. Hartwick, VE3SLQ Hartwick Communications Consulting hartwick@primeline.net

On Fri, 27 Jun 1997, Craig Nelson wrote: > I'm new to most of this, and I "thought" I knew the differences between PRI > and chanellized T-1, and I was wondering if you could clarify that last > statement. In what way are PRI's more efficient? I thought both types offer > 23 or 24 incoming lines. PRI's support both analog and ISDN where the other > supports only analog. > Ok, i wont get into the 'gritty' details but here goes. IF I get a # wrong, don't sue me :) This is off my memory and I am by no means a teleco expert for describing this stuff... : PRI provides (23) 64k channels with (1) 16k channel (B channel) that the teleco uses to send/recieve admin info (like line up, incoming call, busy signals etc). Chan t1 provides (24) 56k channels. The Chan t1 uses a process call "rob-bit-signalling" to handle the admin requests on each line (rather than a "B" channel like in PRI), and because of that you can't get the full 56k out of the circuit (usually 53k would be the fastest posisble connection speed. As for the word "effeciency", i think what the first poster meant was that PRI doesnt have any overhead on the 'data' channels and hence more theoretical max throughput for a customer on a 64k PRI channel than on a rob-bit-signalled chan-t1 56k channel. All in all, if you have to have full speed the ONLY way is via PRI, though rummors of a full speed connecton (33.6 or 56) on a chan-t1 has been seen before but is VERY rare. My experience is on chan-t1 you CAN'T acchieve 33.6 or 56k, but consistently get 31.2 and 53.3 connections all the time. Adam Wills Global 2000 Communications Director of Networking Systems 1840 Western Ave. sysadmin@global2000.net Albany, NY, 12203 http://www.global2000.net (518) 452-1465

In message <Pine.LNX.3.95.970630132838.17766M-100000@shell.global2000.net>, "Adam Wills (Global 2000)" writes: > Ok, i wont get into the 'gritty' details but here goes. IF I get a # > wrong, don't sue me :) This is off my memory and I am by no means a > teleco expert for describing this stuff... : No lawsuit. But it does seem to repeat errors that others have made, so I do feel compelled to correct them. Hope that doesn't offend too much. > PRI provides (23) 64k channels with (1) 16k channel (B channel) that the > teleco uses to send/recieve admin info (like line up, incoming call, busy > signals etc). Nope. T1-based PRI is 23 64K B channels plus one 64K D channel when used over a B8ZS line. The D channel does indeed do the call signaling using Q.931 protocol over Q.921 (LAP-D). It's basically an HDLC channel. Note that T1-based PRI can also run over an AMI line, in which case you get only 56K in those B channels unless you run inverted HDLC. As far as I know, PRI lines aren't normally provisioned that way, but it is part of the ANSI PRI standards. > Chan t1 provides (24) 56k channels. The Chan t1 uses a process call > "rob-bit-signalling" to handle the admin requests on each line (rather > than a "B" channel like in PRI), and because of that you can't get the > full 56k out of the circuit (usually 53k would be the fastest posisble > connection speed. Nope. Bit-robbed signaling leaves you with EXACTLY 56000bps in each of 24 channels -- 7 bits out of an 8 bit sample at a rate of 8000 samples per second. That "53K" number you may have heard may have to do with using X2 modems and limiting CO crosstalk due to FCC rules. It certainly has nothing to do with real digital connections. Channelized T1 using CCS instead of bit-robbed signaling gives 64000bps instead of 56K. Note that K is 1000 in the telco world, not 1024. > My experience is on chan-t1 you CAN'T acchieve 33.6 or 56k, but > consistently get 31.2 and 53.3 connections all the time. 33.6Kbps on V.34+ relies on a 36dB SNR, which is very near the theoretic maximum of 37dB. That's why it's tough to get. --- James Carlson <carlson@xylogics.com>, Prin Engr Tel: +1 508 916 4351 Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317 Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789 Keep an eye out for my PPP design and debug book from Addison-Wesley. (Available early 1998.)

At 7:31 PM -0500 6/29/97, Brian Elfert wrote: >On Sun, 29 Jun 1997, Rick wrote: > >> I see that USR now offers Netserver 8/16 Plus units. I also see they >> come with Netserver code 4.0. Can someone enlighten me as to what the >> PLUS offers over the standard Netserver 16 and also if the 4.0 firmware >> can be used in standard Netserver 16's? > >The Plus units have X2 already loaded. The Netserver/8 Plus is also only >1 RU high instead of the old 2 RU units. > >I don't know if you can run 4.0 on a old Netserver, but I don't think >you'd want to. I was cruising around on the TotalService web page the other day and noticed the Netserver Plus software available there. Since we have a few Netserver/16s lying around waiting to be used, I loaded it onto one of them and investigated. The old Netserver 8/16s are definitely upgradeable, although the process is a little complex. You have to fiddle with the dip switches on the back to set the console port speed to 57600 and physically power off the Netserver at one point. It's also impossible to upgrade boxes over a network (have to have a serial connection) which means it will be a real pain to upgrade boxes at remote POPs. >The big thing about 4.0 is that it is no longer based on Livingston's >ComOS. 4.0 appears to me to actually go backwards from the 3.x release >for the Netserver/8 and /16. I'm also a bit disappointed in the 4.0 release. The old ComOS-based interface seemed a lot more intuitive to use (although this could be more due to my familiarity with ComOS rather than for any substantive reason) and I can't seem to find a comprable command to useful commands like 'show sessions'. (There's a 'list connections' command that is vaguely similar, but without some of the useful information). The functionality of the new software seems comprable to the 3.5 software, or even a little enhanced (we can do more useful things via radius, for example. The new software supports AppleTalk, although that's not a feature we'll be using anytime soon. RIP v2 is added and SNMP support is expanded. But I'm still trying to work my way through the difference in interface... >Automatic DNS assignment for Win 95 is not supported, and the RADIUS >implementation sends accounting packets to port 1645 instead of 1646 like >the RFC calls for. Did 3.5 support automatic DNS assignment? I certainly never got it to work if it did... There are some problems in the old Netserver OS (like idle timeouts not working) that appear to be corrected in the new software, and some of the features may end up being useful enough to motivate us to migrate to the 4.0 software. However, I'm really disappointed with the new interface and am starting to look at Livingston products again. ComOS is really nice, and these days it has so many more features than the Netservers support... Jordyn |----------------------------------------------------------------| |Jordyn A. Buchanan mailto:jordyn@bestweb.net | |Bestweb Corporation http://www.bestweb.net | |Senior System Administrator +1.914.271.4500 | |----------------------------------------------------------------|