January 2000

Subject: Re: (usr-tc) 3COM/USR non hiper questions/ Problems......
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-03 09:18:54

Addressing only Item 2: The NMC might get hung if there are long broadcast storms on you local network, requiring a physical reset. The NMC should have NO affect on user's connections or throughputs, but a network problem that affected the NMC may also be afffecting the users. If you have a sniffer, or netmon you might want to monitor when this happens to see if this is the case. Steve William M Sheeler Sr <tcra@talon.net> on 01/03/2000 08:42:13 AM Please respond to usr-tc@lists.xmission.com Sent by: William M Sheeler Sr <tcra@talon.net> cc: (Steve Valiunas/MW/US/3Com) Hi: I've been going crazy trying to figure this out, so I am now asking for some help. I have 3COM/USR 2059 bundles (yep still running). There are a couple of strange problems. 1. Sometimes a modem card goes red lite on a modem, and a software reset won't work and I have to pull the card and reseat it. When this happens callers can not consistently connect. They get messages saying that the number is blocked, or not available, or even a busy signal. They are configured roundrobin as I was told to do 3 years ago. Sometimes people get past, other times not. Bad thing is that this usually happens on the 1st rack and really causes havoc, and I don't know what to do, how to stop it or just how to watch it so that if and when it happens, something pages us to let us know. Thing is, how do you check for an error message on a phone line? 2. Sometimes the NMC card goes red, and won't take a software reset either, and needs a hard pull to reboot it. This causes issues with slow or no logins (hangs on password authentication using Lucent Radius), and or not being able to go to any sites. 3. We are also having problems with disconnects, and long retrains, etc., and what appears to be noise on the lines, but we are on a fiber OC-3 ring for our PRIs, so where is noise being generated? People are getting low connect speeds, tons of retrains, and I noticed a lot of Bipolar violations (400+ in less than 24hours), code violation error events, errored seconds, etc., across multiple PRIs using the TCM performance monitor. HELP.... This is driving me crazy. Customers are getting too many disconnects, slow connects, retrains, etc, and this did not happen before. It is almost like the telco (not BA but a CLEC) has problems with the B8ZS line encoding, but there is no one with clues there that can figure it out. Also, how can I set cause codes in the PRIs so that the Telco switch knows when there is a modem problem and can move around that modem? Am I on the right track or blowing smoke. HELP Frustrated in PA. Bill their configurations are as follows: Card hrdware ver sware ver dram flash Dual PRI card 4.0.0 3.0.2 4096 1024 Quad Digital Modems 3.0.0 5.10.9 Quad Analog/Digital Modems 3.0.0 5.10.9 Netserver card 7.0.0 3.7.24 20480 2048 NMC card 3.0 5.4.1 4096 2048 Dual 45 watt PS, no service contract. Using Windows TCM 5.5.1 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) 3COM/USR non hiper questions/ Problems......
From: William M Sheeler Sr <tcra@talon.net>
Date: 2000-01-03 09:42:13

Hi: I've been going crazy trying to figure this out, so I am now asking for some help. I have 3COM/USR 2059 bundles (yep still running). There are a couple of strange problems. 1. Sometimes a modem card goes red lite on a modem, and a software reset won't work and I have to pull the card and reseat it. When this happens callers can not consistently connect. They get messages saying that the number is blocked, or not available, or even a busy signal. They are configured roundrobin as I was told to do 3 years ago. Sometimes people get past, other times not. Bad thing is that this usually happens on the 1st rack and really causes havoc, and I don't know what to do, how to stop it or just how to watch it so that if and when it happens, something pages us to let us know. Thing is, how do you check for an error message on a phone line? 2. Sometimes the NMC card goes red, and won't take a software reset either, and needs a hard pull to reboot it. This causes issues with slow or no logins (hangs on password authentication using Lucent Radius), and or not being able to go to any sites. 3. We are also having problems with disconnects, and long retrains, etc., and what appears to be noise on the lines, but we are on a fiber OC-3 ring for our PRIs, so where is noise being generated? People are getting low connect speeds, tons of retrains, and I noticed a lot of Bipolar violations (400+ in less than 24hours), code violation error events, errored seconds, etc., across multiple PRIs using the TCM performance monitor. HELP.... This is driving me crazy. Customers are getting too many disconnects, slow connects, retrains, etc, and this did not happen before. It is almost like the telco (not BA but a CLEC) has problems with the B8ZS line encoding, but there is no one with clues there that can figure it out. Also, how can I set cause codes in the PRIs so that the Telco switch knows when there is a modem problem and can move around that modem? Am I on the right track or blowing smoke. HELP Frustrated in PA. Bill their configurations are as follows: Card hrdware ver sware ver dram flash Dual PRI card 4.0.0 3.0.2 4096 1024 Quad Digital Modems 3.0.0 5.10.9 Quad Analog/Digital Modems 3.0.0 5.10.9 Netserver card 7.0.0 3.7.24 20480 2048 NMC card 3.0 5.4.1 4096 2048 Dual 45 watt PS, no service contract. Using Windows TCM 5.5.1

Subject: (usr-tc) TC call Barring or something
From: bert.f@pacific.net.ph
Date: 2000-01-03 09:58:14

Hi! I just want to know if the TC is capable of blocking a certain telephone number? Thanks. Bert

Subject: Re: (usr-tc) 3COM/USR non hiper questions/ Problems......
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-03 10:22:32

Thus spake William M Sheeler Sr >I have 3COM/USR 2059 bundles (yep still running). Bah...quads...not that old...we've got dual's with 35Amp power supplies still running. ;) >1. Sometimes a modem card goes red lite on a modem, and a software >reset won't work and I have to pull the card and reseat it. When this >happens callers can not consistently connect. They get messages saying >that the number is blocked, or not available, or even a busy signal. >They are configured roundrobin as I was told to do 3 years ago. >Sometimes people get past, other times not. Bad thing is that this >usually happens on the 1st rack and really causes havoc, and I don't >know what to do, how to stop it or just how to watch it so that if and >when it happens, something pages us to let us know. Thing is, how do >you check for an error message on a phone line? Sometimes quads do just loose it...we have that happen occasionally around here...a "hard reset" from TCM should revive them without requiring a full reseat of the card (a life-saver if its at a remote POP :). To get the hard reset (note, this will reset the whole card, not just that one modem), select the card rather than the modem and go to actions. >2. Sometimes the NMC card goes red, and won't take a software reset >either, and needs a hard pull to reboot it. This causes issues with >slow or no logins (hangs on password authentication using Lucent >Radius), and or not being able to go to any sites. Not sure about the NMC...haven't run into that. If its the hub status light, it could be other things that are causing it to go red...though since it doesn't take a soft reset, its seems there really might be a problem with the NMC. For example, a power supply problem will be indicated by a red hub status light on the NMC...there is an SNMP OID somewhere (and I can't remember where off the top of my head) that will tell you the reason for the hub status light being red...this assumes that the NMC itself is actually healthy enough to respond. >3. We are also having problems with disconnects, and long retrains, >etc., and what appears to be noise on the lines, but we are on a fiber >OC-3 ring for our PRIs, so where is noise being generated? Well...its possible that its on the customer's end...their analog loop...but if its widespread, that casts some doubt on that...as does the information below. >People are getting low connect speeds, tons of retrains, and I noticed >a lot of Bipolar violations (400+ in less than 24hours), code violation >error events, errored seconds, etc., across multiple PRIs using the >TCM performance monitor. You need to scream and yell at the telco to get someone clueful on the line. If you can get a PRI cleared off, do so and have them run some test patterns at a loop on it...they will almost assuredly find that something there is misprovisioned...quite possibly a mux (DDM-2000's are commonly a culprit here) will be provisioned as AMI rather than B8ZS (apparently DDM-2000's default to AMI rather than B8ZS...why? I don't know...they can be set in software, but will revert to AMI on its next reset if the hardware switch isn't set on it). Having something like that set to AMI when the circuit is supposed to be running B8ZS (and everything else is running B8ZS) will result in at least BPV's...likely other problems as well. I've generally found that on a circuit misprovisioned like this you can get the D channel up (at least temporarily), but will be unable to bring up the B's. If the circuit is already up...all bets are off as to what will happen. You might want to particularly insist that they run an "all-zero's" pattern as that will definitely catch AMI/B8ZS misprovisioning. >HELP.... This is driving me crazy. Customers are getting too many >disconnects, slow connects, retrains, etc, and this did not happen >before. It is almost like the telco (not BA but a CLEC) has problems >with the B8ZS line encoding, but there is no one with clues there that >can figure it out. You've got to find someone there with clue...you will not get this resolved any other way if its a misprovisioning problem at the telco (and based on your description, it almost assuredly is) >Also, how can I set cause codes in the PRIs so that the Telco switch knows >when there is a modem problem and can move around that modem? Am I on the >right track or blowing smoke. Cause codes don't do anything to cause the switch to skip a modem...they just change what indication is returned to the dialing user when a problem is seen. Cause code 17 is a normal user busy...anything else will likely generate some sort of reorder tone/reorder message/fast busy for the user...which would be appropriate in this case as the circuit is hosed. You might see if the telco can go to a round-robin hunt on their system (we did this recently), and you go to fixed assignment...then you could use auto-response to detect when a modem has gone south and busy out the ds0 on the PRI. This also requires that you not be using the brain-damaged NI-2 (National) translation on the PRI as whoever came up with that protocol was dain bramaged enough to *not* put in service messages in it. Good luck...feel free to followup with requests for clarification in any of this...I've tried to make it clear...but I don't always do too well at that. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) TSmon
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-03 11:48:15

I know a lot you are using tsmon, does anyone else have trouble with tsmon reading the times right off the Arcs?

Subject: Re: (usr-tc) Setting T1 trunk settings through CLI on ARC
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-03 12:11:48

Involved process it is...been working on getting this to work on a test box. This may be a handy feature at certain times. Thanks for the info anyways. ----- Original Message ----- Sent: Saturday, January 01, 2000 4:13 PM > > You can't do it through the HiPerARC CLI per se but you can set up the ARC > to allow you access to the DSPs' CLI through reverse telnet. It's quite an > involved process and I can't remember exactly how it goes but there's an > article about it at 3KB that details the procedure. > > > -----Original Message----- > > From: Cheryl Johnson [SMTP:netadmin@seidata.com] > > Sent: Saturday, January 01, 2000 2:05 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Setting T1 trunk settings through CLI on ARC > > > > Curious if anyone knows a way to configure the trunk settings through the > > HiPerARC for a particular DSP card. Seem we lost contact with the NMC and > > it set back the trunk settings to default <ami/sf>. If anyone know how > > this may be done, please fill me in. > > > > Thanks > > -Cheryl > > Seidata, Inc. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 3COM/USR non hiper questions/ Problems......
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-03 12:34:02

What version of software are you running on the modems, nmc and netserver units? We occasionally see a red light on the modems but nothing we have to hard reset. We have been running 5.10.9 on the modems and I have recently been upgrading them to 6.1.6 (all of ours are single sided). I have one chassis that refuses to flash on any of the modems. We have two chassis sitting side by side and identical from what I can see. The first one flashed just fine and all of the 2nd's modems give me a pending, then time out. Wish I could get them done and I can't figure out the problem with them. >There are a couple of strange problems. > >1. Sometimes a modem card goes red lite on a modem, and a software > reset won't work and I have to pull the card and reseat it. When > this happens > callers can not consistently connect. They get messages saying > that the number > is blocked, or not available, or even a busy signal. They are > configured roundrobin > as I was told to do 3 years ago. Sometimes people get past, > other times not. Bad > thing is that this usually happens on the 1st rack and really > causes havoc, and I don't > know what to do, how to stop it or just how to watch it so that > if and when it happens, > something pages us to let us know. Thing is, how do you check > for an error message > on a phone line? > >2. Sometimes the NMC card goes red, and won't take a software reset >either, and needs > a hard pull to reboot it. This causes issues with slow or no > logins (hangs on password > authentication using Lucent Radius), and or not being able to go > to any sites. > >3. We are also having problems with disconnects, and long retrains, >etc., and what appears to be noise on the lines, but we are on a >fiber OC-3 ring for our PRIs, so where is noise being > generated? People are getting low connect speeds, tons of > retrains, and I noticed a lot of > Bipolar violations (400+ in less than 24hours), code violation > error events, errored seconds, etc., across multiple PRIs using the TCM > performance monitor. > >HELP.... This is driving me crazy. Customers are getting too many >disconnects, slow connects, retrains, etc, and this did not happen >before. It is almost like the telco (not BA but a CLEC) has problems with >the B8ZS line encoding, but there is no one with clues there that can >figure it out. > >Also, how can I set cause codes in the PRIs so that the Telco switch knows >when there is a modem problem and can move around that modem? Am I on the >right track or blowing smoke. > >HELP > >Frustrated in PA. > > >Bill > > > >their configurations are as follows: > >Card hrdware ver sware >ver dram flash >--------------------------------------------------------------------------- >- ----------------------------- >Dual PRI card 4.0.0 3.0.2 4096 1024 >Quad Digital Modems 3.0.0 5.10.9 >Quad Analog/Digital Modems 3.0.0 5.10.9 >Netserver card 7.0.0 3.7.24 20480 2048 >NMC >card 3.0 5.4.1 4096 > 2048 >Dual 45 watt PS, no service contract. Using Windows TCM 5.5.1 > > > >- >To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >with "unsubscribe usr-tc" in the body of the message. >For information on digests or retrieving files and old messages send >"help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) TSmon
From: pferraro@wna-linknet.com
Date: 2000-01-03 15:42:13

YES we do! Had to shut it down... All clients were being logged out because they were all over the time limit! Seems it has a problem with subtraction and the new 2000 date. I have already sent 2 messages to the software editor and programmer, but have yet to hear back from him... If any of you are using the product, you should send them email! I hate to see $600.00 go down the tube! Send it to mailto:thrasher@tsmon.com Hope he corrects it quickly! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Mon, 3 Jan 2000, Terry Kennedy wrote: > I know a lot you are using tsmon, does anyone else have trouble > with tsmon reading the times right off the Arcs? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TSmon
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-03 15:55:46

Thus spake pferraro@wna-linknet.com > YES we do! Had to shut it down... All clients were being logged >out because they were all over the time limit! Seems it has a problem >with subtraction and the new 2000 date. I have already sent 2 messages >to the software editor and programmer, but have yet to hear back from >him... If any of you are using the product, you should send them >email! I hate to see $600.00 go down the tube! At the risk of serious flamage...I think this goes down as an example of the danger of telnet base scripted actions. Like I said last time around...parsing problems will end up biting you in the end. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Caller ID Question
From: Pete Ashdown <pashdown@xmission.com>
Date: 2000-01-03 16:06:57

* bert.f@pacific.net.ph (bert.f@pacific.net.ph) [991230 12:20] writeth: >Is there a command line that will display the CALLER ID of the user? Nope. You have to either pull this information with SNMP via the NMC, or via RADIUS accounting.

Subject: Re: (usr-tc) S/A Server is crashing
From: Jim Faulkner <jlf@montrose-colo.com>
Date: 2000-01-03 17:03:41

I had the exact same problem with version 5.5.3. It would run great for months and the crash several times on three servers simultaneously. I was never ever able to find a cause. I got a copy of ServersAlive which would monitor the radius server and then kill Dr Watson when there was a crash and restart the Radius server. Very messy but it got me by. I've since installed a 6.0 version and haven't seen the problem again but it's only been about three weeks so I'm still holding my breath. Jim GWE.NET ----- Original Message ----- Sent: Monday, January 03, 2000 3:05 PM > Hello, > > I've been running the Total Control Security and Accounting Server for > what seems like forever with no problems whatsoever. Suddenly for no > apparent reason it has started crashing. There is no regularity to when > the crashes occur, and the exceptions happen at a variety of addresses. > Has anybody else seen this type of behaviour? Or does anyone have any > ideas on what may have happened? The software has been installed now on > a new machine with a fresh installation of NT, all the updates > installed, the only thing that the old server and the new have in common > is the .mdb database file. The new server crashes with the same > errors. sigh. > > Eric > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) S/A Server is crashing
From: Eric Ryoti <eryoti@cinetwork.com>
Date: 2000-01-03 17:05:59

Hello, I've been running the Total Control Security and Accounting Server for what seems like forever with no problems whatsoever. Suddenly for no apparent reason it has started crashing. There is no regularity to when the crashes occur, and the exceptions happen at a variety of addresses. Has anybody else seen this type of behaviour? Or does anyone have any ideas on what may have happened? The software has been installed now on a new machine with a fresh installation of NT, all the updates installed, the only thing that the old server and the new have in common is the .mdb database file. The new server crashes with the same errors. sigh. Eric

Subject: (usr-tc) Total Control Enterprise Network Hub
From: Greg Long <greg@coastlink.com>
Date: 2000-01-03 17:57:32

Hello! I've got a Total Control Enterprise Network Hub that has a red "Hub Status" light on the Network Management Card. I tried doing a software reset and shutting it down and powering it back on but the light pops back to red after about 30 seconds. I can't find anything wrong with it, it is still sending and receiving information. My callers haven't complained about low bandwidth or inability to do anything. According to the manual it is a Critical Chassis Failure. What do I need to do to the box to make the green light come back? Any help would be greatly appreciated! Thanks, Greg Long Tech Support Coastlink 801-532-6212 ext 32 techsupp@coastlink.com http://www.coastlink.com

Subject: Re: (usr-tc) Caller ID Question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-03 18:36:44

Depends on the version of hiper arc code you are using, and if theuser is currently logged on - if the user is logged on you could issue this command to look at DNIS numbers list dnis_connection krish On Mon, 3 Jan 2000, Pete Ashdown wrote: > * bert.f@pacific.net.ph (bert.f@pacific.net.ph) [991230 12:20] writeth: > >Is there a command line that will display the CALLER ID of the user? > > Nope. You have to either pull this information with SNMP via the NMC, or > via RADIUS accounting. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Caller ID Question
From: Marshall Morgan <marshall@netdoor.com>
Date: 2000-01-03 18:57:45

Krish, I think the guy wants ANI (Calling Number) not DNIS (Called Number) info. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Monday, January 03, 2000 6:37 PM > To: Pete Ashdown > Cc: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Caller ID Question > > > Depends on the version of hiper arc code you are using, and if theuser is > currently logged on - if the user is logged on you could issue this > command to look at DNIS numbers > > list dnis_connection > > > krish > > On Mon, 3 Jan 2000, Pete Ashdown wrote: > > > * bert.f@pacific.net.ph (bert.f@pacific.net.ph) [991230 12:20] writeth: > > >Is there a command line that will display the CALLER ID of the user? > > > > Nope. You have to either pull this information with SNMP via the NMC, or > > via RADIUS accounting. > >

Subject: RE: (usr-tc) Total Control Enterprise Network Hub
From: Blake Fithen <fithen@networksplus.com>
Date: 2000-01-03 19:35:40

Make sure all the fans are spinning. blake > -----Original Message----- > From: Greg Long [mailto:greg@coastlink.com] > Sent: Monday, January 03, 2000 6:58 PM > To: usr-tc@xmission.com > Subject: (usr-tc) Total Control Enterprise Network Hub > > > Hello! > > I've got a Total Control Enterprise Network Hub that has a > red "Hub Status" > light on the Network Management Card. I tried doing a > software reset and > shutting it down and powering it back on but the light pops > back to red > after about 30 seconds. I can't find anything wrong with it, > it is still > sending and receiving information. My callers haven't > complained about low > bandwidth or inability to do anything. According to the > manual it is a > Critical Chassis Failure. What do I need to do to the box to > make the green > light come back? Any help would be greatly appreciated! > > Thanks, > Greg Long > Tech Support > Coastlink > 801-532-6212 ext 32 > techsupp@coastlink.com > http://www.coastlink.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Total Control Enterprise Network Hub
From: Blake Fithen <fithen@networksplus.com>
Date: 2000-01-03 19:35:40

Subject: RE: (usr-tc) Caller ID Question
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-03 20:02:00

Try it. It gives you both. (Useful stuff; wish I'd known about that before..) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." On Mon, 3 Jan 2000, Marshall Morgan wrote: > Krish, > > I think the guy wants ANI (Calling Number) not DNIS (Called Number) info. > > Marshall Morgan > > Internet Doorway, Inc (aka NETDOOR) > http://www.netdoor.com > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Monday, January 03, 2000 6:37 PM > > To: Pete Ashdown > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Caller ID Question > > > > > > Depends on the version of hiper arc code you are using, and if theuser is > > currently logged on - if the user is logged on you could issue this > > command to look at DNIS numbers > > > > list dnis_connection > > > > > > krish > > > > On Mon, 3 Jan 2000, Pete Ashdown wrote: > > > > > * bert.f@pacific.net.ph (bert.f@pacific.net.ph) [991230 12:20] writeth: > > > >Is there a command line that will display the CALLER ID of the user? > > > > > > Nope. You have to either pull this information with SNMP via the NMC, or > > > via RADIUS accounting. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Total Control Enterprise Network Hub
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-03 21:19:31

Thus spake Greg Long >I've got a Total Control Enterprise Network Hub that has a red "Hub >Status" light on the Network Management Card. I tried doing a software >reset and shutting it down and powering it back on but the light pops >back to red after about 30 seconds. I can't find anything wrong with >it, it is still sending and receiving information. My callers haven't >complained about low bandwidth or inability to do anything. According >to the manual it is a Critical Chassis Failure. What do I need to do >to the box to make the green light come back? Any help would be >greatly appreciated! Could be a faulty fan in the fan tray or faulty power supply. Walk the uchasPowerSupplyTable for information about the power supplies, and, unfortunately, it seems that there is no OID to find out about fan failures...3Com, is there a possibility that this can be added? Obviously, they are instrumented as you can get traps on fan failures and auto-response scripts for fan failures... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Caller ID Question
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-03 21:25:46

This command displays both ani and dnis looks something like this joeuser 168890937 149.112.154.110 slot:11/mod:18 7299236 846469 krish On Mon, 3 Jan 2000, Marshall Morgan wrote: > Krish, > > I think the guy wants ANI (Calling Number) not DNIS (Called Number) info. > > Marshall Morgan > > Internet Doorway, Inc (aka NETDOOR) > http://www.netdoor.com > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > > Sent: Monday, January 03, 2000 6:37 PM > > To: Pete Ashdown > > Cc: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Caller ID Question > > > > > > Depends on the version of hiper arc code you are using, and if theuser is > > currently logged on - if the user is logged on you could issue this > > command to look at DNIS numbers > > > > list dnis_connection > > > > > > krish > > > > On Mon, 3 Jan 2000, Pete Ashdown wrote: > > > > > * bert.f@pacific.net.ph (bert.f@pacific.net.ph) [991230 12:20] writeth: > > > >Is there a command line that will display the CALLER ID of the user? > > > > > > Nope. You have to either pull this information with SNMP via the NMC, or > > > via RADIUS accounting. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TSmon
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-03 22:06:41

On Mon, 3 Jan 2000, Jeff Mcadams wrote: > At the risk of serious flamage...I think this goes down as an example of > the danger of telnet base scripted actions. Like I said last time > around...parsing problems will end up biting you in the end. :/ Indeed. What starts as a quick and simple winds up not so quick or simple. But I've recently been playing around with doing various monitoring and check tasks.....am having a good bit of fun with perl, SNMP.pl, and CGI.pl. *grin*

Subject: Re: (usr-tc) Total Control Enterprise Network Hub
From: Stephen Amadei <amadei@dandy.net>
Date: 2000-01-03 22:35:01

On Mon, 3 Jan 2000, Jeff Mcadams wrote: > Walk the uchasPowerSupplyTable for information about the power supplies, > and, unfortunately, it seems that there is no OID to find out about fan > failures...3Com, is there a possibility that this can be added? > Obviously, they are instrumented as you can get traps on fan failures > and auto-response scripts for fan failures... Aren't the fans in the fantray two wire? I don't think two wire fans can be tested for failure, like the new three wire PC chassis and CPU fans. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Subject: RE: (usr-tc) Caller ID Question
From: Marshall Morgan <marshall@netdoor.com>
Date: 2000-01-03 23:21:37

We are not running a version of the ARC that supports that but sounds like a great deal. Anyone know the SNMP OID's for that? Marshall Morgan Internet Doorway, Inc. (aka NETDOOR) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tatai SV Krishnan > Sent: Monday, January 03, 2000 9:26 PM > To: Marshall Morgan > Cc: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Caller ID Question > > > This command displays both ani and dnis looks something like this > joeuser 168890937 149.112.154.110 slot:11/mod:18 7299236 > 846469 > > > krish

Subject: (usr-tc) Problems with fast busy on Hiper DSP's
From: Clint R. Sparks <csparks@cqc.com>
Date: 2000-01-04 00:13:11

Hello, We are having problems with a fast busy situation on a Total Control using Hiper DSP cards using 2.0.81 on the first three Hiper DSP's and 2.0.51 on the last two (this was to test the new code) and a Hiper ARC card using 4.1.59-6. We use PRI lines 23 B's and 1 D per PRI line in Ameritech area who uses a 5ess switch. We had four Hiper DSP cards and added a fifth one Friday, since then we have had a problem where the TC can only take 92 connections instead of 115, once 92 modems are filled up anyone calling in gets a fast busy signal, the 92 connections can even span across all five Hiper DSP cards but once it gets to 92 a fast busy. We have checked all the Hiper ARC settings against another Total Control chassis we have with more cards and all the settings look right, we have rebooted the Hiper ARC and the Hiper DSP's but this has not helped. Ameritech has checked and all the B channels and D channels are up and provisioned properly. We can't help thinking that we have missed something, any help or ideas would be greatly appreciated. Thank you, Clint R. Sparks ComQuest Internet Services csparks@cqc.com

Subject: (usr-tc) Motorola SM56 modems
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-04 00:25:21

Anyone had any problems with Motorola SM56 modems? I ran into one person a while back that had a hell of a lot of problems with one, which went away when he got a Sportster... apparently Motorola didn't have any newer drivers (and yes it's a Winmodem). But in the last 4 days -- 3 of which we've been running 2.0.51 code on a mix of hardware revs 49, 53, and 54 -- we've had a sharp increase in the number of people having disconnects with these things. One of them was in a brand new Gateway computer, so I fear that they may have switched modem vendors yet again, and with Christmas having just come, that might be the source of lots of them. (ugh) So at this point I can't tell if it's that or if it's the 2.0.51 code causing the problem. I would rather be running 2.0.51 because I've got five DSP's on order and they're likely to be a newer hardware rev, and I'd rather run the same code across the board... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear."

Subject: RE: (usr-tc) Problems with fast busy on Hiper DSP's
From: System Administrator <sysadmin@nebi.com>
Date: 2000-01-04 07:15:11

I don't work with PRI's here, but it almost looks like you added trunks and forgot to increase the IP pool. Do a "list ip pool" and make sure the total count is at least 115. HTH, Justin -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Clint R. Sparks Sent: Monday, January 03, 2000 11:13 PM Hello, We are having problems with a fast busy situation on a Total Control using Hiper DSP cards using 2.0.81 on the first three Hiper DSP's and 2.0.51 on the last two (this was to test the new code) and a Hiper ARC card using 4.1.59-6. We use PRI lines 23 B's and 1 D per PRI line in Ameritech area who uses a 5ess switch. We had four Hiper DSP cards and added a fifth one Friday, since then we have had a problem where the TC can only take 92 connections instead of 115, once 92 modems are filled up anyone calling in gets a fast busy signal, the 92 connections can even span across all five Hiper DSP cards but once it gets to 92 a fast busy. We have checked all the Hiper ARC settings against another Total Control chassis we have with more cards and all the settings look right, we have rebooted the Hiper ARC and the Hiper DSP's but this has not helped. Ameritech has checked and all the B channels and D channels are up and provisioned properly. We can't help thinking that we have missed something, any help or ideas would be greatly appreciated. Thank you, Clint R. Sparks ComQuest Internet Services csparks@cqc.com - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Total Control Enterprise Network Hub
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-04 07:59:42

Thus spake Stephen Amadei >On Mon, 3 Jan 2000, Jeff Mcadams wrote: >> Walk the uchasPowerSupplyTable for information about the power supplies, >> and, unfortunately, it seems that there is no OID to find out about fan >> failures...3Com, is there a possibility that this can be added? >> Obviously, they are instrumented as you can get traps on fan failures >> and auto-response scripts for fan failures... >Aren't the fans in the fantray two wire? I don't think two wire fans >can be tested for failure, like the new three wire PC chassis and CPU >fans. Dunno...haven't checked that closely...but I do know that there is a trap enable for fan failures, as well as an auto-response script, so I'm pretty sure they are instrumented. I'll pull a fan tray to see if I can tell if I think about it today. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Motorola SM56 modems
From: Mark E. Levy <mark@fsi.net>
Date: 2000-01-04 08:09:49

I have a user (also with a brand new Gateway) having similiar problems with this modem. They connect at no better than 21K. We're running 2.0.19 & 4.1.59-6. Mike Andrews wrote: > Anyone had any problems with Motorola SM56 modems? I ran into one person > a while back that had a hell of a lot of problems with one, which went > away when he got a Sportster... apparently Motorola didn't have any newer > drivers (and yes it's a Winmodem). But in the last 4 days -- 3 of which > we've been running 2.0.51 code on a mix of hardware revs 49, 53, and 54 -- > we've had a sharp increase in the number of people having disconnects with > these things. One of them was in a brand new Gateway computer, so I fear > that they may have switched modem vendors yet again, and with Christmas > having just come, that might be the source of lots of them. (ugh) So at > this point I can't tell if it's that or if it's the 2.0.51 code causing > the problem. I would rather be running 2.0.51 because I've got five DSP's > on order and they're likely to be a newer hardware rev, and I'd rather > run the same code across the board... > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville > "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.net

Subject: Re: (usr-tc) Total Control Enterprise Network Hub
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-04 08:29:43

The NMC can be queried to tell you the reason for the Hub-Status light being red- It's under Performance Monitor / FuncGroup=FailureReasons / Parm=HubStatusRed. This is available on TCS3.5 and later codes (nmc ver 6.x.x). It might be a high temperature, a card being reset, some kind of non-critical failure on the NMC, a bad PSU... The oldstyle chassis with the fan in the back has a sensor for the single fan, and the newer-style chassis with the built-in fan tray will report failures for the tray. You probably won't get anything for the older add-on fan tray though. Steve valiunas Jeff Mcadams <jeffm@iglou.com> on 01/04/2000 06:59:42 AM Please respond to usr-tc@lists.xmission.com Sent by: Jeff Mcadams <jeffm@iglou.com> cc: (Steve Valiunas/MW/US/3Com) Thus spake Stephen Amadei >On Mon, 3 Jan 2000, Jeff Mcadams wrote: >> Walk the uchasPowerSupplyTable for information about the power supplies, >> and, unfortunately, it seems that there is no OID to find out about fan >> failures...3Com, is there a possibility that this can be added? >> Obviously, they are instrumented as you can get traps on fan failures >> and auto-response scripts for fan failures... >Aren't the fans in the fantray two wire? I don't think two wire fans >can be tested for failure, like the new three wire PC chassis and CPU >fans. Dunno...haven't checked that closely...but I do know that there is a trap enable for fan failures, as well as an auto-response script, so I'm pretty sure they are instrumented. I'll pull a fan tray to see if I can tell if I think about it today. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) PCSDL, is there some sort of trick to this?
From: D A Substanley <das@gol.com>
Date: 2000-01-04 09:07:41

Hi Tom, Thanks for the follow-up. I've got it working know. Wrong files in wrong places as everyone expected. I knew that it had to be something simple as the instructions were straightforward. Thanks to all who responded. das Tom Collins (Tom_Collins@mw.3com.com) spake: > > > Are you issuing this command within the same directory as the .nac and .sdl > files? > > the application pcsdl and the .nac & .sdl files need to be in the same folder. > > > > > > > Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> on 12/21/99 10:21:34 AM > > Please respond to usr-tc@lists.xmission.com > > Sent by: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > To: das <das@gol.com> > cc: usr-tc@lists.xmission.com (Tom Collins/MW/US/3Com) > Subject: Re: (usr-tc) PCSDL, is there some sort of trick to this? > > > > > On Wed, 22 Dec 1999, das wrote: > > > I've read all of the documentation. I've now got some remote NMCs that > > have become unreachable via TCM. I figure that I need to go there and > > reflash them via PCSDL. I've never had to do this before, so I did my > > homework. This is what I'm typing: > > > > pcsdl -p1 -r9600 -vsd5.4.1 -vna5.2.2 -nsdnm -nnanm > > > > This should be all you need correct? It keeps giving me the following > > error message: > > > > Error: No such file or directory. > > This error refers to the sdl and the nac file. What it says here is that > you do not have a either a sdl file named nm050401.sdl or you do not have > a nm05050202.nac file. Check the file names > > krish > > > > > So, I tried using the -d flag to specify C:\usr_sdl . But, that didn't > > seem to have any affect. > > > > Any ideas? I don't want to have to go all the way out there tomorrow > > without any way to bring these cards up. > > > > TIA, > > > > das > > > > -- > > ____________________________________________ > > Alex Substanley Global OnLine Japan > > Engineering Department > > Das Man TEL: 81-3-5334-1700 > > Systems Engineer FAX: 81-3-5334-1711 > > The Highest Quality Service, Bar None > > ____________________________________________ > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Total Control Enterprise Network Hub
From: Greg Long <greg@coastlink.com>
Date: 2000-01-04 09:21:12

Hey thanks! That was the problem. Temp still looks good. I have two fans in the room to keep the air moving so it stays cool. -Greg -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Blake Fithen Sent: Monday, January 03, 2000 6:36 PM Make sure all the fans are spinning. blake > -----Original Message----- > From: Greg Long [mailto:greg@coastlink.com] > Sent: Monday, January 03, 2000 6:58 PM > To: usr-tc@xmission.com > Subject: (usr-tc) Total Control Enterprise Network Hub > > > Hello! > > I've got a Total Control Enterprise Network Hub that has a > red "Hub Status" > light on the Network Management Card. I tried doing a > software reset and > shutting it down and powering it back on but the light pops > back to red > after about 30 seconds. I can't find anything wrong with it, > it is still > sending and receiving information. My callers haven't > complained about low > bandwidth or inability to do anything. According to the > manual it is a > Critical Chassis Failure. What do I need to do to the box to > make the green > light come back? Any help would be greatly appreciated! > > Thanks, > Greg Long > Tech Support > Coastlink > 801-532-6212 ext 32 > techsupp@coastlink.com > http://www.coastlink.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Total Control Enterprise Network Hub
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-04 09:52:54

Thus spake Steve Valiunas > The NMC can be queried to tell you the reason for the Hub-Status >light being red- It's under Performance Monitor / >FuncGroup=FailureReasons / Parm=HubStatusRed. This is available on >TCS3.5 and later codes (nmc ver 6.x.x). It might be a high >temperature, a card being reset, some kind of non-critical failure on >the NMC, a bad PSU... What's the actual SNMP OID for this? I think I remember seeing it somewhere, but I'll be darned if I can find it now. Aha! Just found it. In the NMC-MIB, nmcStatRedLed nmcStatRedLed OBJECT-TYPE SYNTAX INTEGER{ none(1), chassisTemperatureHigh(2), chassisFanFailure(3), voltageWarningforPSU(4), failureofPSU(5), managementBusFailure(6), interfaceCardFailure(7), incompatibleTokenRingNIC(8) } ACCESS read-only STATUS optional DESCRIPTION "This Object will return the Reason why the Hub Status LED is RED." ::= { nmcStat 12 } > The oldstyle chassis with the fan in the back has a sensor for the >single fan, and the newer-style chassis with the built-in fan tray will >report failures for the tray. You probably won't get anything for the >older add-on fan tray though. Well...considering the older style add-on tray didn't have any connection whatsoever to the chassis, that makes sense. ;) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) radius attribute 0x988b (39051)
From: Clayton Zekelman <clayton@mnsi.net>
Date: 2000-01-04 10:28:31

I tried the 3Com knowledge base, searching for VSA and Vendor Specific Attribute, but came up with zip. Lucent keeps an up to date dictionary available on their site (ftp.livingston.com), but it only includes the LE VSA's. I really wish 3Com would do that too. At 02:03 PM 12/23/99 -0500, you wrote: > > Does someone know what this attribute is? Name, and type (integer, >string, etc..) would be very helpful. > > Also, does USR have a difinitive radius attribute >dictonary that they distribute? I can't find one on >totalservice or lying around either. > > Thanks. > > - Jared > >-- >Jared Mauch | pgp key available via finger from jared@puck.nether.net >clue++; | http://puck.nether.net/~jared/ My statements are only mine. >END OF LINE | > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) S/A Server is crashing
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-04 11:39:47

At 05:03 PM 1/3/00 -0700, Jim Faulkner wrote: >I had the exact same problem with version 5.5.3. It would run great for >months and the crash several times on three servers simultaneously. I was >never ever able to find a cause. I got a copy of ServersAlive which would >monitor the radius server and then kill Dr Watson when there was a crash and >restart the Radius server. Very messy but it got me by. I've since installed >a 6.0 version and haven't seen the problem again but it's only been about >three weeks so I'm still holding my breath. I've been running 6.0.90 for about 3 months with no problems. If you're running it on Access '97, you may also want to make sure it's upgraded to SP2, that's the "Y2K Compliant" version. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) Total Control Enterprise Network Hub
From: Greg Long <greg@coastlink.com>
Date: 2000-01-04 12:18:57

I've got another question for everyone. Does anyone have the part number for a fan or the fan tray that would fit a USRobotics Total Control Enterprise Network Hub with 17 slots and 2 psu slots, or is anyone selling one? Thanks, Greg Long Tech Support Coastlink 801-532-6212 ext 32 techsupp@coastlink.com http://www.coastlink.com -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Long Sent: Tuesday, January 04, 2000 9:21 AM Hey thanks! That was the problem. Temp still looks good. I have two fans in the room to keep the air moving so it stays cool. -Greg -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Blake Fithen Sent: Monday, January 03, 2000 6:36 PM Make sure all the fans are spinning. blake > -----Original Message----- > From: Greg Long [mailto:greg@coastlink.com] > Sent: Monday, January 03, 2000 6:58 PM > To: usr-tc@xmission.com > Subject: (usr-tc) Total Control Enterprise Network Hub > > > Hello! > > I've got a Total Control Enterprise Network Hub that has a > red "Hub Status" > light on the Network Management Card. I tried doing a > software reset and > shutting it down and powering it back on but the light pops > back to red > after about 30 seconds. I can't find anything wrong with it, > it is still > sending and receiving information. My callers haven't > complained about low > bandwidth or inability to do anything. According to the > manual it is a > Critical Chassis Failure. What do I need to do to the box to > make the green > light come back? Any help would be greatly appreciated! > > Thanks, > Greg Long > Tech Support > Coastlink > 801-532-6212 ext 32 > techsupp@coastlink.com > http://www.coastlink.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) DSP 2.0.51
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-04 13:21:00

Anybody running 2.0.51 on their DSP's -- I have some .54 rev boards which, so far as I can tell, are exhibiting no unusual problems. But the release notes on 2.0.51 indicates it should be used on both .54 and .55 boards. I have noticed a slight increase in Rockwell problems since I turned these 2 cards up, and there are 1 or 2 Rockwell fixes in this release. Any thoughts? -- Scot Desort NJ Internet Access

Subject: (usr-tc) Dedicated IP pools
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-04 15:30:50

This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BF56C8.ADEE3260 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hello usr list fans...I got another project I am not sure how to set up. = I am trying to set up a dedicated <private> pool for only specific users = to use for a somewhat called dedicated modem. Now the problem is I set = up two different pools one for public and one for private but only the = public and be accessed. Using a T1, how do you set this up?=20 Any ideas, please reply. Thanks, -C ------=_NextPart_000_000B_01BF56C8.ADEE3260 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>hello usr list fans...I got another = project I am=20 not sure how to set up. I am trying to set up a dedicated = <private> pool=20 for only specific users to use for a somewhat called dedicated = modem. Now=20 the problem is I set up two different pools one for public and one for = private=20 but only the public and be accessed. Using a T1, how do you set this up? = </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Any ideas, please reply.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Thanks,</FONT></DIV> <DIV><FONT face=3DArial size=3D2>-C</FONT></DIV></BODY></HTML> ------=_NextPart_000_000B_01BF56C8.ADEE3260--

Subject: Re: (usr-tc) Dedicated IP pools
From: James Sewell <jsewell-lists@home.com>
Date: 2000-01-04 16:07:43

Two ways to do it: Set your users up in a RADIUS server. For those users who need to get an address in the private pool, set RADIUS attribute #217 "Framed-IP-Addr-Pool-Name" to the name of the private pool. Any existing users who do not have anything set for this parameter will continue to get an address from the original public pool. This would also explain why you are currently only seeing the public pool being used. The second way is to confugure the user accounts directly on the HiPer ARC. It's more cumbersome to manage a user database directly on the card, but if it's only s few users, it might be easier to make the change here than in your RADIUS database. Add the user account and set any other desired parameters as usual, then to set the private IP pool use this command: add address_pool user <user_name> pool_name <pool_name> -James > Cheryl Johnson wrote: > > hello usr list fans...I got another project I am not sure how to set > up. I am trying to set up a dedicated <private> pool for only specific > users to use for a somewhat called dedicated modem. Now the problem is > I set up two different pools one for public and one for private but > only the public and be accessed. Using a T1, how do you set this up? > > Any ideas, please reply. > > Thanks, > -C

Subject: RE: (usr-tc) radius attribute 0x988b (39051)
From: Scott Boggs <sboggs@unitedbank.net>
Date: 2000-01-04 16:24:38

There are some docs on 3com VSAs in the HiperArc Product ref. Appendix E Scott Boggs AccessUnited ISP Operations > -----Original Message----- > From: Clayton Zekelman [SMTP:clayton@MNSi.Net] > Sent: Tuesday, January 04, 2000 10:29 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) radius attribute 0x988b (39051) > > I tried the 3Com knowledge base, searching for VSA and Vendor Specific > Attribute, but came up with zip. > > Lucent keeps an up to date dictionary available on their site > (ftp.livingston.com), but it only includes the LE VSA's. I really wish > 3Com would do that too. > > > > At 02:03 PM 12/23/99 -0500, you wrote: > > > > Does someone know what this attribute is? Name, and type (integer, > >string, etc..) would be very helpful. > > > > Also, does USR have a difinitive radius attribute > >dictonary that they distribute? I can't find one on > >totalservice or lying around either. > > > > Thanks. > > > > - Jared > > > >-- > >Jared Mauch | pgp key available via finger from jared@puck.nether.net > >clue++; | http://puck.nether.net/~jared/ My statements are only > mine. > >END OF LINE | > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > --- > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 875 Ouellette Avenue > Windsor, Ontario > N9A 4J6 > > tel. 519-985-8410 > fax. 519-258-3009 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) R2 and PRI problem
From: Jorge Lozano <jorge@andinet.com>
Date: 2000-01-04 17:40:42

This is a multi-part message in MIME format. ------=_NextPart_000_01AF_01BF56DA.D2AEE600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody! I have a TCH with Hiper DSP cards, they are working correctly with R2, but I want to make to them work with PRI lines. if somebody know what is the procedure.... can help me?=20 Maybe... the answer is very easy, but I am a newbie in this. Thanks for all. Jorge Lozano M. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com> iQA/AwUBOHJ26ap3oywyFVUlEQIWlwCg0VmR6YcInE/JI6BvVzPJNtip104AnApv wzbbUDD3WUVI33xA5Ue6wYFm =3DHnLd -----END PGP SIGNATURE----- ------=_NextPart_000_01AF_01BF56DA.D2AEE600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV>-----BEGIN PGP SIGNED MESSAGE-----<BR>Hash: SHA1</DIV> <DIV> </DIV> <DIV>Hi everybody!<BR>I have a TCH with Hiper DSP cards, they are = working=20 correctly with<BR>R2, but I want to make to them work with PRI lines. if = somebody know<BR>what is the procedure.... can help me? <BR>Maybe... the = answer=20 is very easy, but I am a newbie in this.</DIV> <DIV> </DIV> <DIV>Thanks for all.</DIV> <DIV> </DIV> <DIV>Jorge Lozano M.</DIV> <DIV> </DIV> <DIV>-----BEGIN PGP SIGNATURE-----<BR>Version: PGPfreeware 6.5.1 for=20 non-commercial use <<A=20 href=3D"http://www.pgp.com">http://www.pgp.com</A>></DIV> <DIV> </DIV> <DIV>iQA/AwUBOHJ26ap3oywyFVUlEQIWlwCg0VmR6YcInE/JI6BvVzPJNtip104AnApv<BR>= wzbbUDD3WUVI33xA5Ue6wYFm<BR>=3DHnLd<BR>-----END=20 PGP SIGNATURE-----<BR></DIV></BODY></HTML> ------=_NextPart_000_01AF_01BF56DA.D2AEE600--

Subject: (usr-tc) Flaky modem or telco problem?
From: zip-usrtc@ran.zipcon.net
Date: 2000-01-04 18:43:39

I'm having a modem problem with a USR TC with DSP based modems. DSP is 2.0.51, ARC is 4.2.32. I'm having an odd problem where modem 24 is being troublesome quite often. It appears to work for short periods of time though (a few seconds). I'm unsure how to identify whether its the modem or a problem with the telco T1. Does anyone have any tips on a good way to test the modem or line within the ARC? Thanks, Dan

Subject: (usr-tc) Total Control Software Questions
From: meijin@vvm.com <meijin@vvm.com>
Date: 2000-01-04 23:06:14

I am inheriting an older Total Control system with a total of (I believe) 46 or 48 modems. I come from a background of Portmaster products. So, I am curious about software. Is there a Radius server for NT that works with this equipment? Also, is there something that is similar to PMVision? That is, allows me to monitor the modems and who is on them and such from the PC? All from an NT environment? Is this stuff bundled with the hardware or is it sold extra? Any apps out on the net for this? Any help? Thanks! dr

Subject: (usr-tc) DSP Settings
From: Mark E. Levy <mark@fsi.net>
Date: 2000-01-05 08:06:33

When installing a new DSP or doing a firmware upgrade on an existing one, I've always done "Restore T1/E1 and Modems from Default" and "Restore Template 1 from Default", changed the call routing to "Round Robin", and resaved both to NVRAM. I'm thinking that perhaps there may be other things that would be advantageous to change. What sort of parameters do you change when installing or upgrading a DSP? -- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.net

Subject: Re: (usr-tc) R2 and PRI problem
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 2000-01-05 08:57:22

--0__=JcK6rciz29OvhY5J4bBmnu3dHePMJY8Ps1eRQy8CEiewjQYygWOQjxUU Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hi Jorge, If you are talking about E1/PRI do the following, Install the E1/PRI version via TCM, Go to the DSP CLI >chdev span >cmd rd (Default) >cmd sv (save) > re (Reset) Ask the following questions from your Telco provider Frame type Set ltype = E1 or CRC E1 Switch type Set Swtype = ictr4 (Euro ISDN) or VN4 (France) Line coding is set to HDB3 Make sure your Sigmode is also set to message oriented (Default) Ray W "Jorge Lozano" <jorge@andinet.com> on 04/01/2000 22:40:42 Please respond to usr-tc@lists.xmission.com Sent by: "Jorge Lozano" <jorge@andinet.com> cc: (Ray Whelan/IE/3Com) -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi everybody! I have a TCH with Hiper DSP cards, they are working correctly with R2, but I want to make to them work with PRI lines. if somebody know what is the procedure.... can help me? Maybe... the answer is very easy, but I am a newbie in this. Thanks for all. Jorge Lozano M. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com> iQA/AwUBOHJ26ap3oywyFVUlEQIWlwCg0VmR6YcInE/JI6BvVzPJNtip104AnApv wzbbUDD3WUVI33xA5Ue6wYFm =HnLd -----END PGP SIGNATURE----- --0__=JcK6rciz29OvhY5J4bBmnu3dHePMJY8Ps1eRQy8CEiewjQYygWOQjxUU Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjMxNC4xMDAwIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj4tLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVT U0FHRS0tLS0tPEJSPkhhc2g6IFNIQTE8L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPkhp IGV2ZXJ5Ym9keSE8QlI+SSBoYXZlIGEgVENIIHdpdGggSGlwZXIgRFNQIGNhcmRzLCB0aGV5IGFy ZSB3b3JraW5nIA0KY29ycmVjdGx5IHdpdGg8QlI+UjIsIGJ1dCBJIHdhbnQgdG8gbWFrZSB0byB0 aGVtIHdvcmsgd2l0aCBQUkkgbGluZXMuIGlmIA0Kc29tZWJvZHkga25vdzxCUj53aGF0IGlzIHRo ZSBwcm9jZWR1cmUuLi4uIGNhbiBoZWxwIG1lPyA8QlI+TWF5YmUuLi4gdGhlIGFuc3dlciANCmlz IHZlcnkgZWFzeSwgYnV0IEkgYW0gYSBuZXdiaWUgaW4gdGhpcy48L0RJVj4NCjxESVY+Jm5ic3A7 PC9ESVY+DQo8RElWPlRoYW5rcyBmb3IgYWxsLjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+Sm9yZ2UgTG96YW5vIE0uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj4tLS0tLUJF R0lOIFBHUCBTSUdOQVRVUkUtLS0tLTxCUj5WZXJzaW9uOiBQR1BmcmVld2FyZSA2LjUuMSBmb3Ig DQpub24tY29tbWVyY2lhbCB1c2UgJmx0OzxBIA0KaHJlZj0iaHR0cDovL3d3dy5wZ3AuY29tIj5o dHRwOi8vd3d3LnBncC5jb208L0E+Jmd0OzwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+ aVFBL0F3VUJPSEoyNmFwM295d3lGVlVsRVFJV2x3Q2cwVm1SNlljSW5FL0pJNkJ2VnpQSk50aXAx MDRBbkFwdjxCUj53emJiVUREM1dVVkkzM3hBNVVlNndZRm08QlI+PUhuTGQ8QlI+LS0tLS1FTkQg DQpQR1AgU0lHTkFUVVJFLS0tLS08QlI+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== --0__=JcK6rciz29OvhY5J4bBmnu3dHePMJY8Ps1eRQy8CEiewjQYygWOQjxUU--

Subject: Re: (usr-tc) Dedicated IP pools
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-05 09:13:19

Ok, configuring this through the ARC works quite well at least for a limited number of users. This doesn't actually set a specific modem to the dedicated user. I am trying to pull a modem...say <slot:15:/mod:[24}> out of the available pool on the DSP card and set this up for a modem_group named <dedicated> so this modem can only be used by a specific user and not the entire public pool. Although I haven't found the command set to do this yet, but think I am heading in the right direction. Theoretically, yes the modem should always have a modem to connect to if you set the public ip_pool <whatever> number less on the available number of modems, but this is not a true dedicated modem because the user may not always get the same modem. This would more helpful in troubleshooting, if problems arise for a dedicated user. Cheryl ----- Original Message ----- Sent: Tuesday, January 04, 2000 5:07 PM > Two ways to do it: > > Set your users up in a RADIUS server. For those users who need to get > an address in the private pool, set RADIUS attribute #217 > "Framed-IP-Addr-Pool-Name" to the name of the private pool. Any > existing users who do not have anything set for this parameter will > continue to get an address from the original public pool. This would > also explain why you are currently only seeing the public pool being > used. > > > The second way is to confugure the user accounts directly on the HiPer > ARC. It's more cumbersome to manage a user database directly on the > card, but if it's only s few users, it might be easier to make the > change here than in your RADIUS database. Add the user account and set > any other desired parameters as usual, then to set the private IP pool > use this command: > > add address_pool user <user_name> pool_name <pool_name> > > > -James > > > Cheryl Johnson wrote: > > > > hello usr list fans...I got another project I am not sure how to set > > up. I am trying to set up a dedicated <private> pool for only specific > > users to use for a somewhat called dedicated modem. Now the problem is > > I set up two different pools one for public and one for private but > > only the public and be accessed. Using a T1, how do you set this up? > > > > Any ideas, please reply. > > > > Thanks, > > -C > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Total Control Software Questions
From: Greg Long <greg@coastlink.com>
Date: 2000-01-05 09:22:57

We've got a Total Control Hub with 48 modems. Steel Belted Radius runs on NT and allows you to monitor who is on. It also does a really nice job with accounting. www.funk.com -Greg -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of meijin@vvm.com Sent: Tuesday, January 04, 2000 10:06 PM I am inheriting an older Total Control system with a total of (I believe) 46 or 48 modems. I come from a background of Portmaster products. So, I am curious about software. Is there a Radius server for NT that works with this equipment? Also, is there something that is similar to PMVision? That is, allows me to monitor the modems and who is on them and such from the PC? All from an NT environment? Is this stuff bundled with the hardware or is it sold extra? Any apps out on the net for this? Any help? Thanks! dr - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Problems with TCM!
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-05 10:29:31

You might be using an older NMC version. You need 6.x NMC code. Steve Valiunas Jorge Lozano <jorge@andinet.com> on 01/05/2000 10:26:28 AM Please respond to usr-tc@lists.xmission.com Sent by: Jorge Lozano <jorge@andinet.com> cc: (Steve Valiunas/MW/US/3Com) Hi again... I have a TCM 6.0.23 and 6.0.86, I am trying congifure the Hiper DSP cards (2.0.19), but then... I have an error message from TCM. The following lines are the message: Error Opening Device Description File Configuration not supported Initiation failed anybody know what is the problem?????? sincerely, Jorge Lozano Este mensaje fue enviado usando Andinet WebMail. http://www.andinet.com/ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Dedicated IP pools
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-05 10:33:15

if you want to have a set of modems to which only a select group will have access, you will need to have the telco split up your trunks into multiple trunk groups and assign separate numbers to each. Then you would need to do DNIS based authentication on the RADIUS side. Also confirm with the telco that they are sending DNIS digits. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Cheryl Johnson [mailto:netadmin@seidata.com] > Sent: Wednesday, January 05, 2000 10:13 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Dedicated IP pools > > > Ok, configuring this through the ARC works quite well at > least for a limited > number of users. This doesn't actually set a specific modem > to the dedicated > user. I am trying to pull a modem...say <slot:15:/mod:[24}> out of the > available pool on the DSP card and set this up for a modem_group named > <dedicated> so this modem can only be used by a specific user > and not the > entire public pool. Although I haven't found the command set > to do this yet, > but think I am heading in the right direction. Theoretically, > yes the modem > should always have a modem to connect to if you set the public ip_pool > <whatever> number less on the available number of modems, but > this is not a > true dedicated modem because the user may not always get the > same modem. > This would more helpful in troubleshooting, if problems arise for a > dedicated user. > > > Cheryl > > ----- Original Message ----- > From: James Sewell <jsewell-lists@home.com> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, January 04, 2000 5:07 PM > Subject: Re: (usr-tc) Dedicated IP pools > > > > Two ways to do it: > > > > Set your users up in a RADIUS server. For those users who > need to get > > an address in the private pool, set RADIUS attribute #217 > > "Framed-IP-Addr-Pool-Name" to the name of the private pool. Any > > existing users who do not have anything set for this parameter will > > continue to get an address from the original public pool. > This would > > also explain why you are currently only seeing the public pool being > > used. > > > > > > The second way is to confugure the user accounts directly > on the HiPer > > ARC. It's more cumbersome to manage a user database directly on the > > card, but if it's only s few users, it might be easier to make the > > change here than in your RADIUS database. Add the user > account and set > > any other desired parameters as usual, then to set the > private IP pool > > use this command: > > > > add address_pool user <user_name> pool_name <pool_name> > > > > > > -James > > > > > Cheryl Johnson wrote: > > > > > > hello usr list fans...I got another project I am not sure > how to set > > > up. I am trying to set up a dedicated <private> pool for > only specific > > > users to use for a somewhat called dedicated modem. Now > the problem is > > > I set up two different pools one for public and one for > private but > > > only the public and be accessed. Using a T1, how do you > set this up? > > > > > > Any ideas, please reply. > > > > > > Thanks, > > > -C > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Problems with TCM!
From: Jorge Lozano <jorge@andinet.com>
Date: 2000-01-05 11:26:28

Hi again... I have a TCM 6.0.23 and 6.0.86, I am trying congifure the Hiper DSP cards (2.0.19), but then... I have an error message from TCM. The following lines are the message: Error Opening Device Description File Configuration not supported Initiation failed anybody know what is the problem?????? sincerely, Jorge Lozano Este mensaje fue enviado usando Andinet WebMail. http://www.andinet.com/

Subject: Re: (usr-tc) Dedicated IP pools
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-05 11:56:02

Well, this is what I am trying to stay away from to avoid the hefty charges the telcos charge to split the trunks on an active circuit. But maybe with what I have will work as long as I have plenty of modems available. I'll keep digging for possibilities....thanks. Cheryl Johnson netadmin@seidata.com SEI Data Network Services, Inc. ----- Original Message ----- Sent: Wednesday, January 05, 2000 9:33 AM > > if you want to have a set of modems to which only a select group will have > access, you will need to have the telco split up your trunks into multiple > trunk groups and assign separate numbers to each. Then you would need to do > DNIS based authentication on the RADIUS side. Also confirm with the telco > that they are sending DNIS digits. > > Matthew Stainforth || Technical Services Manager || BrunNet Inc. > > > > -----Original Message----- > > From: Cheryl Johnson [mailto:netadmin@seidata.com] > > Sent: Wednesday, January 05, 2000 10:13 AM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Dedicated IP pools > > > > > > Ok, configuring this through the ARC works quite well at > > least for a limited > > number of users. This doesn't actually set a specific modem > > to the dedicated > > user. I am trying to pull a modem...say <slot:15:/mod:[24}> out of the > > available pool on the DSP card and set this up for a modem_group named > > <dedicated> so this modem can only be used by a specific user > > and not the > > entire public pool. Although I haven't found the command set > > to do this yet, > > but think I am heading in the right direction. Theoretically, > > yes the modem > > should always have a modem to connect to if you set the public ip_pool > > <whatever> number less on the available number of modems, but > > this is not a > > true dedicated modem because the user may not always get the > > same modem. > > This would more helpful in troubleshooting, if problems arise for a > > dedicated user. > > > > > > Cheryl > > > > ----- Original Message ----- > > From: James Sewell <jsewell-lists@home.com> > > To: <usr-tc@lists.xmission.com> > > Sent: Tuesday, January 04, 2000 5:07 PM > > Subject: Re: (usr-tc) Dedicated IP pools > > > > > > > Two ways to do it: > > > > > > Set your users up in a RADIUS server. For those users who > > need to get > > > an address in the private pool, set RADIUS attribute #217 > > > "Framed-IP-Addr-Pool-Name" to the name of the private pool. Any > > > existing users who do not have anything set for this parameter will > > > continue to get an address from the original public pool. > > This would > > > also explain why you are currently only seeing the public pool being > > > used. > > > > > > > > > The second way is to confugure the user accounts directly > > on the HiPer > > > ARC. It's more cumbersome to manage a user database directly on the > > > card, but if it's only s few users, it might be easier to make the > > > change here than in your RADIUS database. Add the user > > account and set > > > any other desired parameters as usual, then to set the > > private IP pool > > > use this command: > > > > > > add address_pool user <user_name> pool_name <pool_name> > > > > > > > > > -James > > > > > > > Cheryl Johnson wrote: > > > > > > > > hello usr list fans...I got another project I am not sure > > how to set > > > > up. I am trying to set up a dedicated <private> pool for > > only specific > > > > users to use for a somewhat called dedicated modem. Now > > the problem is > > > > I set up two different pools one for public and one for > > private but > > > > only the public and be accessed. Using a T1, how do you > > set this up? > > > > > > > > Any ideas, please reply. > > > > > > > > Thanks, > > > > -C > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Total Control Software Questions
From: Scott Boggs <sboggs@unitedbank.net>
Date: 2000-01-05 12:09:05

We also use Steel Belted RADIUS from Funk.com I like it a lot. Especially its ability to handle VSAs for multiple vendors. We have a TC and two ascend Maxs, and SBR serves both simultanesouesly. Their latest version has a command line adapter that can admin from dos prompt. Scott Boggs AccessUnited ISP Operations > -----Original Message----- > From: Greg Long [SMTP:greg@coastlink.com] > Sent: Wednesday, January 05, 2000 11:23 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Total Control Software Questions > > We've got a Total Control Hub with 48 modems. Steel Belted Radius runs on > NT and allows you to monitor who is on. It also does a really nice job > with > accounting. www.funk.com > > -Greg > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of meijin@vvm.com > Sent: Tuesday, January 04, 2000 10:06 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Total Control Software Questions > > > I am inheriting an older Total Control system with a total of (I believe) > 46 or 48 modems. I come from a background of Portmaster products. So, I am > curious about software. Is there a Radius server for NT that works with > this equipment? Also, is there something that is similar to PMVision? That > is, allows me to monitor the modems and who is on them and such from the > PC? All from an NT environment? Is this stuff bundled with the hardware or > is it sold extra? Any apps out on the net for this? Any help? > > Thanks! > > dr > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Dedicated IP pools
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-05 13:12:35

Without splitting the trunks you have no way of guaranteeing a call will or won't be delivered to slot:x/mod:y. The charge by our telco is tarrifed at $250 installation per trunk group affected plus $1.30/month per extra telephone number. I wouldn't think it would vary much by region but I guess you never know with telcos. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Cheryl Johnson [mailto:netadmin@seidata.com] > Sent: Wednesday, January 05, 2000 12:56 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Dedicated IP pools > > > Well, this is what I am trying to stay away from to avoid the > hefty charges > the telcos charge to split the trunks on an active circuit. > But maybe with > what I have will work as long as I have plenty of modems > available. I'll > keep digging for possibilities....thanks. > > Cheryl Johnson > netadmin@seidata.com > SEI Data Network Services, Inc. > > > ----- Original Message ----- > From: Stainforth, Matthew <MatthewS@staff.brunnet.net> > To: <usr-tc@lists.xmission.com> > Sent: Wednesday, January 05, 2000 9:33 AM > Subject: RE: (usr-tc) Dedicated IP pools > > > > > > if you want to have a set of modems to which only a select > group will have > > access, you will need to have the telco split up your > trunks into multiple > > trunk groups and assign separate numbers to each. Then you > would need to > do > > DNIS based authentication on the RADIUS side. Also confirm > with the telco > > that they are sending DNIS digits. > > > > Matthew Stainforth || Technical Services Manager || BrunNet Inc. > > > > > > > -----Original Message----- > > > From: Cheryl Johnson [mailto:netadmin@seidata.com] > > > Sent: Wednesday, January 05, 2000 10:13 AM > > > To: usr-tc@lists.xmission.com > > > Subject: Re: (usr-tc) Dedicated IP pools > > > > > > > > > Ok, configuring this through the ARC works quite well at > > > least for a limited > > > number of users. This doesn't actually set a specific modem > > > to the dedicated > > > user. I am trying to pull a modem...say > <slot:15:/mod:[24}> out of the > > > available pool on the DSP card and set this up for a > modem_group named > > > <dedicated> so this modem can only be used by a specific user > > > and not the > > > entire public pool. Although I haven't found the command set > > > to do this yet, > > > but think I am heading in the right direction. Theoretically, > > > yes the modem > > > should always have a modem to connect to if you set the > public ip_pool > > > <whatever> number less on the available number of modems, but > > > this is not a > > > true dedicated modem because the user may not always get the > > > same modem. > > > This would more helpful in troubleshooting, if problems > arise for a > > > dedicated user. > > > > > > > > > Cheryl > > > > > > ----- Original Message ----- > > > From: James Sewell <jsewell-lists@home.com> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Tuesday, January 04, 2000 5:07 PM > > > Subject: Re: (usr-tc) Dedicated IP pools > > > > > > > > > > Two ways to do it: > > > > > > > > Set your users up in a RADIUS server. For those users who > > > need to get > > > > an address in the private pool, set RADIUS attribute #217 > > > > "Framed-IP-Addr-Pool-Name" to the name of the private pool. Any > > > > existing users who do not have anything set for this > parameter will > > > > continue to get an address from the original public pool. > > > This would > > > > also explain why you are currently only seeing the > public pool being > > > > used. > > > > > > > > > > > > The second way is to confugure the user accounts directly > > > on the HiPer > > > > ARC. It's more cumbersome to manage a user database > directly on the > > > > card, but if it's only s few users, it might be easier > to make the > > > > change here than in your RADIUS database. Add the user > > > account and set > > > > any other desired parameters as usual, then to set the > > > private IP pool > > > > use this command: > > > > > > > > add address_pool user <user_name> pool_name <pool_name> > > > > > > > > > > > > -James > > > > > > > > > Cheryl Johnson wrote: > > > > > > > > > > hello usr list fans...I got another project I am not sure > > > how to set > > > > > up. I am trying to set up a dedicated <private> pool for > > > only specific > > > > > users to use for a somewhat called dedicated modem. Now > > > the problem is > > > > > I set up two different pools one for public and one for > > > private but > > > > > only the public and be accessed. Using a T1, how do you > > > set this up? > > > > > > > > > > Any ideas, please reply. > > > > > > > > > > Thanks, > > > > > -C > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old > > > messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Total Control Software Questions
From: Tom Swenson <tom@netconx.net>
Date: 2000-01-05 13:56:41

I also am from a Portmaster background, and was disappointed to find I couldn't see who was online, how fast, how long, and how idle. I have a pmwho conversion to a usrwho which is working well, but it won't tell connect speed or idle time. I have to either telnet into the TC or use TCM to see how fast. Not very efficient. I also was used to being able to see a user connecting and be able to see if they were misspelling or putting @netconx.net on the end of their username, but I can't see it with the usrwho program. If I'm missing any ways of doing these things, I hope someone would pass along the secrets. Good luck with your TC's, I like mine so far except for the monitoring. There is lot's of good info in the TCM that I didn't have before. I also like going beyond 48 modems in a chassis. Tom Swenson NetConX - Internet Access - Web Design - Client Managed Web Database Applications tom@netconx.net http://www.netconx.net (515) 421-4170 - Voice (515) 423-3351 - FAX *********** REPLY SEPARATOR *********** On 1/4/2000 at 11:06 PM meijin@vvm.com wrote: >I am inheriting an older Total Control system with a total of (I believe) >46 or 48 modems. I come from a background of Portmaster products. So, I am >curious about software. Is there a Radius server for NT that works with >this equipment? Also, is there something that is similar to PMVision? That >is, allows me to monitor the modems and who is on them and such from the >PC? All from an NT environment? Is this stuff bundled with the hardware or >is it sold extra? Any apps out on the net for this? Any help? > >Thanks! > >dr > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Problems with new HiperARC Code
From: Jorge Lozano <jorge@andinet.com>
Date: 2000-01-05 14:47:56

Hi! I�m trying upgrade HiperARC firmware with TCM 6.0.86 to new version (4.2.32). But during the firmware transfer (65% aprox.), the TCM give me an error... Failed. TFTP error: Access violation Can you tell me why? Thanks for all your help! Jorge Lozano M. Este mensaje fue enviado usando Andinet WebMail. http://www.andinet.com/

Subject: (usr-tc) Callback with DSP
From: Jorge Lozano <jorge@andinet.com>
Date: 2000-01-05 21:57:15

This is a multi-part message in MIME format. ------=_NextPart_000_00B1_01BF57C7.D3EA2870 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm the following configuration: HiperDSP (E1/PRI) with firmware 2.0.19 HiperARC with firmware 4.1.17 TCM 6.0.86 How can I setup the callback option for users using my RADIUS server (Radiator) or using the chassis userlist?? Thanks again...=20 Jorge Lozano M. <jorge@andinet.com> "The security is not a solution, is a life style" Please visit, http://www.andinet.com -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.1 for non-commercial use <http://www.pgp.com> iQA/AwUBOHQEiqp3oywyFVUlEQJWxgCg+NvXumER1fTGqHsPApoIEWDzXaIAmgMj /kfGzONOL/Xzk0NPNSAbln7A =3DZrdk -----END PGP SIGNATURE----- ------=_NextPart_000_00B1_01BF57C7.D3EA2870 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV>-----BEGIN PGP SIGNED MESSAGE-----<BR>Hash: SHA1</DIV> <DIV> </DIV> <DIV>I'm the following configuration:<BR>HiperDSP (E1/PRI) with firmware = 2.0.19<BR>HiperARC with firmware 4.1.17<BR>TCM 6.0.86</DIV> <DIV> </DIV> <DIV>How can I setup the callback option for users using my RADIUS=20 server<BR>(Radiator) or using the chassis userlist??</DIV> <DIV> </DIV> <DIV>Thanks again... </DIV> <DIV> </DIV> <DIV>Jorge Lozano M. <<A=20 href=3D"mailto:jorge@andinet.com">jorge@andinet.com</A>><BR>"The = security is=20 not a solution, is a life style"<BR>Please visit, <A=20 href=3D"http://www.andinet.com">http://www.andinet.com</A></DIV> <DIV> </DIV> <DIV>-----BEGIN PGP SIGNATURE-----<BR>Version: PGPfreeware 6.5.1 for=20 non-commercial use <<A=20 href=3D"http://www.pgp.com">http://www.pgp.com</A>></DIV> <DIV> </DIV> <DIV>iQA/AwUBOHQEiqp3oywyFVUlEQJWxgCg+NvXumER1fTGqHsPApoIEWDzXaIAmgMj<BR>= /kfGzONOL/Xzk0NPNSAbln7A<BR>=3DZrdk<BR>-----END=20 PGP SIGNATURE-----<BR></DIV></BODY></HTML> ------=_NextPart_000_00B1_01BF57C7.D3EA2870--

Subject: (usr-tc) HiperTRAX, x.25 and POS
From: Andres Kroonmaa <andre@ml.ee>
Date: 2000-01-05 22:24:44

hi, Has anyone any experience or info about so called HiperTRAX for TC systems? Its for credit/debit card applications like point-of-sale connectivity, with X.25 support, etc. The only thing I can find on 3com web is this page: http://www.3com.com/products/dsheets/400444.html which really isn't very heplful. I can't really understand what hardware is needed for it, what software/firmware, what PN's should I use for pricing. Actually, is this a real thing or yet another marketing hype? anyone? Andres Kroonmaa <andre@online.ee> MicroLink Online Network Development Manager Tel: 6501 731, Fax: 6501 708 P=E4rnu mnt. 158, Tallinn, 11317 Estonia

Subject: RE: (usr-tc) Total Control Software Questions
From: Greg Long <greg@coastlink.com>
Date: 2000-01-06 09:25:06

If your users authenitcate to an NT SAM database then any misspelling of a username can be logged into the event log. That's how we set it up here. Alas I am rather new to the job and haven't been over everything (if it works, leave it alone) -Greg -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tom Swenson Sent: Wednesday, January 05, 2000 12:57 PM I also am from a Portmaster background, and was disappointed to find I couldn't see who was online, how fast, how long, and how idle. I have a pmwho conversion to a usrwho which is working well, but it won't tell connect speed or idle time. I have to either telnet into the TC or use TCM to see how fast. Not very efficient. I also was used to being able to see a user connecting and be able to see if they were misspelling or putting @netconx.net on the end of their username, but I can't see it with the usrwho program. If I'm missing any ways of doing these things, I hope someone would pass along the secrets. Good luck with your TC's, I like mine so far except for the monitoring. There is lot's of good info in the TCM that I didn't have before. I also like going beyond 48 modems in a chassis. Tom Swenson NetConX - Internet Access - Web Design - Client Managed Web Database Applications tom@netconx.net http://www.netconx.net (515) 421-4170 - Voice (515) 423-3351 - FAX *********** REPLY SEPARATOR *********** On 1/4/2000 at 11:06 PM meijin@vvm.com wrote: >I am inheriting an older Total Control system with a total of (I believe) >46 or 48 modems. I come from a background of Portmaster products. So, I am >curious about software. Is there a Radius server for NT that works with >this equipment? Also, is there something that is similar to PMVision? That >is, allows me to monitor the modems and who is on them and such from the >PC? All from an NT environment? Is this stuff bundled with the hardware or >is it sold extra? Any apps out on the net for this? Any help? > >Thanks! > >dr > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Management Bus Failures
From: Phil Nass <phil@lakefield.net>
Date: 2000-01-06 09:38:28

Hello all, We have two TC chassis, one has 14 DSP's w/2 ARC's and the other has 6 DSP w/1 ARC. I am running all ISDN PRI's and all DSP's are at 2.0.60, 4.1.59-6 ARC's and the HiPer NMC's with 6.2.17. The DSP firmware of the DSP's ranges from .49 to .54. My problem is that we get sporadic Management Bus Failures - "in both chassis" and on different cards. When this happens the card re-boots itself and of course, drops those 23 online. The re-boots do not follow any sort of pattern and I went a couple of weeks without any and now have had 3 or 4 within the past week. I have switched DSP cards and PRI's. The newer version 2.0.19 does address the management re-boots but only for the .54 and .55 firmware. Anybody have or seen anything similar...??? Any other ideas..??? This is really driving me crazy and BTW: I received another this morning on SLOT 2 in the 218 chassis. ........... Phil@lakefield.net (920) 758-2211 Phil Nass - General Manger @ Lakefield Tel I have enclosed a portion of my alarm server text: Authentication Failure 0 INFORMATIONAL OPERATIONAL 01/01/00 21:05:08 206.40.97.218 12/31/69 16:00:01 10005 Authentication Failure 0 INFORMATIONAL OPERATIONAL 01/01/00 21:04:43 206.40.97.218 12/31/69 16:00:01 10005 6; Yellow Alarm (remote OOF) cleared on Slot 12, DS1 Channel 1 0 INFORMATIONAL OPERATIONAL 01/01/00 19:42:25 206.40.97.218 01/01/00 11:46:24 429050 5; Watchdog Timeout in Slot 12, Channel 0 0 MAJOR NONOPERATIONAL 01/01/00 19:42:12 206.40.97.218 01/01/00 11:46:11 429007 4; Yellow Alarm (remote OOF) on Slot 12, DS1 Channel 1 0 INFORMATIONAL OPERATIONAL 01/01/00 19:41:58 206.40.97.218 01/01/00 11:45:57 429022 3; Management Bus Failure in Slot 12, Channel 1 0 MAJOR NONOPERATIONAL 01/01/00 19:39:26 206.40.97.218 01/01/00 11:43:25 429008 2; Watchdog Timeout in Slot 6, Channel 0 0 MAJOR NONOPERATIONAL 01/01/00 17:33:48 206.40.97.218 01/01/00 09:37:47 429007 1; Management Bus Failure in Slot 6, Channel 1 0 MAJOR NONOPERATIONAL 01/01/00 17:42:59 206.40.97.218 01/01/00 09:37:43 429008 Authentication Failure 0 INFORMATIONAL OPERATIONAL 01/01/00 16:13:19 206.40.97.218 12/31/69 16:00:01 10005 Warm Start 1 INFORMATIONAL OPERATIONAL 12/29/99 18:03:44 206.40.97.219 12/31/69 16:00:01 12/29/99 18:26:15 10002 3; Yellow Alarm (remote OOF) cleared on Slot 1, DS1 Channel 1 1 INFORMATIONAL OPERATIONAL 12/29/99 16:44:06 206.40.97.219 04/27/29 04:14:35 12/29/99 16:44:12 429050 2; Watchdog Timeout in Slot 1, Channel 0 1 MAJOR NONOPERATIONAL 12/29/99 16:43:50 206.40.97.219 04/27/29 04:14:19 12/29/99 16:44:12 429007 1; Management Bus Failure in Slot 1, Channel 1 1 MAJOR NONOPERATIONAL 12/29/99 16:41:28 206.40.97.219 04/27/29 04:11:54 12/29/99 16:42:48 429008

Subject: (usr-tc) trapped with snmp
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-06 10:19:15

Now that I've (locally) discovered the use of perl and the Net:SNMP module to talk to my TC (HiPer) chassis, I've recently been feeling all godlike and stuff. Of course, when a human experiences a taste of godhood, the PowersThatBe quickly queue up a lesson in humility. Anyway, I'm trying to play with SNMP traps and I must be missing something obvious. Here's the deal: 1) I run snmptrapd (from cmu-snmp-utils-3.5-3) on a handy linux box, telling it to both print the trap and dump inbound packets. 2) I verify operation of #1 by running snmptrap to generate a couple of arbitrary traps. Works great. 3) I go into TCM, pick a HiPerDSP card (selecting the LEDs on the span), and click "Fault->Trap Settings" and select "Trap Enables" 4) There, I set a few choice ones to "enableTrap". Specifically, "Red Alarm", "Loss of Signal", and "Physical State Change". Then I click "Set" and "Ok" to set it and exit. 5) Next, I click "Fault->Trap Destinations", and add an entry for the aforementioned linux box running snmptrapd. 6) I physically unplug the span from the HiPerDSP. Amazingly enough, the LEDS suddenly reflect a Red Alarm. (: 7) The amazement turns to disappointment when I see that my snmptrapd didn't hear anything. Due to my lack of real understanding of the trap destination configuration (umm, not the need for, you understand *grin*), I tried a few different things there. Even though snmptrapd appears to not give a whit about the community string, I tried three: nothing, junk, and the same as my NMC's community. And since I can't find anything in the docs that explains the "Annotation" entry, I also tried nothing, an integer '1', and an arbitrary string. I also verified that the linux box had a listener on the udp:snmp-trap port. All else failed, so it was time to consult the documentation. (: The docs basically told me to do all the stuff I did already. And, typical of docs, stopped short from answering the real question (like WTF is expected for "Annotation"). So, before I scrap the whole idea for now (being unwilling to go to the bother of sticking a hub in between the TC and the linux box so I can stick another packet-sniffin' box in there (a PIA that needs to be done because my LAN is point2point switched ethernet...useless to sniff from other segments)), I thought I'd ask here in case there was anything obvious that I'm leaving out (like maybe the NAC needs a reboot for the trap destination change to take effect or some other tripe). Or if I'm falling into some sort of a hidden, umm, trap. If anyone can slap me with a clue stick, I'd be grateful. (:

Subject: Re: (usr-tc) Total Control Software Questions
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-06 11:24:29

I use the vircom.com radius server and it is very stable. My recomendation is to not run the radius on a machine doing other tasks, actually I would make the same statement about most mission critical tasks. I have found that many NT applications have memory leaks that eventually take down the server. The machines that are running known stable code are very reliable, but I do have a machine running an application that is problematic in this area. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Thursday, January 06, 2000 11:28 AM > I am currently authenticating to a Linux server with Cistron Radius. If I > could ever figure out a way to migrate my users/passwords to NT, I might > consider it. I am leary, however, because my two NT servers are not nearly > as reliable as my Linux is ( I don't mean to start any OS wars here). I am > using Platypus as a accounting program and I believe that there are Radius > version which will authenticate to the SQL Server. This would be kind of > nice. > > Thanks for the reply. > > Tom Swenson > NetConX - Internet Access - Web Design - Client Managed Web Database > Applications > tom@netconx.net http://www.netconx.net > (515) 421-4170 - Voice (515) 423-3351 - FAX > > > *********** REPLY SEPARATOR *********** > > On 1/6/2000 at 9:25 AM Greg Long wrote: > > >If your users authenitcate to an NT SAM database then any misspelling of > a > >username can be logged into the event log. That's how we set it up here. > >Alas I am rather new to the job and haven't been over everything (if it > >works, leave it alone) > > > >-Greg > > > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tom Swenson > >Sent: Wednesday, January 05, 2000 12:57 PM > >To: usr-tc@lists.xmission.com > >Subject: Re: (usr-tc) Total Control Software Questions > > > > > >I also am from a Portmaster background, and was disappointed to find I > >couldn't see who was online, how fast, how long, and how idle. I have a > >pmwho conversion to a usrwho which is working well, but it won't tell > >connect speed or idle time. I have to either telnet into the TC or use > TCM > >to see how fast. Not very efficient. I also was used to being able to see > >a user connecting and be able to see if they were misspelling or putting > >@netconx.net on the end of their username, but I can't see it with the > >usrwho program. If I'm missing any ways of doing these things, I hope > >someone would pass along the secrets. Good luck with your TC's, I like > >mine so far except for the monitoring. There is lot's of good info in the > >TCM that I didn't have before. I also like going beyond 48 modems in a > >chassis. > > > >Tom Swenson > >NetConX - Internet Access - Web Design - Client Managed Web Database > >Applications > >tom@netconx.net http://www.netconx.net > >(515) 421-4170 - Voice (515) 423-3351 - FAX > > > > > >*********** REPLY SEPARATOR *********** > > > >On 1/4/2000 at 11:06 PM meijin@vvm.com wrote: > > > >>I am inheriting an older Total Control system with a total of (I > believe) > >>46 or 48 modems. I come from a background of Portmaster products. So, I > >am > >>curious about software. Is there a Radius server for NT that works with > >>this equipment? Also, is there something that is similar to PMVision? > >That > >>is, allows me to monitor the modems and who is on them and such from the > >>PC? All from an NT environment? Is this stuff bundled with the hardware > >or > >>is it sold extra? Any apps out on the net for this? Any help? > >> > >>Thanks! > >> > >>dr > >> > >> > >>- > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > > > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Total Control Software Questions
From: Tom Swenson <tom@netconx.net>
Date: 2000-01-06 11:28:28

I am currently authenticating to a Linux server with Cistron Radius. If I could ever figure out a way to migrate my users/passwords to NT, I might consider it. I am leary, however, because my two NT servers are not nearly as reliable as my Linux is ( I don't mean to start any OS wars here). I am using Platypus as a accounting program and I believe that there are Radius version which will authenticate to the SQL Server. This would be kind of nice. Thanks for the reply. Tom Swenson NetConX - Internet Access - Web Design - Client Managed Web Database Applications tom@netconx.net http://www.netconx.net (515) 421-4170 - Voice (515) 423-3351 - FAX *********** REPLY SEPARATOR *********** On 1/6/2000 at 9:25 AM Greg Long wrote: >If your users authenitcate to an NT SAM database then any misspelling of a >username can be logged into the event log. That's how we set it up here. >Alas I am rather new to the job and haven't been over everything (if it >works, leave it alone) > >-Greg > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tom Swenson >Sent: Wednesday, January 05, 2000 12:57 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Total Control Software Questions > > >I also am from a Portmaster background, and was disappointed to find I >couldn't see who was online, how fast, how long, and how idle. I have a >pmwho conversion to a usrwho which is working well, but it won't tell >connect speed or idle time. I have to either telnet into the TC or use TCM >to see how fast. Not very efficient. I also was used to being able to see >a user connecting and be able to see if they were misspelling or putting >@netconx.net on the end of their username, but I can't see it with the >usrwho program. If I'm missing any ways of doing these things, I hope >someone would pass along the secrets. Good luck with your TC's, I like >mine so far except for the monitoring. There is lot's of good info in the >TCM that I didn't have before. I also like going beyond 48 modems in a >chassis. > >Tom Swenson >NetConX - Internet Access - Web Design - Client Managed Web Database >Applications >tom@netconx.net http://www.netconx.net >(515) 421-4170 - Voice (515) 423-3351 - FAX > > >*********** REPLY SEPARATOR *********** > >On 1/4/2000 at 11:06 PM meijin@vvm.com wrote: > >>I am inheriting an older Total Control system with a total of (I believe) >>46 or 48 modems. I come from a background of Portmaster products. So, I >am >>curious about software. Is there a Radius server for NT that works with >>this equipment? Also, is there something that is similar to PMVision? >That >>is, allows me to monitor the modems and who is on them and such from the >>PC? All from an NT environment? Is this stuff bundled with the hardware >or >>is it sold extra? Any apps out on the net for this? Any help? >> >>Thanks! >> >>dr >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) trapped with snmp
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-06 11:30:41

The "Annotation" field can be used as a comment. You can check that the NMC is sending traps by pulling out or inserting a card (other than the NMC)- The card insert traps are enabled by default and are a quick test (as long as you have a card you can play with). The Fan Failure Trap is also enabled by default... HiperDSP trap or log settings at the modem level require a template refresh to take affect (a good reason to have been setting the modem parms using templates instead of directly on the modems). The Span level stuff should not need this though. See if you can get ANY trap out of the NMC to start with. STeve Valiunas "Lon R. Stockton, Jr." <lon@moonstar.com> on 01/06/2000 09:19:15 AM Please respond to usr-tc@lists.xmission.com Sent by: "Lon R. Stockton, Jr." <lon@moonstar.com> cc: (Steve Valiunas/MW/US/3Com) Now that I've (locally) discovered the use of perl and the Net:SNMP module to talk to my TC (HiPer) chassis, I've recently been feeling all godlike and stuff. Of course, when a human experiences a taste of godhood, the PowersThatBe quickly queue up a lesson in humility. Anyway, I'm trying to play with SNMP traps and I must be missing something obvious. Here's the deal: 1) I run snmptrapd (from cmu-snmp-utils-3.5-3) on a handy linux box, telling it to both print the trap and dump inbound packets. 2) I verify operation of #1 by running snmptrap to generate a couple of arbitrary traps. Works great. 3) I go into TCM, pick a HiPerDSP card (selecting the LEDs on the span), and click "Fault->Trap Settings" and select "Trap Enables" 4) There, I set a few choice ones to "enableTrap". Specifically, "Red Alarm", "Loss of Signal", and "Physical State Change". Then I click "Set" and "Ok" to set it and exit. 5) Next, I click "Fault->Trap Destinations", and add an entry for the aforementioned linux box running snmptrapd. 6) I physically unplug the span from the HiPerDSP. Amazingly enough, the LEDS suddenly reflect a Red Alarm. (: 7) The amazement turns to disappointment when I see that my snmptrapd didn't hear anything. Due to my lack of real understanding of the trap destination configuration (umm, not the need for, you understand *grin*), I tried a few different things there. Even though snmptrapd appears to not give a whit about the community string, I tried three: nothing, junk, and the same as my NMC's community. And since I can't find anything in the docs that explains the "Annotation" entry, I also tried nothing, an integer '1', and an arbitrary string. I also verified that the linux box had a listener on the udp:snmp-trap port. All else failed, so it was time to consult the documentation. (: The docs basically told me to do all the stuff I did already. And, typical of docs, stopped short from answering the real question (like WTF is expected for "Annotation"). So, before I scrap the whole idea for now (being unwilling to go to the bother of sticking a hub in between the TC and the linux box so I can stick another packet-sniffin' box in there (a PIA that needs to be done because my LAN is point2point switched ethernet...useless to sniff from other segments)), I thought I'd ask here in case there was anything obvious that I'm leaving out (like maybe the NAC needs a reboot for the trap destination change to take effect or some other tripe). Or if I'm falling into some sort of a hidden, umm, trap. If anyone can slap me with a clue stick, I'd be grateful. (: - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Total Control Software Questions
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-06 11:50:29

Great, another unix bigot... I never said I run only one task per server. I indicated that I would verify that the application did not adversly affect the system environment. Most of my machines run multiple applications, only my test platform is stuck with a buggy app that is not deployed. As far as staying up more than a couple that is more than likely a configuration problem caused by someone who doesn't have a clue. Don't lump everything into one pile when it isn't true and never was. That sort of like saying all 'nix's are great, when in fact many of them are basically flawed out of the box. Superior technical expertise takes the flawed OS and makes a box of gold out of it because they know what they are doing, then they frown on others who can't. This is why there is and will continue to be a digital divide. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Thursday, January 06, 2000 12:00 PM > That's why many ISP's don't use MS for 'Mission Critical' tasks. Why do > you think they invented server farms? NT can't run more than a few days > (memory leaks.. your words) so you put up a whole bunch of servers and > hope they all don't crash at the same time. > > As for one box, one task... well, no. I run RADUIS, secondary DNS, a tech > support web server, and in house mail server off on 96Mb AMD 400 Red Hat > 5.2 box. Has never slowed or rebooted. We authenticate 3K plus calls a > day off it and the NAS has never trapped a radius failure (oh yeah.... > it's an snmp management station UCD-SNMP also). > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Thu, 6 Jan 2000, Mark Thornton wrote: > > > I use the vircom.com radius server and it is very stable. My recomendation > > is to not run the radius on a machine doing other tasks, actually I would > > make the same statement about most mission critical tasks. I have found that > > many NT applications have memory leaks that eventually take down the server. > > The machines that are running known stable code are very reliable, but I do > > have a machine running an application that is problematic in this area. > > > > Mark Thornton > > San Marcos Internet, Inc. > > 512-393-5300 > > > > ----- Original Message ----- > > From: Tom Swenson <tom@netconx.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Thursday, January 06, 2000 11:28 AM > > Subject: RE: (usr-tc) Total Control Software Questions > > > > > > > I am currently authenticating to a Linux server with Cistron Radius. If I > > > could ever figure out a way to migrate my users/passwords to NT, I might > > > consider it. I am leary, however, because my two NT servers are not nearly > > > as reliable as my Linux is ( I don't mean to start any OS wars here). I am > > > using Platypus as a accounting program and I believe that there are Radius > > > version which will authenticate to the SQL Server. This would be kind of > > > nice. > > > > > > Thanks for the reply. > > > > > > Tom Swenson > > > NetConX - Internet Access - Web Design - Client Managed Web Database > > > Applications > > > tom@netconx.net http://www.netconx.net > > > (515) 421-4170 - Voice (515) 423-3351 - FAX > > > > > > > > > *********** REPLY SEPARATOR *********** > > > > > > On 1/6/2000 at 9:25 AM Greg Long wrote: > > > > > > >If your users authenitcate to an NT SAM database then any misspelling of > > > a > > > >username can be logged into the event log. That's how we set it up here. > > > >Alas I am rather new to the job and haven't been over everything (if it > > > >works, leave it alone) > > > > > > > >-Greg > > > > > > > >-----Original Message----- > > > >From: owner-usr-tc@lists.xmission.com > > > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tom Swenson > > > >Sent: Wednesday, January 05, 2000 12:57 PM > > > >To: usr-tc@lists.xmission.com > > > >Subject: Re: (usr-tc) Total Control Software Questions > > > > > > > > > > > >I also am from a Portmaster background, and was disappointed to find I > > > >couldn't see who was online, how fast, how long, and how idle. I have a > > > >pmwho conversion to a usrwho which is working well, but it won't tell > > > >connect speed or idle time. I have to either telnet into the TC or use > > > TCM > > > >to see how fast. Not very efficient. I also was used to being able to see > > > >a user connecting and be able to see if they were misspelling or putting > > > >@netconx.net on the end of their username, but I can't see it with the > > > >usrwho program. If I'm missing any ways of doing these things, I hope > > > >someone would pass along the secrets. Good luck with your TC's, I like > > > >mine so far except for the monitoring. There is lot's of good info in the > > > >TCM that I didn't have before. I also like going beyond 48 modems in a > > > >chassis. > > > > > > > >Tom Swenson > > > >NetConX - Internet Access - Web Design - Client Managed Web Database > > > >Applications > > > >tom@netconx.net http://www.netconx.net > > > >(515) 421-4170 - Voice (515) 423-3351 - FAX > > > > > > > > > > > >*********** REPLY SEPARATOR *********** > > > > > > > >On 1/4/2000 at 11:06 PM meijin@vvm.com wrote: > > > > > > > >>I am inheriting an older Total Control system with a total of (I > > > believe) > > > >>46 or 48 modems. I come from a background of Portmaster products. So, I > > > >am > > > >>curious about software. Is there a Radius server for NT that works with > > > >>this equipment? Also, is there something that is similar to PMVision? > > > >That > > > >>is, allows me to monitor the modems and who is on them and such from the > > > >>PC? All from an NT environment? Is this stuff bundled with the hardware > > > >or > > > >>is it sold extra? Any apps out on the net for this? Any help? > > > >> > > > >>Thanks! > > > >> > > > >>dr > > > >> > > > >> > > > >>- > > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > >> with "unsubscribe usr-tc" in the body of the message. > > > >> For information on digests or retrieving files and old messages send > > > >> "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > >- > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > >- > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Total Control Software Questions
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-06 13:00:02

That's why many ISP's don't use MS for 'Mission Critical' tasks. Why do you think they invented server farms? NT can't run more than a few days (memory leaks.. your words) so you put up a whole bunch of servers and hope they all don't crash at the same time. As for one box, one task... well, no. I run RADUIS, secondary DNS, a tech support web server, and in house mail server off on 96Mb AMD 400 Red Hat 5.2 box. Has never slowed or rebooted. We authenticate 3K plus calls a day off it and the NAS has never trapped a radius failure (oh yeah.... it's an snmp management station UCD-SNMP also). Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 6 Jan 2000, Mark Thornton wrote: > I use the vircom.com radius server and it is very stable. My recomendation > is to not run the radius on a machine doing other tasks, actually I would > make the same statement about most mission critical tasks. I have found that > many NT applications have memory leaks that eventually take down the server. > The machines that are running known stable code are very reliable, but I do > have a machine running an application that is problematic in this area. > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 > > ----- Original Message ----- > From: Tom Swenson <tom@netconx.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, January 06, 2000 11:28 AM > Subject: RE: (usr-tc) Total Control Software Questions > > > > I am currently authenticating to a Linux server with Cistron Radius. If I > > could ever figure out a way to migrate my users/passwords to NT, I might > > consider it. I am leary, however, because my two NT servers are not nearly > > as reliable as my Linux is ( I don't mean to start any OS wars here). I am > > using Platypus as a accounting program and I believe that there are Radius > > version which will authenticate to the SQL Server. This would be kind of > > nice. > > > > Thanks for the reply. > > > > Tom Swenson > > NetConX - Internet Access - Web Design - Client Managed Web Database > > Applications > > tom@netconx.net http://www.netconx.net > > (515) 421-4170 - Voice (515) 423-3351 - FAX > > > > > > *********** REPLY SEPARATOR *********** > > > > On 1/6/2000 at 9:25 AM Greg Long wrote: > > > > >If your users authenitcate to an NT SAM database then any misspelling of > > a > > >username can be logged into the event log. That's how we set it up here. > > >Alas I am rather new to the job and haven't been over everything (if it > > >works, leave it alone) > > > > > >-Greg > > > > > >-----Original Message----- > > >From: owner-usr-tc@lists.xmission.com > > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tom Swenson > > >Sent: Wednesday, January 05, 2000 12:57 PM > > >To: usr-tc@lists.xmission.com > > >Subject: Re: (usr-tc) Total Control Software Questions > > > > > > > > >I also am from a Portmaster background, and was disappointed to find I > > >couldn't see who was online, how fast, how long, and how idle. I have a > > >pmwho conversion to a usrwho which is working well, but it won't tell > > >connect speed or idle time. I have to either telnet into the TC or use > > TCM > > >to see how fast. Not very efficient. I also was used to being able to see > > >a user connecting and be able to see if they were misspelling or putting > > >@netconx.net on the end of their username, but I can't see it with the > > >usrwho program. If I'm missing any ways of doing these things, I hope > > >someone would pass along the secrets. Good luck with your TC's, I like > > >mine so far except for the monitoring. There is lot's of good info in the > > >TCM that I didn't have before. I also like going beyond 48 modems in a > > >chassis. > > > > > >Tom Swenson > > >NetConX - Internet Access - Web Design - Client Managed Web Database > > >Applications > > >tom@netconx.net http://www.netconx.net > > >(515) 421-4170 - Voice (515) 423-3351 - FAX > > > > > > > > >*********** REPLY SEPARATOR *********** > > > > > >On 1/4/2000 at 11:06 PM meijin@vvm.com wrote: > > > > > >>I am inheriting an older Total Control system with a total of (I > > believe) > > >>46 or 48 modems. I come from a background of Portmaster products. So, I > > >am > > >>curious about software. Is there a Radius server for NT that works with > > >>this equipment? Also, is there something that is similar to PMVision? > > >That > > >>is, allows me to monitor the modems and who is on them and such from the > > >>PC? All from an NT environment? Is this stuff bundled with the hardware > > >or > > >>is it sold extra? Any apps out on the net for this? Any help? > > >> > > >>Thanks! > > >> > > >>dr > > >> > > >> > > >>- > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > >> with "unsubscribe usr-tc" in the body of the message. > > >> For information on digests or retrieving files and old messages send > > >> "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Total Control Software Questions
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-06 14:03:09

Okay, okay. I can see this can easily explode on us. As one usr-tc participant to another, please take it to private email. I'm not going to take sides no matter how much I like my favorite OS. Every OS has it's pluses and minuses. There are things that some are better at than others. Each administrator must make his or her own decisions about OS choices and take responsiblity for those choices. No matter how much we may want to get into a discussion about which OS is "better," it's a personal choice not an enforcable anything and most of all, certainly not appropriate for this forum. On Thu, 6 Jan 2000, Mark Thornton wrote: > Date: Thu, 6 Jan 2000 11:50:29 -0600 > From: Mark Thornton <mark@corridor.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Total Control Software Questions > > Great, another unix bigot... I never said I run only one task per server. I > indicated that I would verify that the application did not adversly affect > the system environment. Most of my machines run multiple applications, only > my test platform is stuck with a buggy app that is not deployed. As far as > staying up more than a couple that is more than likely a configuration > problem caused by someone who doesn't have a clue. Don't lump everything > into one pile when it isn't true and never was. That sort of like saying all > 'nix's are great, when in fact many of them are basically flawed out of the > box. Superior technical expertise takes the flawed OS and makes a box of > gold out of it because they know what they are doing, then they frown on > others who can't. This is why there is and will continue to be a digital > divide. > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 > > ----- Original Message ----- > From: Paul Farber <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, January 06, 2000 12:00 PM > Subject: Re: (usr-tc) Total Control Software Questions > > > > That's why many ISP's don't use MS for 'Mission Critical' tasks. Why do > > you think they invented server farms? NT can't run more than a few days > > (memory leaks.. your words) so you put up a whole bunch of servers and > > hope they all don't crash at the same time. > > > > As for one box, one task... well, no. I run RADUIS, secondary DNS, a tech > > support web server, and in house mail server off on 96Mb AMD 400 Red Hat > > 5.2 box. Has never slowed or rebooted. We authenticate 3K plus calls a > > day off it and the NAS has never trapped a radius failure (oh yeah.... > > it's an snmp management station UCD-SNMP also). > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Thu, 6 Jan 2000, Mark Thornton wrote: > > > > > I use the vircom.com radius server and it is very stable. My > recomendation > > > is to not run the radius on a machine doing other tasks, actually I > would > > > make the same statement about most mission critical tasks. I have found > that > > > many NT applications have memory leaks that eventually take down the > server. > > > The machines that are running known stable code are very reliable, but I > do > > > have a machine running an application that is problematic in this area. > > > > > > Mark Thornton > > > San Marcos Internet, Inc. > > > 512-393-5300 > > > > > > ----- Original Message ----- > > > From: Tom Swenson <tom@netconx.net> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Thursday, January 06, 2000 11:28 AM > > > Subject: RE: (usr-tc) Total Control Software Questions > > > > > > > > > > I am currently authenticating to a Linux server with Cistron Radius. > If I > > > > could ever figure out a way to migrate my users/passwords to NT, I > might > > > > consider it. I am leary, however, because my two NT servers are not > nearly > > > > as reliable as my Linux is ( I don't mean to start any OS wars here). > I am > > > > using Platypus as a accounting program and I believe that there are > Radius > > > > version which will authenticate to the SQL Server. This would be kind > of > > > > nice. > > > > > > > > Thanks for the reply. > > > > > > > > Tom Swenson > > > > NetConX - Internet Access - Web Design - Client Managed Web Database > > > > Applications > > > > tom@netconx.net http://www.netconx.net > > > > (515) 421-4170 - Voice (515) 423-3351 - FAX > > > > > > > > > > > > *********** REPLY SEPARATOR *********** > > > > > > > > On 1/6/2000 at 9:25 AM Greg Long wrote: > > > > > > > > >If your users authenitcate to an NT SAM database then any misspelling > of > > > > a > > > > >username can be logged into the event log. That's how we set it up > here. > > > > >Alas I am rather new to the job and haven't been over everything (if > it > > > > >works, leave it alone) > > > > > > > > > >-Greg > > > > > > > > > >-----Original Message----- > > > > >From: owner-usr-tc@lists.xmission.com > > > > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Tom Swenson > > > > >Sent: Wednesday, January 05, 2000 12:57 PM > > > > >To: usr-tc@lists.xmission.com > > > > >Subject: Re: (usr-tc) Total Control Software Questions > > > > > > > > > > > > > > >I also am from a Portmaster background, and was disappointed to find > I > > > > >couldn't see who was online, how fast, how long, and how idle. I have > a > > > > >pmwho conversion to a usrwho which is working well, but it won't tell > > > > >connect speed or idle time. I have to either telnet into the TC or > use > > > > TCM > > > > >to see how fast. Not very efficient. I also was used to being able to > see > > > > >a user connecting and be able to see if they were misspelling or > putting > > > > >@netconx.net on the end of their username, but I can't see it with > the > > > > >usrwho program. If I'm missing any ways of doing these things, I hope > > > > >someone would pass along the secrets. Good luck with your TC's, I > like > > > > >mine so far except for the monitoring. There is lot's of good info in > the > > > > >TCM that I didn't have before. I also like going beyond 48 modems in > a > > > > >chassis. > > > > > > > > > >Tom Swenson > > > > >NetConX - Internet Access - Web Design - Client Managed Web Database > > > > >Applications > > > > >tom@netconx.net http://www.netconx.net > > > > >(515) 421-4170 - Voice (515) 423-3351 - FAX > > > > > > > > > > > > > > >*********** REPLY SEPARATOR *********** > > > > > > > > > >On 1/4/2000 at 11:06 PM meijin@vvm.com wrote: > > > > > > > > > >>I am inheriting an older Total Control system with a total of (I > > > > believe) > > > > >>46 or 48 modems. I come from a background of Portmaster products. > So, I > > > > >am > > > > >>curious about software. Is there a Radius server for NT that works > with > > > > >>this equipment? Also, is there something that is similar to > PMVision? > > > > >That > > > > >>is, allows me to monitor the modems and who is on them and such from > the > > > > >>PC? All from an NT environment? Is this stuff bundled with the > hardware > > > > >or > > > > >>is it sold extra? Any apps out on the net for this? Any help? > > > > >> > > > > >>Thanks! > > > > >> > > > > >>dr > > > > >> > > > > >> > > > > >>- > > > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > >> with "unsubscribe usr-tc" in the body of the message. > > > > >> For information on digests or retrieving files and old messages > send > > > > >> "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > > > > > >- > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > >- > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) hawho
From: Richard Stuplich <dick@dwave.net>
Date: 2000-01-06 14:57:57

As the author of hawho I can admit that I didn't even notice this until you sent this mail. I will work on this and post a fix to the list. Jeremy Gault wrote: > Hi, > > Has anyone noticed that ever since Y2K, everyone shows up > as being online for 0 minutes in hawho? I'm not sure how many > people here use hawho, but I am sure some do. Does anyone > know of a fix for this? Right now when we list our users, it shows > everyone as being connected for 0 minutes. Any help would be > appreciated. > > Jeremy > > Jeremy Gault > Systems Administrator - WingNET Internet Services > http://www.wingnet.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) hawho
From: Jeremy Gault <jgault@wingnet.net>
Date: 2000-01-06 15:23:56

Hi, Has anyone noticed that ever since Y2K, everyone shows up as being online for 0 minutes in hawho? I'm not sure how many people here use hawho, but I am sure some do. Does anyone know of a fix for this? Right now when we list our users, it shows everyone as being connected for 0 minutes. Any help would be appreciated. Jeremy Jeremy Gault Systems Administrator - WingNET Internet Services http://www.wingnet.net

Subject: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Chuck Stace <chuck_stace@mw.3com.com>
Date: 2000-01-06 15:36:59

3Com Customers, HiPerARC Service Release v4.1.22 has been posted to the TotalService website ( http://totalservice.3com.com) and the Software Compatibility Matrix has been updated. HiPer ARC 4.1.22 resolves many problems found since 4.1.59-6 including HiPerbomb DOS Attack and SNMP community string security hole. For more information on the details of this Service Release, please reference the release notes. Both the code and release notes can be found on TotalService in the following location: http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software ( search by Total Control Hubs : Hiper ARC ) This code will be free for download for 90 days. After that 90 days, it will be only be available to customers with a valid service contract. If there are any questions or concerns regarding these changes, please contact 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an area not handled by this number, the TotalService website has contact information for other countries and regions. Please go to the TotalService website and click on 'Contacting Tech Support' for more information. Chuck Stace Customer Service Product Planning Chuck_Stace@3com.com

Subject: Re: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Richard Lorbieski <richard@alpha1.net>
Date: 2000-01-06 15:38:48

What if we have 4.1.32, should we upgrade/downgrade to 4.1.22? Chuck Stace wrote: > > 3Com Customers, > > HiPerARC Service Release v4.1.22 has been posted to the TotalService website ( > http://totalservice.3com.com) and the Software Compatibility Matrix has been > updated. > > HiPer ARC 4.1.22 resolves many problems found since 4.1.59-6 including HiPerbomb > DOS Attack and SNMP community string security hole. > > For more information on the details of this Service Release, please reference > the release notes. Both the code and release notes can be found on TotalService > in the following location: > > http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software > ( search by Total Control Hubs : Hiper ARC ) > > This code will be free for download for 90 days. After that 90 days, it will be > only be available to customers with a valid service contract. > > If there are any questions or concerns regarding these changes, please contact > 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an > area not handled by this number, the TotalService website has contact > information for other countries and regions. Please go to the TotalService > website and click on 'Contacting Tech Support' for more information. > > Chuck Stace > Customer Service Product Planning > Chuck_Stace@3com.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Richard Lorbieski - richard@alpha1.net Chief Technical Officer - Senior System Administrator Alpha1 Internet http://www.alpha1.net 409.731.8236 - 877.4.alpha1 (877.425.7421)

Subject: Re: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Brian Elfert <brian@citilink.com>
Date: 2000-01-06 15:53:46

On Thu, 6 Jan 2000, Richard Lorbieski wrote: > What if we have 4.1.32, should we upgrade/downgrade to 4.1.22? There are two release trains, the 4.1 train and the 4.2 train. You're probably running 4.2.32-1, so you would not want to upgrade. The 4.2 train adds OSPF, but the 4.1 train is more stable. Brian

Subject: Re: (usr-tc) hawho Y2K Fix
From: Richard Stuplich <dick@dwave.net>
Date: 2000-01-06 16:14:19

Silly me... When tm_year wants "The number of years since 1900" it doesn't want "00" for year 2000 it wants 100. All fixed and will even work at y3k, y4k and y5k now as well. Thank you Jeremy for pointing this out. Anyway, it is again available at http://www.dwave.net/arctools/ Jeremy Gault wrote: > Hi, > > Has anyone noticed that ever since Y2K, everyone shows up > as being online for 0 minutes in hawho? I'm not sure how many > people here use hawho, but I am sure some do. Does anyone > know of a fix for this? Right now when we list our users, it shows > everyone as being connected for 0 minutes. Any help would be > appreciated. > > Jeremy > > Jeremy Gault > Systems Administrator - WingNET Internet Services > http://www.wingnet.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Mike Wilker <mikew@ll.net>
Date: 2000-01-06 16:16:35

Is the only difference between 4.1 and 4.2 OSPF? ----- Original Message ----- Sent: Thursday, January 06, 2000 3:53 PM complete) > > > On Thu, 6 Jan 2000, Richard Lorbieski wrote: > > > What if we have 4.1.32, should we upgrade/downgrade to 4.1.22? > > There are two release trains, the 4.1 train and the 4.2 train. > > You're probably running 4.2.32-1, so you would not want to upgrade. > > The 4.2 train adds OSPF, but the 4.1 train is more stable. > > Brian > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) DNS Server Assigned Question
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-06 16:18:55

Don't all versions of the total control units have the ability to assign dns numbers to callers? We have a unit with a netserver, nmc and using quad modems that appears to not be assigning it. I thought they all had the capability for the past couple of years. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) hawho
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-06 16:46:03

At 02:57 PM 1/6/00 -0600, Richard Stuplich wrote: >As the author of hawho I can admit that I didn't even notice this until >you sent this mail. I will work on this and post a fix to the list. Since I've never heard of "hawho"(Hiper Arc Who?), I was going to ask for a URL, but I guess I'll wait and try the one included in the fix notice :) -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Dayton Internet <w8mfd@dayton.net>
Date: 2000-01-06 16:58:13

What if we have 4.2.32-1? (ne040232.dmf) --Rich Adams, President, Dayton Internet Services Inc., Dayton, Ohio-- --w8mfd@dayton.net--www.dayton.net--www.dayton.com--937-586-2500-- On Thu, 6 Jan 2000, Richard Lorbieski wrote: > What if we have 4.1.32, should we upgrade/downgrade to 4.1.22? > > Chuck Stace wrote: > > > > 3Com Customers, > > > > HiPerARC Service Release v4.1.22 has been posted to the TotalService website ( > > http://totalservice.3com.com) and the Software Compatibility Matrix has been > > updated. > > > > HiPer ARC 4.1.22 resolves many problems found since 4.1.59-6 including HiPerbomb > > DOS Attack and SNMP community string security hole. > > > > For more information on the details of this Service Release, please reference > > the release notes. Both the code and release notes can be found on TotalService > > in the following location: > > > > http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software > > ( search by Total Control Hubs : Hiper ARC ) > > > > This code will be free for download for 90 days. After that 90 days, it will be > > only be available to customers with a valid service contract. > > > > If there are any questions or concerns regarding these changes, please contact > > 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an > > area not handled by this number, the TotalService website has contact > > information for other countries and regions. Please go to the TotalService > > website and click on 'Contacting Tech Support' for more information. > > > > Chuck Stace > > Customer Service Product Planning > > Chuck_Stace@3com.com > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > > Richard Lorbieski - richard@alpha1.net > Chief Technical Officer - Senior System Administrator > Alpha1 Internet http://www.alpha1.net > 409.731.8236 - 877.4.alpha1 (877.425.7421) > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-06 17:00:57

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wilker |Sent: Thursday, January 06, 2000 4:17 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting |complete) | | |Is the only difference between 4.1 and 4.2 OSPF? | | For the most part.. There is also support for Frame-Relay, and ATM NICS.. -M

Subject: RE: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-06 17:00:57

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dayton Internet |Sent: Thursday, January 06, 2000 3:58 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting |complete) | | |What if we have 4.2.32-1? (ne040232.dmf) | 4.2 has the security fixes in it. You do not need to go back to 4.1.22 to get them. If you are experiencing problems with 4.2.32 and you do not need OSPF you may consider moving to the 4.1.22 code. There are instructions included in the ZIP file that discuss the REQUIRED configuration deletion when downgrading code versions. -M

Subject: (usr-tc) Init String
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-06 20:16:43

This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BF5882.F3013A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Can someone tell me what chip set the Motorola 56 ACF modem uses. I am = having trouble getting one to connect and would like to disable the v90 = part and see if it helps. Thanks In Advance Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_0007_01BF5882.F3013A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Can someone tell me what chip set the = Motorola 56=20 ACF modem uses. I am having trouble getting one to connect and would = like to=20 disable the v90 part and see if it helps. Thanks In Advance</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A>=20 </FONT></DIV></BODY></HTML> ------=_NextPart_000_0007_01BF5882.F3013A80--

Subject: (usr-tc) (My Bad) init string
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-06 20:41:11

This is a multi-part message in MIME format. ------=_NextPart_000_0020_01BF5886.5DEDF100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry...My Bad...Its a Motorola SM56 AC-L Modem I need init string = for.....Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ----- Original Message -----=20 From: Greg owens=20 To: usr-tc@lists.xmission.com=20 Sent: Thursday, January 06, 2000 8:16 PM Subject: (usr-tc) Init String Can someone tell me what chip set the Motorola 56 ACF modem uses. I am = having trouble getting one to connect and would like to disable the v90 = part and see if it helps. Thanks In Advance Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_0020_01BF5886.5DEDF100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2> <DIV><FONT face=3DArial size=3D2>Sorry...My Bad...Its a Motorola SM56 = AC-L Modem I=20 need init string for.....Thanks</FONT></DIV> <DIV>Greg Owens<BR>Magnolia Internet Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:gowens@magnolia-net.com" = title=3Dgowens@magnolia-net.com>Greg=20 owens</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, January 06, = 2000 8:16=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> (usr-tc) Init = String</DIV> <DIV><BR></DIV> <DIV><FONT face=3DArial size=3D2>Can someone tell me what chip set the = Motorola 56=20 ACF modem uses. I am having trouble getting one to connect and would = like to=20 disable the v90 part and see if it helps. Thanks In = Advance</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A>=20 </FONT></DIV></BLOCKQUOTE></FONT></DIV></BODY></HTML> ------=_NextPart_000_0020_01BF5886.5DEDF100--

Subject: (usr-tc) Radius Accounting problem with one chassis
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-06 21:00:55

I am having a problem with one of my TCH chassis, out of a total of four. The chassis in question is running a hiperarc and two dsp's connected to PRI lines primarily servicing ISDN. The other three are hiperarc w/ 12 quads and two dsp's on T1's. All are running the same level of code. The problem is that the ISDN chassis is losing some of the accounting packets, mainly the stop packets. It appears to occur more frequently with certain users, but I think that is mainly because they log on and off a lot. I don't see this on any of the other chassis's at all. I have compensated for this by using a radius server that monitors the chassis via snmp to keep the active user list accurate. The problem is that if a client tries to log in before the snmp cycle occurs they fail because of too many active sessions. I have another hack for that but something is wrong that needs to be fixed. I have tried two different NT machines in different network configurations (switch vs. hub on same segment), and I have tried a Linux machine configured to receive the radius accounting packets. All have experienced the problem so I have concluded it is in the chassis. I was kinda hoping it was the NT machines, because it is easy to replace;) Anyway, I am lost on what to else look for. All the systems are configured in the same way or at least I think so. Is there a way to do a configuration dump from multiple chassis's and then run them through a comparison? What parts of the system are responsible for generating the stop message? One thing I haven't tried yet is swapping the hiperarcs between chassis's and see if the problem moves. Is this worth a shot or could it be the NMC. All of mine are real old. Thanks for any insight you can offer... Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: Re: (usr-tc) (My Bad) init string
From: Epix Customer <scott@epix.net>
Date: 2000-01-06 22:03:41

This is a multi-part message in MIME format. ------=_NextPart_000_0060_01BF5891.E4AE65C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable AT*MM12 Disables all but 56K on most of the Motorola SM56 's I have dealt with. http://www.modemhelp.org/inits/motorolasm56.html --- Scott Bailey CCNA Epix Internet Services scott@epix.net ----- Original Message -----=20 From: Greg owens=20 To: usr-tc@lists.xmission.com=20 Sent: Thursday, January 06, 2000 9:41 PM Subject: (usr-tc) (My Bad) init string Sorry...My Bad...Its a Motorola SM56 AC-L Modem I need init string = for.....Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_0060_01BF5891.E4AE65C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>AT*MM12 Disables all but 56K on most of the Motorola = SM56=20 's</FONT></DIV> <DIV><FONT size=3D2>I have dealt with.</FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2><A=20 href=3D"http://www.modemhelp.org/inits/motorolasm56.html">http://www.mode= mhelp.org/inits/motorolasm56.html</A></FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>---</FONT></DIV> <DIV><FONT size=3D2>Scott Bailey  CCNA</FONT></DIV> <DIV><FONT size=3D2>Epix Internet Services</FONT></DIV> <DIV><FONT size=3D2><A=20 href=3D"mailto:scott@epix.net">scott@epix.net</A></FONT></DIV> <DIV> </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:gowens@magnolia-net.com" = title=3Dgowens@magnolia-net.com>Greg=20 owens</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, January 06, = 2000 9:41=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> (usr-tc) (My Bad) init = string</DIV> <DIV><BR></DIV> <DIV><FONT face=3DArial size=3D2> <DIV><FONT face=3DArial size=3D2>Sorry...My Bad...Its a Motorola SM56 = AC-L Modem I=20 need init string for.....Thanks</FONT></DIV> <DIV>Greg Owens<BR>Magnolia Internet Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A>=20 </DIV></FONT></DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0060_01BF5891.E4AE65C0--

Subject: Re: (usr-tc) (My Bad) init string
From: Epix Customer <scott@epix.net>
Date: 2000-01-06 22:12:07

This is a multi-part message in MIME format. ------=_NextPart_000_0072_01BF5893.12094F20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Epix Customer=20 To: usr-tc@lists.xmission.com=20 Sent: Thursday, January 06, 2000 10:03 PM Subject: Re: (usr-tc) (My Bad) init string AT*MM12 Disables all but 56K on most of the Motorola SM56 's I have dealt with. http://www.modemhelp.org/inits/motorolasm56.html --- Scott Bailey CCNA Epix Internet Services scott@epix.net Oops, that was supposed to be all 56K. --- Scott Bailey CCNA Epix Internet Services scott@epix.net ------=_NextPart_000_0072_01BF5893.12094F20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV> </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:scott@epix.net" title=3Dscott@epix.net>Epix = Customer</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, January 06, = 2000 10:03=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: (usr-tc) (My Bad) = init=20 string</DIV> <DIV><BR></DIV> <DIV><FONT size=3D2>AT*MM12 Disables all but 56K on most of the = Motorola SM56=20 's</FONT></DIV> <DIV><FONT size=3D2>I have dealt with.</FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2><A=20 = href=3D"http://www.modemhelp.org/inits/motorolasm56.html">http://www.mode= mhelp.org/inits/motorolasm56.html</A></FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>---</FONT></DIV> <DIV><FONT size=3D2>Scott Bailey  CCNA</FONT></DIV> <DIV><FONT size=3D2>Epix Internet Services</FONT></DIV> <DIV><FONT size=3D2><A=20 href=3D"mailto:scott@epix.net">scott@epix.net</A></FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>Oops, that was supposed to be all = 56K.</FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2> <DIV><FONT size=3D2>---</FONT></DIV> <DIV><FONT size=3D2>Scott Bailey  CCNA</FONT></DIV> <DIV><FONT size=3D2>Epix Internet Services</FONT></DIV> <DIV><FONT size=3D2><A=20 = href=3D"mailto:scott@epix.net">scott@epix.net</A></FONT></DIV></FONT></DI= V></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0072_01BF5893.12094F20--

Subject: Re: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-06 22:37:47

Thus spake Mike Wilker >Is the only difference between 4.1 and 4.2 OSPF? And added a couple of new NIC types, one with 2 v.35 wan ports, and one with 4 t1 ports with integrated CSU/DSU...you sacrifice one of your fast ethernet's to get these. Also...as part of adding those NICs, they added frame-relay support. For most people...OSPF is the only real change...and to be honest, I'm not real keen on running OSPF yet...its still rather rough around the edges. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) DNS Server Assigned Question
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-06 22:40:57

Thus spake Greg Coffey >Don't all versions of the total control units have the ability to assign >dns numbers to callers? We have a unit with a netserver, nmc and using >quad modems that appears to not be assigning it. I thought they all had >the capability for the past couple of years. Depends on how far back you want to go to consider it "all." :) Assigned DNS (and WINS) nameservers via IPCP negotiation was written as an informational RFC (note, not standards track) after the original NETServer came out...so...you can go far enough back to not have the support for that...but I seriously doubt you have code that old. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) NOTICE - HiPerARC Service Release 4.1.22 (posting complete)
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-07 08:04:23

4.1.32 is older code 4.1.22 is newer code. If you are talking about 4.2.32 then its totally a different code. Use 4.2.32 if you want to use ospf. Else you are better off with 4.159 or 4.1.22 code. 4.1.59 has security holes which 4.1.22 fixes. krish On Thu, 6 Jan 2000, Richard Lorbieski wrote: > What if we have 4.1.32, should we upgrade/downgrade to 4.1.22? > > Chuck Stace wrote: > > > > 3Com Customers, > > > > HiPerARC Service Release v4.1.22 has been posted to the TotalService website ( > > http://totalservice.3com.com) and the Software Compatibility Matrix has been > > updated. > > > > HiPer ARC 4.1.22 resolves many problems found since 4.1.59-6 including HiPerbomb > > DOS Attack and SNMP community string security hole. > > > > For more information on the details of this Service Release, please reference > > the release notes. Both the code and release notes can be found on TotalService > > in the following location: > > > > http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+software > > ( search by Total Control Hubs : Hiper ARC ) > > > > This code will be free for download for 90 days. After that 90 days, it will be > > only be available to customers with a valid service contract. > > > > If there are any questions or concerns regarding these changes, please contact > > 3Com Technical Support toll-free at 1-800-231-8770. If you are calling from an > > area not handled by this number, the TotalService website has contact > > information for other countries and regions. Please go to the TotalService > > website and click on 'Contacting Tech Support' for more information. > > > > Chuck Stace > > Customer Service Product Planning > > Chuck_Stace@3com.com > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > > Richard Lorbieski - richard@alpha1.net > Chief Technical Officer - Senior System Administrator > Alpha1 Internet http://www.alpha1.net > 409.731.8236 - 877.4.alpha1 (877.425.7421) > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-07 09:08:37

Did you do a reset time on the netserver after setting up the NTP server? krish On Fri, 7 Jan 2000, Kevin Benton wrote: > The NetServer 3.8.1 code running on two of our tc's is not Y2K Compliant. > It's running NTP to accept the time from our time servers and shows the > date to be incorrectly something with the year of 1900. Our HARC's are > doing just fine via NTP. Want to find out if your netserver is reporting > the date correctly? From the Command> prompt, type show time then Enter. > > Due to this fact, I would strongly suggest that 3Com 1) fix this problem > in NTP on the NSC 3.8.1 code, 2) implement a way to set the date and > time from the CLI on the NSC, and 3) remove the YES next to the NetServer > PRI 3.8.1 Y2K Compliance check statement until it's fixed. Both of these > would require new code for the NetServer. The 3Com case number for this > problem is 154529. > > Kevin Benton > Network Administrator > SOTANet LLC, A Voyager.net Company > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-07 09:29:12

The NetServer 3.8.1 code running on two of our tc's is not Y2K Compliant. It's running NTP to accept the time from our time servers and shows the date to be incorrectly something with the year of 1900. Our HARC's are doing just fine via NTP. Want to find out if your netserver is reporting the date correctly? From the Command> prompt, type show time then Enter. Due to this fact, I would strongly suggest that 3Com 1) fix this problem in NTP on the NSC 3.8.1 code, 2) implement a way to set the date and time from the CLI on the NSC, and 3) remove the YES next to the NetServer PRI 3.8.1 Y2K Compliance check statement until it's fixed. Both of these would require new code for the NetServer. The 3Com case number for this problem is 154529. Kevin Benton Network Administrator SOTANet LLC, A Voyager.net Company E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Jamie Orzechowski <mhz@ripnet.com>
Date: 2000-01-07 09:37:34

looks fine on mine ... Command> version U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 Build date: Aug 11 1998 Build time: 13:49:21 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Standard Command> show time January 7, 2000 14:36:20 UT ----- Original Message ----- Sent: Friday, January 07, 2000 9:29 AM > The NetServer 3.8.1 code running on two of our tc's is not Y2K Compliant. > It's running NTP to accept the time from our time servers and shows the > date to be incorrectly something with the year of 1900. Our HARC's are > doing just fine via NTP. Want to find out if your netserver is reporting > the date correctly? From the Command> prompt, type show time then Enter. > > Due to this fact, I would strongly suggest that 3Com 1) fix this problem > in NTP on the NSC 3.8.1 code, 2) implement a way to set the date and > time from the CLI on the NSC, and 3) remove the YES next to the NetServer > PRI 3.8.1 Y2K Compliance check statement until it's fixed. Both of these > would require new code for the NetServer. The 3Com case number for this > problem is 154529. > > Kevin Benton > Network Administrator > SOTANet LLC, A Voyager.net Company > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Clayton Zekelman <clayton@mnsi.net>
Date: 2000-01-07 09:47:40

If your Netserver isn't talking to your NTP server properly, it starts life out at 1900. From the date listed, thats what appears to be happening - February? Sounds to me like it was booted 2 months ago. At 09:49 AM 1/7/00 -0500, you wrote: >Not here....I get: > >Command> ver >U.S. Robotics >Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 > Build date: Aug 11 1998 > Build time: 13:49:21 > > Network Interface Card: Ethernet & Frame Relay Combination (26) > ISDN Interface Card : MUNICH32 (4) > Packet Bus Circuit : Enhanced > >Command> sho time >February 27, 1900 0:40:15 UT > > >Strange, everything else is the same?? > >---Marius > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski >> Sent: Friday, January 07, 2000 9:38 AM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant >> >> >> looks fine on mine ... >> >> Command> version >> U.S. Robotics >> Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 >> Build date: Aug 11 1998 >> Build time: 13:49:21 >> >> Network Interface Card: Ethernet & Frame Relay Combination (26) >> ISDN Interface Card : MUNICH32 (4) >> Packet Bus Circuit : Standard >> >> Command> show time >> January 7, 2000 14:36:20 UT >> >> >> ----- Original Message ----- >> From: Kevin Benton <s1kevin@tims.net> >> To: <usr-tc@lists.xmission.com> >> Sent: Friday, January 07, 2000 9:29 AM >> Subject: (usr-tc) NetServer 3.8.1 not Y2K Compliant >> >> >> > The NetServer 3.8.1 code running on two of our tc's is not Y2K >> Compliant. >> > It's running NTP to accept the time from our time servers and shows the >> > date to be incorrectly something with the year of 1900. Our HARC's are >> > doing just fine via NTP. Want to find out if your netserver is >> reporting >> > the date correctly? From the Command> prompt, type show time >> then Enter. >> > >> > Due to this fact, I would strongly suggest that 3Com 1) fix this problem >> > in NTP on the NSC 3.8.1 code, 2) implement a way to set the date and >> > time from the CLI on the NSC, and 3) remove the YES next to the >> NetServer >> > PRI 3.8.1 Y2K Compliance check statement until it's fixed. >> Both of these >> > would require new code for the NetServer. The 3Com case number for this >> > problem is 154529. >> > >> > Kevin Benton >> > Network Administrator >> > SOTANet LLC, A Voyager.net Company >> > >> > E-Mail: s1kevin@tims.net >> > Web: http://users.sota-oh.com/~s1kevin/ >> > Unsolicited advertisements processing fee: $50 subject to change without >> notice >> > >> > >> > - >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: RE: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Marius Kirschner <marius@agoron.com>
Date: 2000-01-07 09:49:00

Not here....I get: Command> ver U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 Build date: Aug 11 1998 Build time: 13:49:21 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced Command> sho time February 27, 1900 0:40:15 UT Strange, everything else is the same?? ---Marius > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski > Sent: Friday, January 07, 2000 9:38 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant > > > looks fine on mine ... > > Command> version > U.S. Robotics > Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 > Build date: Aug 11 1998 > Build time: 13:49:21 > > Network Interface Card: Ethernet & Frame Relay Combination (26) > ISDN Interface Card : MUNICH32 (4) > Packet Bus Circuit : Standard > > Command> show time > January 7, 2000 14:36:20 UT > > > ----- Original Message ----- > From: Kevin Benton <s1kevin@tims.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 07, 2000 9:29 AM > Subject: (usr-tc) NetServer 3.8.1 not Y2K Compliant > > > > The NetServer 3.8.1 code running on two of our tc's is not Y2K > Compliant. > > It's running NTP to accept the time from our time servers and shows the > > date to be incorrectly something with the year of 1900. Our HARC's are > > doing just fine via NTP. Want to find out if your netserver is > reporting > > the date correctly? From the Command> prompt, type show time > then Enter. > > > > Due to this fact, I would strongly suggest that 3Com 1) fix this problem > > in NTP on the NSC 3.8.1 code, 2) implement a way to set the date and > > time from the CLI on the NSC, and 3) remove the YES next to the > NetServer > > PRI 3.8.1 Y2K Compliance check statement until it's fixed. > Both of these > > would require new code for the NetServer. The 3Com case number for this > > problem is 154529. > > > > Kevin Benton > > Network Administrator > > SOTANet LLC, A Voyager.net Company > > > > E-Mail: s1kevin@tims.net > > Web: http://users.sota-oh.com/~s1kevin/ > > Unsolicited advertisements processing fee: $50 subject to change without > notice > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-07 09:51:46

Thus spake Kevin Benton >Due to this fact, I would strongly suggest that 3Com 1) fix this >problem in NTP on the NSC 3.8.1 code, Too bad they don't have source code to the NETServer/ComOS based code anymore to be able to make such fixes. If this turns out to be true...and I haven't a clue if it is or not...I saw another post indicating that this might not be a problem...perhaps 3Com will finally do the right thing for people with NETServers. Hah...fat chance, I know...but I can dream. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Marius Kirschner <marius@agoron.com>
Date: 2000-01-07 09:59:55

Good point...how do I add an entry fon an NTP server? ---Marius > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Clayton Zekelman > Sent: Friday, January 07, 2000 9:48 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) NetServer 3.8.1 not Y2K Compliant > > > If your Netserver isn't talking to your NTP server properly, it > starts life > out at 1900. From > the date listed, thats what appears to be happening - February? Sounds to > me like it was booted 2 months ago.

Subject: RE: (usr-tc) (My Bad) init string
From: Greg Long <greg@coastlink.com>
Date: 2000-01-07 10:49:18

This is a multi-part message in MIME format. ------=_NextPart_000_0012_01BF58FC.E76015A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I don't if it will have what you are looking for but here is a link to the Motorola website product specs: http://www.motorola.com/networking/products/sm56_ac-l/index.html -Greg -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg owens Sent: Thursday, January 06, 2000 7:41 PM Sorry...My Bad...Its a Motorola SM56 AC-L Modem I need init string for.....Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com ----- Original Message ----- Sent: Thursday, January 06, 2000 8:16 PM Can someone tell me what chip set the Motorola 56 ACF modem uses. I am having trouble getting one to connect and would like to disable the v90 part and see if it helps. Thanks In Advance Greg Owens Magnolia Internet Services http://www.magnolia-net.com ------=_NextPart_000_0012_01BF58FC.E76015A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D350014917-07012000>I=20 don't if it will have what you are looking for but here is a link to the = Motorola website product specs:</SPAN></FONT></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D350014917-07012000><A=20 href=3D"http://www.motorola.com/networking/products/sm56_ac-l/index.html"= >http://www.motorola.com/networking/products/sm56_ac-l/index.html</A></SP= AN></FONT></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D350014917-07012000></SPAN></FONT> </DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D350014917-07012000>-Greg</SPAN></FONT></DIV> <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"> <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B>=20 owner-usr-tc@lists.xmission.com = [mailto:owner-usr-tc@lists.xmission.com]<B>On=20 Behalf Of </B>Greg owens<BR><B>Sent:</B> Thursday, January 06, 2000 = 7:41=20 PM<BR><B>To:</B> usr-tc@lists.xmission.com<BR><B>Subject:</B> (usr-tc) = (My=20 Bad) init string<BR><BR></DIV></FONT> <DIV><FONT face=3DArial size=3D2> <DIV><FONT face=3DArial size=3D2>Sorry...My Bad...Its a Motorola SM56 = AC-L Modem I=20 need init string for.....Thanks</FONT></DIV> <DIV>Greg Owens<BR>Magnolia Internet Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; = MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:gowens@magnolia-net.com" = title=3Dgowens@magnolia-net.com>Greg=20 owens</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> = </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Thursday, January 06, = 2000 8:16=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> (usr-tc) Init = String</DIV> <DIV><BR></DIV> <DIV><FONT face=3DArial size=3D2>Can someone tell me what chip set = the Motorola=20 56 ACF modem uses. I am having trouble getting one to connect and = would like=20 to disable the v90 part and see if it helps. Thanks In = Advance</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </FONT></DIV></BLOCKQUOTE></FONT></DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0012_01BF58FC.E76015A0--

Subject: RE: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-07 10:57:21

mine all seem to be working fine with NTP... Command> sho time January 7, 2000 14:56:46 UT Command> ver U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 Build date: Aug 11 1998 Build time: 13:49:21 Network Interface Card: Ethernet & Frame Relay Combination (26) ISDN Interface Card : MUNICH32 (4) Packet Bus Circuit : Enhanced Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Kevin Benton [mailto:s1kevin@tims.net] > Sent: Friday, January 07, 2000 10:29 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) NetServer 3.8.1 not Y2K Compliant > > > The NetServer 3.8.1 code running on two of our tc's is not > Y2K Compliant. > It's running NTP to accept the time from our time servers and > shows the > date to be incorrectly something with the year of 1900. Our > HARC's are > doing just fine via NTP. Want to find out if your netserver > is reporting > the date correctly? From the Command> prompt, type show time > then Enter. > > Due to this fact, I would strongly suggest that 3Com 1) fix > this problem > in NTP on the NSC 3.8.1 code, 2) implement a way to set the date and > time from the CLI on the NSC, and 3) remove the YES next to > the NetServer > PRI 3.8.1 Y2K Compliance check statement until it's fixed. > Both of these > would require new code for the NetServer. The 3Com case > number for this > problem is 154529. > > Kevin Benton > Network Administrator > SOTANet LLC, A Voyager.net Company > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to > change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-07 12:08:41

Hey..your right. Mine shows: Command> sh time January 23, 1900 21:45: 6 UT ----- Original Message ----- Sent: Friday, January 07, 2000 9:47 AM > If your Netserver isn't talking to your NTP server properly, it starts life > out at 1900. From > the date listed, thats what appears to be happening - February? Sounds to > me like it was booted 2 months ago. > > > At 09:49 AM 1/7/00 -0500, you wrote: > >Not here....I get: > > > >Command> ver > >U.S. Robotics > >Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 > > Build date: Aug 11 1998 > > Build time: 13:49:21 > > > > Network Interface Card: Ethernet & Frame Relay Combination (26) > > ISDN Interface Card : MUNICH32 (4) > > Packet Bus Circuit : Enhanced > > > >Command> sho time > >February 27, 1900 0:40:15 UT > > > > > >Strange, everything else is the same?? > > > >---Marius > > > >> -----Original Message----- > >> From: owner-usr-tc@lists.xmission.com > >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski > >> Sent: Friday, January 07, 2000 9:38 AM > >> To: usr-tc@lists.xmission.com > >> Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant > >> > >> > >> looks fine on mine ... > >> > >> Command> version > >> U.S. Robotics > >> Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.8.1 > >> Build date: Aug 11 1998 > >> Build time: 13:49:21 > >> > >> Network Interface Card: Ethernet & Frame Relay Combination (26) > >> ISDN Interface Card : MUNICH32 (4) > >> Packet Bus Circuit : Standard > >> > >> Command> show time > >> January 7, 2000 14:36:20 UT > >> > >> > >> ----- Original Message ----- > >> From: Kevin Benton <s1kevin@tims.net> > >> To: <usr-tc@lists.xmission.com> > >> Sent: Friday, January 07, 2000 9:29 AM > >> Subject: (usr-tc) NetServer 3.8.1 not Y2K Compliant > >> > >> > >> > The NetServer 3.8.1 code running on two of our tc's is not Y2K > >> Compliant. > >> > It's running NTP to accept the time from our time servers and shows the > >> > date to be incorrectly something with the year of 1900. Our HARC's are > >> > doing just fine via NTP. Want to find out if your netserver is > >> reporting > >> > the date correctly? From the Command> prompt, type show time > >> then Enter. > >> > > >> > Due to this fact, I would strongly suggest that 3Com 1) fix this problem > >> > in NTP on the NSC 3.8.1 code, 2) implement a way to set the date and > >> > time from the CLI on the NSC, and 3) remove the YES next to the > >> NetServer > >> > PRI 3.8.1 Y2K Compliance check statement until it's fixed. > >> Both of these > >> > would require new code for the NetServer. The 3Com case number for this > >> > problem is 154529. > >> > > >> > Kevin Benton > >> > Network Administrator > >> > SOTANet LLC, A Voyager.net Company > >> > > >> > E-Mail: s1kevin@tims.net > >> > Web: http://users.sota-oh.com/~s1kevin/ > >> > Unsolicited advertisements processing fee: $50 subject to change without > >> notice > >> > > >> > > >> > - > >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> > with "unsubscribe usr-tc" in the body of the message. > >> > For information on digests or retrieving files and old messages send > >> > "help" to the same address. Do not use quotes in your message. > >> > > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > --- > Clayton Zekelman > Managed Network Systems Inc. (MNSi) > 875 Ouellette Avenue > Windsor, Ontario > N9A 4J6 > > tel. 519-985-8410 > fax. 519-258-3009 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Transmitter levels
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-07 14:58:05

Anyone have a clue as to the correct ( if there is even such a thing ) settings on the dsp's. On all code previous to 2.0.51 the the default has been 11db. I have experimented with using a setting of 13db, 2 db lower power. Don't really know how this has affected the overall problem that i'm trying to solve of disconnects. I came to setting from trials with multitech analog modems. Changing from 11 to 13 on those solved a ton of problems. So i was surprised to see the default setting for 2.0.51 set to 10. What are you guys running or do you even bother setting these levels?

Subject: (usr-tc) v.42bis problems
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-07 16:51:52

An old problem has just come back, but in only one weird case. I've got a crapload of people getting randomly bumped offline with v.42 or v.42bis related problems. (I suspect v.42bis.) However... it's only happening on the first 12 channels of ONE DSP card. It's not happening on the other 11 channels of that card, or of any other card in that city or any other city. The card is configured *identically* to the others in every way I can think of checking -- all DSP's are running 2.0.51, though they have varying hardware revisions. The card in question is revision 0.49. Just from midnight to 4:30 pm today on these 12 channels, I've had 310 disconnects for "v.42 string too long", 63 disconnects for "v.42 invalid codeword", and 17 disconnects for "Link security abort". It doesn't matter what brand of modem the client is calling in with. It could be a cheap Winmodem, it could be a USR Courier. It definitely happens with USR modems. For now I've disabled v.42bis on this card until I can figure out what's going on. Disabling v.42bis stops the disconnects. I seem to remember having this problem once quite a while ago, but it was more widespread then... it had popped up right after a DSP firmware upgrade (I think to 1.2.68 at the time). And this has popped up right after going from 2.0.60 to 2.0.51 -- but again, only on half of one card. Ideas? Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear."

Subject: (usr-tc) Re: Net Server Y2K compliance
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-07 17:26:38

On Fri, 7 Jan 2000, Ivan Baby wrote: > You are correct with your assessment of the Y2K status of NetServer 3.8.1. > NetServer 3.8.1 is compliant through the year 2035. NetServer does not maintain > its own clock but is dependent on an NTP server for the time. Has anyone asked > the customer to display the time on their NTP server to see if it is correct? If this is true, then why does a show time show a date of something in 1900 on both NetServers we're using? Why is the clock so far off? How can I get it set properly? My ARC's are doing just fine with NTP. NTP is being served by a local Linux box which is itself served by Ohio State University and Washington State University time servers (with a maximum 30 second difference) once every 24 hours. Are you saying my NTP is broken? E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) Re: Net Server Y2K compliance
From: Clayton Zekelman <clayton@mnsi.net>
Date: 2000-01-07 17:32:43

>second difference) once every 24 hours. Are you saying my NTP is broken? Is it possible that you don't have NTP set up correctly on the Netservers? I know that prior to implementing NTP, my Netservers showed 1900, even in 1998. Once the settings were entered, configuration saved and the cards rebooted, the time updated, and displayed properly. > >E-Mail: s1kevin@tims.net >Web: http://users.sota-oh.com/~s1kevin/ >Unsolicited advertisements processing fee: $50 subject to change without notice > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) v.42bis problems
From: Clayton Zekelman <clayton@mnsi.net>
Date: 2000-01-07 17:34:32

Have you tried resetting the card, or reflashing? At 04:51 PM 1/7/00 -0500, you wrote: >An old problem has just come back, but in only one weird case. > >I've got a crapload of people getting randomly bumped offline with v.42 or >v.42bis related problems. (I suspect v.42bis.) > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: (usr-tc) Re..(My Bad) init string
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-07 19:10:15

This is a multi-part message in MIME format. ------=_NextPart_000_001F_01BF5942.D49F8180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks....I actually hooked up another Gateway identical to the one = yesterday (The new one that has monitor, hard drive etc all in one = chassis) today and their modem worked great. I'm beginning to believe = that old MaBell has struck again with another crummy phone line. But = appreciate the link Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ----- Original Message -----=20 From: Greg Long=20 To: usr-tc@lists.xmission.com=20 Sent: Friday, January 07, 2000 11:49 AM Subject: RE: (usr-tc) (My Bad) init string I don't if it will have what you are looking for but here is a link to = the Motorola website product specs: http://www.motorola.com/networking/products/sm56_ac-l/index.html =20 -Greg -----Original Message----- From: owner-usr-tc@lists.xmission.com = [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg owens Sent: Thursday, January 06, 2000 7:41 PM To: usr-tc@lists.xmission.com Subject: (usr-tc) (My Bad) init string Sorry...My Bad...Its a Motorola SM56 AC-L Modem I need init string = for.....Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_001F_01BF5942.D49F8180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2> <DIV><FONT face=3DArial size=3D2>Thanks....I actually hooked up another = Gateway=20 identical to the one yesterday (The new one that has monitor, hard drive = etc all=20 in one chassis) today and their modem worked great. I'm beginning to = believe=20 that old MaBell has struck again with another crummy phone line. But = appreciate=20 the link</FONT></DIV> <DIV>Greg Owens<BR>Magnolia Internet Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:greg@coastlink.com" title=3Dgreg@coastlink.com>Greg = Long</A>=20 </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, January 07, 2000 = 11:49=20 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: (usr-tc) (My Bad) = init=20 string</DIV> <DIV><BR></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D350014917-07012000>I=20 don't if it will have what you are looking for but here is a link to = the=20 Motorola website product specs:</SPAN></FONT></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D350014917-07012000><A=20 = href=3D"http://www.motorola.com/networking/products/sm56_ac-l/index.html"= >http://www.motorola.com/networking/products/sm56_ac-l/index.html</A></SP= AN></FONT></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D350014917-07012000></SPAN></FONT> </DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D350014917-07012000>-Greg</SPAN></FONT></DIV> <BLOCKQUOTE style=3D"MARGIN-RIGHT: 0px"> <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT = face=3DTahoma=20 size=3D2>-----Original Message-----<BR><B>From:</B> <A=20 = href=3D"mailto:owner-usr-tc@lists.xmission.com">owner-usr-tc@lists.xmissi= on.com</A>=20 [<A=20 = href=3D"mailto:owner-usr-tc@lists.xmission.com">mailto:owner-usr-tc@lists= .xmission.com</A>]<B>On=20 Behalf Of </B>Greg owens<BR><B>Sent:</B> Thursday, January 06, 2000 = 7:41=20 PM<BR><B>To:</B> usr-tc@lists.xmission.com<BR><B>Subject:</B> = (usr-tc) (My=20 Bad) init string<BR><BR></DIV></FONT> <DIV><FONT face=3DArial size=3D2> <DIV><FONT face=3DArial size=3D2>Sorry...My Bad...Its a Motorola = SM56 AC-L Modem=20 I need init string for.....Thanks</FONT></DIV> <DIV>Greg Owens<BR>Magnolia Internet Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </DIV></FONT></FONT><FONT face=3DArial size=3D2>Greg = Owens<BR>Magnolia Internet=20 Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </FONT></DIV></BLOCKQUOTE></BLOCKQUOTE></DIV></BODY></HTML> ------=_NextPart_000_001F_01BF5942.D49F8180--

Subject: Re: (usr-tc) Re: Net Server Y2K compliance
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-07 19:59:40

Thus spake Kevin Benton >On Fri, 7 Jan 2000, Ivan Baby wrote: >> You are correct with your assessment of the Y2K status of NetServer >> 3.8.1. NetServer 3.8.1 is compliant through the year 2035. NetServer >> does not maintain its own clock but is dependent on an NTP server for >> the time. Has anyone asked the customer to display the time on their >> NTP server to see if it is correct? >If this is true, then why does a show time show a date of something in >1900 on both NetServers we're using? Why is the clock so far off? How >can I get it set properly? My ARC's are doing just fine with NTP. NTP >is being served by a local Linux box which is itself served by Ohio >State University and Washington State University time servers (with a >maximum 30 second difference) once every 24 hours. Are you saying my >NTP is broken? What's the command that you're using on your Linux box to sync with OSU and Washington State? The way you said it sounds like its being synced with ntpdate once a day, rather than letting ntpd run and adjust it constantly. I *believe* that ntpd will not serve as a time sync source for other systems if its not actively synced up with its own time sources...ie, running ntpdate once a day doesn't hack it. :) Perhaps you're aware of this and I'm misinterpreting your message. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) cisco 804 to total-control hiperarc
From: Laszlo Vecsey <master@internexus.net>
Date: 2000-01-07 22:38:50

I have a customer attempting to dial up with an isdn cisco 804 unit, to a total control hiperarc (quad modems). The connection is established and I see the authentication show up in the radius server log, but then the connection gets dropped. The user and pass is accepted ok. I monitored the ppp call events on the hiperarc, and as the call comes in it says almost instantly that the Peer does not have any IP protocol set, so DISABLING. Any idea why that might be?

Subject: Re: (usr-tc) hawho
From: Richard Stuplich <dick@dwave.net>
Date: 2000-01-07 23:40:37

I'll go into the hawho and hacom a bit. But let me start by saying that I didn't know anyone else used them. I think I wrote to the list once and got no real feedback. * hawho is a "pmwho" edit that makes a hyperarc return pmwho output like so: $ hawho tc2 Port User Host/Inet/Dest Type Dir Status Start Idle ---- --------------- ---------------- ------- --- ------------- ------ ------ Saa rlanhhin 12.20.66.44 Netwrk In ESTABLISHED 4:08 0 Sab g1p1r1 12.20.66.28 Netwrk In ESTABLISHED 39 0 Sac godsim 12.20.66.87 Netwrk In ESTABLISHED 15:30 0 ... Note that the Port is not a number but 2 letters. The 'S' is to act like a portmaster 'sh ses" and the first letter after the S is the card and the 2nd letter is the port on that card. I had to find a way to get the port on the hyperarc to fit into the portmaster's lengths so everything can get processed the same by other scripts I already had for portmasters. The time connected 'Start' column is correct now after the y2k fix. The Idle is always '0' because USR and now 3com don't think we need to be able to get that information, or they just don't care. (Perhaps this is too harsh, maybe they added a way to get that information now, I never cared to look again in any of the new firmware commands or SNMP mibs). The real reason for these scripts is that there was no real good way of finding this information and as I had MANY scripts for protmasters already finished I wasn't gonna go and fix them to make everything work. I thought it best to fix the hyperarc output and then use my old tools. Also I couldn't find a way to get how long each user had been connected because the command in the hyperarc only shows when they logged in. I do a commend to get the time it thinks it is and then I subtract the users time they connected to get the time they have been online. Something I don't want to have to do by hand when I need this information. * hacom is a pmcom conversion. It allows you a way to - oh, dump a user from a unix command line. Something I needed. http://www.dwave.net/arctools You can get my real feelings from the source code of hawho. You will be able to tell how much I liked the hyperarc from reading that. And as always, without the work of the people who created pmwho and pmcom these programs wouldn't be available. They are the real programmers that made hawho and hacom available. K Mitchell wrote: > At 02:57 PM 1/6/00 -0600, Richard Stuplich wrote: > >As the author of hawho I can admit that I didn't even notice this until > >you sent this mail. I will work on this and post a fix to the list. > > Since I've never heard of "hawho"(Hiper Arc Who?), I was going to ask for a > URL, but I guess I'll wait and try the one included in the fix notice :) > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) cisco 804 to total-control hiperarc
From: Blake Fithen <fithen@networksplus.com>
Date: 2000-01-07 23:41:19

not sure whats going on there but we have the same setup except DSP's instead of quads. never have problems with the 800's. here's my configs - the ppp auth. config on the Cisco is a little wierd but thats the only way I could get auth. requests answered by the ARC. Hope this helps!!!!!! Current configuration: ! version 12.0 no service pad service timestamps debug datetime msec localtime show-timezone service timestamps log datetime localtime show-timezone service password-encryption ! hostname xxx ! username xxx password yyy ! ip subnet-zero ! isdn switch-type basic-ni ! interface Ethernet0 ip address 10.0.0.80 255.255.255.0 no ip directed-broadcast ip nat inside no cdp enable ! interface BRI0 no ip address no ip directed-broadcast ip nat outside encapsulation ppp dialer rotary-group 1 isdn switch-type basic-ni isdn spid1 xxxxxxxxxxxxxx xxxxxxx isdn voice-priority xxxxxxx in always isdn incoming-voice modem no cdp enable ! interface Dialer1 description ISP ip address negotiated no ip directed-broadcast no ip proxy-arp ip nat outside encapsulation ppp no ip split-horizon dialer in-band dialer idle-timeout 9000 dialer string xxxxxxx dialer load-threshold 1 either dialer-group 1 no cdp enable ppp authentication pap callin ppp chap password yyy ppp pap sent-username xxx password yyy ppp multilink ! ip nat inside source list 1 interface Dialer1 overload ip http server ip classless ip route 0.0.0.0 0.0.0.0 Dialer1 ! access-list 1 permit 10.0.0.0 0.0.0.255 dialer-list 1 protocol ip permit no cdp run ! line con 0 exec-timeout 0 0 transport input none stopbits 1 line vty 0 4 password yyy login ! end tpk-32.7> sh ppp PPP AUTHENTICATION DIAL_IN Users Authenticate: PAP PPP Authentication Preference: DEFAULT System Transmit Authentication Name: xxxx PPP offloading: DISABLED CCP will be attempted for call type(s): NONE Primary NBNS Server address: 0.0.0.0 Secondary NBNS Server address: 0.0.0.0 DNS configuration Usage: SYSTEM Primary PPP DNS Server address: 0.0.0.0 Secondary PPP DNS Server address: 0.0.0.0 PPP session start message: PPP session from %server_ip to %client _ip beginning.... Send Accounting for PPP Abnormal Disc: DISABLED PPP Address Field Compression: ENABLED PPP Protocol Field Compression: ENABLED PPP Multilink PPP: ENABLED PPP BACP and BAP: DISABLED PPP Bap Hunt Group Phone Number: PPP Receive ACCM: DISABLED > -----Original Message----- > From: Laszlo Vecsey [mailto:master@internexus.net] > Sent: Friday, January 07, 2000 9:39 PM > To: usr-tc@xmission.com > Subject: (usr-tc) cisco 804 to total-control hiperarc > > > > I have a customer attempting to dial up with an isdn cisco > 804 unit, to a > total control hiperarc (quad modems). The connection is > established and I > see the authentication show up in the radius server log, but then the > connection gets dropped. The user and pass is accepted ok. > > I monitored the ppp call events on the hiperarc, and as the > call comes in > it says almost instantly that the Peer does not have any IP > protocol set, > so DISABLING. Any idea why that might be? > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) cisco 804 to total-control hiperarc
From: Blake Fithen <fithen@networksplus.com>
Date: 2000-01-07 23:41:19

Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 2000-01-08 08:41:45

> The NetServer 3.8.1 code running on two of our tc's is not Y2K > Compliant. It's running NTP to accept the time from our time servers > and shows the date to be incorrectly something with the year of 1900. Hmmm, we have 10 units operating at the moment, all using NTP, and they're all spot on. This must either be a really obscure bug, or be configuration dependent. > would require new code for the NetServer. The 3Com case number for > this problem is 154529. Let us all know if they make new code available to fix it :-) Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

Subject: Re: (usr-tc) Re: Net Server Y2K compliance
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-08 08:58:31

On Sat, 8 Jan 2000, Bob Purdon (Lists) wrote: > > > second difference) once every 24 hours. Are you saying my NTP is broken? > > Not necessarily that your NTP is broken, but that your NETserver cards are > having trouble talking to it. We use NTP here with our NETserver cards > and every card is fine. > > The symptoms presented so far, as well as the 'me to' and 'not here' > comments from others, suggest that this is probably configuration > dependent. > > Of course it *may* be a NETserver bug, but the evidence so far suggests > configuration is more likely. Its not a NETServer bug. Its configuration - also its not a y2k bug for the NETServer does still work and does not use NTP to anything other than MPIP, so if all of your NETServers are showing the same time - your MPIP will also work fine. Check your configuration, make sure that your NTP works, do a reset time on the NETSErver - if all this does not work - do a erase flash on the NETServer and reconfigure the same. krish > > ------------------------------------------------------------------------ > Bob Purdon, Ground Floor, Marine Board Building > Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 > Southern Internet Services. +61 (3) 6234 7444 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) v.42bis problems
From: Horace Demmink <horace@pathwaynet.com>
Date: 2000-01-08 14:07:55

On Fri, 7 Jan 2000, Mike Andrews wrote: > An old problem has just come back, but in only one weird case. > > I've got a crapload of people getting randomly bumped offline with v.42 or > v.42bis related problems. (I suspect v.42bis.) > > However... it's only happening on the first 12 channels of ONE DSP card. > I had a similar problem that turned out to be a DSP hardware problem. One of my DSP's would, after moderate use, not answer on the first 12 channels until it was reset. I had flashed several different versions of code, tried different lines (CT1 and PRI), different locations, chassis's, etc. Nothing made a difference. After jerking around with 3COM's RMA dept for a while (you can't RMA it until a tech says it's bad, you can't talk to a tech without a contract) my vendor offered to RMA it for me. I have not seen this symptom pop up on any other cards I have. -- Horace Demmink PathWay Computing

Subject: Re: (usr-tc) Re: Net Server Y2K compliance
From: Bob Purdon (Lists) <lists@aussie.nu>
Date: 2000-01-08 17:54:56

> second difference) once every 24 hours. Are you saying my NTP is broken? Not necessarily that your NTP is broken, but that your NETserver cards are having trouble talking to it. We use NTP here with our NETserver cards and every card is fine. The symptoms presented so far, as well as the 'me to' and 'not here' comments from others, suggest that this is probably configuration dependent. Of course it *may* be a NETserver bug, but the evidence so far suggests configuration is more likely. Bob Purdon, Ground Floor, Marine Board Building Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 Southern Internet Services. +61 (3) 6234 7444

Subject: RE: (usr-tc) DNS Server Assigned Question
From: Kevin Tucker <klt@tucker-usa.com>
Date: 2000-01-08 20:07:49

Auto assigning DNS: I have never got this to work. What is the procedure? KLT -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Mcadams Sent: Thursday, January 06, 2000 10:41 PM Thus spake Greg Coffey >Don't all versions of the total control units have the ability to assign >dns numbers to callers? We have a unit with a netserver, nmc and using >quad modems that appears to not be assigning it. I thought they all had >the capability for the past couple of years. Depends on how far back you want to go to consider it "all." :) Assigned DNS (and WINS) nameservers via IPCP negotiation was written as an informational RFC (note, not standards track) after the original NETServer came out...so...you can go far enough back to not have the support for that...but I seriously doubt you have code that old. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) changing IP pool
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-09 03:19:53

I want to change the IP pool on my chassis from one class C to another one, while leaving the ARC and NMC with their original IPs from the first class C. Will simply resetting the IP pool in ARC work ok, or do I need to make any special provisions for the changeover? Will the ARC still route to the old addresses on current calls? Thanks, -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) changing IP pool
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-09 09:12:56

On Sun, 9 Jan 2000, K Mitchell wrote: > I want to change the IP pool on my chassis from one class C to another > one, while leaving the ARC and NMC with their original IPs from the first > class C. Will simply resetting the IP pool in ARC work ok, or do I need to > make any special provisions for the changeover? Will the ARC still route to > the old addresses on current calls? Well - you will have to first create a new IP pool with the new IP address, and then disable the first IP pool. If you have users currently dialed in - they will be using the first IP pool - thus you cannot disable and delete the pool. krish > > Thanks, > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Second request --dsp transmitter levels
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-09 09:58:33

Since noone replied to the first request for info on this I take it 1) noneone else IS messing with these settings or 2)noone HAS been messing with these settings or 3) Everyone simply ignored the mail. So I'll ask once again and then leave it alone on this list. A few revisions back, can't remember how far, the dsp code started to allow setting of the transmiter power levels. This was under line interface options, transmitter level (-db), the same as the quads used to have. They also had the same -11db setting as the quads did. I have had better luck with the quads ( and some old analog multitech modems ) by lowering the power level to -13db. It helped two different problems, disconnects and the long training sessions that never would connect. I was about to start changing these levels to -13db when I noticed that 3com has changed the default setting from -11db to -10db in 2.0.51. In all previuos releases they were set at -11db. Anyone out have any input on this? Does anyone know how to get measurements from the ct1s to determine what the correct level should be? Terry Kennedy OlyPen, Inc.

Subject: Re: (usr-tc) Second request --dsp transmitter levels
From: Rob Nelson <rob@mag-net.com>
Date: 2000-01-09 11:16:53

Terry Kennedy wrote: > A few revisions back, can't remember how far, the dsp code started to allow > setting of the transmiter power levels. This was under line interface > options, transmitter level (-db), the same as the quads used to have. They > also had the same -11db setting as the quads did. I have had better luck > with the quads ( and some old analog multitech modems ) by lowering the > power level to -13db. It helped two different problems, disconnects and the > long training sessions that never would connect. I was about to start > changing these levels to -13db when I noticed that 3com has changed the > default setting from -11db to -10db in 2.0.51. In all previuos releases they > were set at -11db. Anyone out have any input on this? Does anyone know how > to get measurements from the ct1s to determine what the correct level should > be? I changed our DSP's to -13db when I read the following in the release notes for 2.0.81 <quote> Adjustable Transmit Level Adjustable transmit level provides the ability to configure the modems for optimum performance. Ranges: -3 to -30 dBm for digital T1 line sources. A setting of -13 dBm (S39=13) is recommended for calls over digital lines (T1 or PRI). </quote> We have seen no ill effects from this setting. We had problems with what you describe above, long training sessions that wouldn't connect. I don't know yet if this setting has made an improvement. What I would like to know is why the recommended setting is not the default setting?

Subject: RE: (usr-tc) Second request --dsp transmitter levels
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-09 12:29:23

Thanks for the reply Rob, When I was working with multitech a long time ago on some analog modems made by them, we started playing around for with the power levels in an effort to solve connection problems ( the same long training and then no connect or the dropped connection ) The only explanation I ever got out them was something to do with the way the phone co. provisioned the line and whether or no they added padding to them. Apparently some do some don't. Padding on ct1s is out my experience range so I took their word for it. But there must some way to check this, either a measurement made directly on the line or a indirect method by querying the modems somehow. A 3com tech I tallked to once made reference to reading this info directly off the dsp by plugging in a console cable to them. He never did make it out here on-site, so his knowlege was lost to wind.. Oh well.. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Rob Nelson Sent: Sunday, January 09, 2000 11:17 AM Terry Kennedy wrote: > A few revisions back, can't remember how far, the dsp code started to allow > setting of the transmiter power levels. This was under line interface > options, transmitter level (-db), the same as the quads used to have. They > also had the same -11db setting as the quads did. I have had better luck > with the quads ( and some old analog multitech modems ) by lowering the > power level to -13db. It helped two different problems, disconnects and the > long training sessions that never would connect. I was about to start > changing these levels to -13db when I noticed that 3com has changed the > default setting from -11db to -10db in 2.0.51. In all previuos releases they > were set at -11db. Anyone out have any input on this? Does anyone know how > to get measurements from the ct1s to determine what the correct level should > be? I changed our DSP's to -13db when I read the following in the release notes for 2.0.81 <quote> Adjustable Transmit Level Adjustable transmit level provides the ability to configure the modems for optimum performance. Ranges: -3 to -30 dBm for digital T1 line sources. A setting of -13 dBm (S39=13) is recommended for calls over digital lines (T1 or PRI). </quote> We have seen no ill effects from this setting. We had problems with what you describe above, long training sessions that wouldn't connect. I don't know yet if this setting has made an improvement. What I would like to know is why the recommended setting is not the default setting? - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) IAS accounting problem with HiperArc
From: USRobotics TC Mailing List <usroboticstcmailinglist@imagenisp.com>
Date: 2000-01-09 13:01:53

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BF5AE3.FEECC6D0 Content-Type: text/plain; charset="windows-1252" I am having a problem with my HiperArc and accounting using Microsoft IAS. I have my first accounting server specified as the primary accounting server, and everything is working fine as is. The problem I'm having is related to my second server, which I intend to use as a backup in case the first one goes down. When my second server is set as the secondary server, everything works okay. However, when I have my second server set as the primary first backup, no accounting records are recorded and the NT event log is full of malformed packets. What is different about the packets when they are sent to the server configured as the primary first backup versus the secondary? My other chassis which runs a NSC has no problem at all with the second server. Thanks for your help. Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820 ------_=_NextPart_001_01BF5AE3.FEECC6D0 Content-Type: text/html; charset="windows-1252" <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252"> <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD> <BODY> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000>I am having a problem with my HiperArc and accounting using Microsoft IAS.  I have my first accounting server specified as the primary accounting server, and everything is working fine as is.  </SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000>The problem I'm having is related to my second server, which I intend to use as a backup in case the first one goes down.</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000>When my second server is set as the secondary server, everything works okay.  However, when I have my second server set as the primary first backup, no accounting records are recorded and the NT event log is full of malformed packets.</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000>What is different about the packets when they are sent to the server configured as the primary first backup versus the secondary?</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000>My other chassis which runs a NSC has no problem at all with the second server.</SPAN></FONT></DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000></SPAN></FONT> </DIV> <DIV><FONT face=Arial size=2><SPAN class=450455020-09012000>Thanks for your help.</SPAN></FONT><FONT face=Arial size=2><SPAN class=450455020-09012000></DIV></SPAN></FONT> <DIV><FONT size=2> <P>Anu Jolliffe<BR>Network Administrator<BR>Imagen Communications Inc.<BR>(250) 538-0406 FAX (250) 537-5820</P> <P></P> <P> </P></FONT></DIV> <DIV> </DIV></BODY></HTML> ------_=_NextPart_001_01BF5AE3.FEECC6D0--

Subject: Re: (usr-tc) v.42bis problems
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-09 15:07:56

On Sat, 8 Jan 2000, Horace Demmink wrote: > On Fri, 7 Jan 2000, Mike Andrews wrote: > > > An old problem has just come back, but in only one weird case. > > > > I've got a crapload of people getting randomly bumped offline with v.42 or > > v.42bis related problems. (I suspect v.42bis.) > > > > However... it's only happening on the first 12 channels of ONE DSP card. > > > > I had a similar problem that turned out to be a DSP hardware problem. One > of my DSP's would, after moderate use, not answer on the first 12 channels > until it was reset. I had flashed several different versions of code, > tried different lines (CT1 and PRI), different locations, chassis's, > etc. Nothing made a difference. After jerking around with 3COM's RMA dept > for a while (you can't RMA it until a tech says it's bad, you can't talk > to a tech without a contract) my vendor offered to RMA it for me. I have > not seen this symptom pop up on any other cards I have. Interesting. Any idea what hardware revision the card was? 0.49 maybe? I'm just trying to see if there's any pattern to these at all... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear."

Subject: Re: (usr-tc) changing IP pool
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-09 21:34:42

Thus spake Tatai SV Krishnan >On Sun, 9 Jan 2000, K Mitchell wrote: >> I want to change the IP pool on my chassis from one class C to another >> one, while leaving the ARC and NMC with their original IPs from the first >> class C. Will simply resetting the IP pool in ARC work ok, or do I need to >> make any special provisions for the changeover? Will the ARC still route to >> the old addresses on current calls? >Well - you will have to first create a new IP pool with the new IP >address, and then disable the first IP pool. If you have users currently >dialed in - they will be using the first IP pool - thus you cannot >disable and delete the pool. Actually...I've found you can actually issue the delete command and it works like a charm. The pool will still be there when you do a list ip pools command, since there are still addresses in use, but no new ones will be assigned from it, and when all the addresses in use from that pool are released, the pool does indeed disappear. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) v.42bis problems
From: Horace Demmink <horace@pathwaynet.com>
Date: 2000-01-09 22:38:35

On Sun, 9 Jan 2000, Mike Andrews wrote: > Interesting. > > Any idea what hardware revision the card was? 0.49 maybe? I'm just > trying to see if there's any pattern to these at all... > > No idea, I didn't keep record on what revision the card was. It very well could be 0.49 (why are the hardware revisions 0.xx, are these beta release cards? :-) as the others I installed at the same time are. -- Horace Demmink PathWay Computing

Subject: Re: (usr-tc) IAS accounting problem with HiperArc
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-10 10:43:48

--0__=DD2eq0cxIWj46UPKpNMa5gTgXCzglAyfIf4eYnnVI8xynw6Og23dkra2 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Check your secondary-server's shared secret. STeve Valiunas USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> on 01/09/2000 03:01:53 PM Please respond to usr-tc@lists.xmission.com Sent by: USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> cc: (Steve Valiunas/MW/US/3Com) I am having a problem with my HiperArc and accounting using Microsoft IAS. I have my first accounting server specified as the primary accounting server, and everything is working fine as is. The problem I'm having is related to my second server, which I intend to use as a backup in case the first one goes down. When my second server is set as the secondary server, everything works okay. However, when I have my second server set as the primary first backup, no accounting records are recorded and the NT event log is full of malformed packets. What is different about the packets when they are sent to the server configured as the primary first backup versus the secondary? My other chassis which runs a NSC has no problem at all with the second server. Thanks for your help. Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820 --0__=DD2eq0cxIWj46UPKpNMa5gTgXCzglAyfIf4eYnnVI8xynw6Og23dkra2 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9d2luZG93cy0xMjUyIj4NCg0KDQo8TUVUQSBjb250ZW50 PSJNU0hUTUwgNS4wMC4yOTE5LjYzMDciIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPg0K PERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiBjbGFzcz00NTA0NTUwMjAtMDkwMTIw MDA+SSBhbSBoYXZpbmcgYSANCnByb2JsZW0gd2l0aCBteSBIaXBlckFyYyBhbmQgYWNjb3VudGlu ZyB1c2luZyZuYnNwO01pY3Jvc29mdCBJQVMuJm5ic3A7IEkgaGF2ZSANCm15IGZpcnN0IGFjY291 bnRpbmcgc2VydmVyIHNwZWNpZmllZCBhcyB0aGUgcHJpbWFyeSBhY2NvdW50aW5nIHNlcnZlciwg YW5kIA0KZXZlcnl0aGluZyBpcyB3b3JraW5nIGZpbmUgYXMgaXMuJm5ic3A7IDwvU1BBTj48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDUw NDU1MDIwLTA5MDEyMDAwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ1MDQ1NTAyMC0wOTAxMjAwMD5UaGUgcHJvYmxl bSBJJ20gDQpoYXZpbmcgaXMgcmVsYXRlZCB0byBteSBzZWNvbmQgc2VydmVyLCB3aGljaCBJIGlu dGVuZCB0byB1c2UgYXMgYSBiYWNrdXAgaW4gY2FzZSANCnRoZSBmaXJzdCBvbmUgZ29lcyBkb3du LjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFO IA0KY2xhc3M9NDUwNDU1MDIwLTA5MDEyMDAwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8 RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ1MDQ1NTAyMC0wOTAxMjAw MD5XaGVuIG15Jm5ic3A7c2Vjb25kIA0Kc2VydmVyIGlzIHNldCBhcyB0aGUgc2Vjb25kYXJ5IHNl cnZlciwgZXZlcnl0aGluZyB3b3JrcyBva2F5LiZuYnNwOyBIb3dldmVyLCANCndoZW4gSSBoYXZl IG15IHNlY29uZCBzZXJ2ZXIgc2V0IGFzIHRoZSBwcmltYXJ5IGZpcnN0IGJhY2t1cCwgbm8gYWNj b3VudGluZyANCnJlY29yZHMgYXJlIHJlY29yZGVkIGFuZCB0aGUgTlQgZXZlbnQgbG9nIGlzIGZ1 bGwgb2YgbWFsZm9ybWVkIA0KcGFja2V0cy48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48Rk9O VCBmYWNlPUFyaWFsIHNpemU9Mj48U1BBTiANCmNsYXNzPTQ1MDQ1NTAyMC0wOTAxMjAwMD48L1NQ QU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj48U1BB TiBjbGFzcz00NTA0NTUwMjAtMDkwMTIwMDA+V2hhdCBpcyBkaWZmZXJlbnQgDQphYm91dCB0aGUg cGFja2V0cyB3aGVuIHRoZXkgYXJlIHNlbnQgdG8gdGhlIHNlcnZlciBjb25maWd1cmVkIGFzIHRo ZSBwcmltYXJ5IA0KZmlyc3QgYmFja3VwIHZlcnN1cyB0aGUgc2Vjb25kYXJ5PzwvU1BBTj48L0ZP TlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDUw NDU1MDIwLTA5MDEyMDAwPjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ1MDQ1NTAyMC0wOTAxMjAwMD5NeSBvdGhlciBj aGFzc2lzIA0Kd2hpY2ggcnVucyBhIE5TQyBoYXMgbm8gcHJvYmxlbSBhdCBhbGwgd2l0aCB0aGUg c2Vjb25kIA0Kc2VydmVyLjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJp YWwgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NDUwNDU1MDIwLTA5MDEyMDAwPjwvU1BBTj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQ1 MDQ1NTAyMC0wOTAxMjAwMD5UaGFua3MgZm9yIHlvdXIgDQpoZWxwLjwvU1BBTj48L0ZPTlQ+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+PFNQQU4gDQpjbGFzcz00NTA0NTUwMjAtMDkwMTIwMDA+PC9E SVY+PC9TUEFOPjwvRk9OVD4NCjxESVY+PEZPTlQgc2l6ZT0yPg0KPFA+QW51IEpvbGxpZmZlPEJS Pk5ldHdvcmsgQWRtaW5pc3RyYXRvcjxCUj5JbWFnZW4gQ29tbXVuaWNhdGlvbnMgSW5jLjxCUj4o MjUwKSANCjUzOC0wNDA2IEZBWCAoMjUwKSA1MzctNTgyMDwvUD4NCjxQPjwvUD4NCjxQPiZuYnNw OzwvUD48L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQoNCg== --0__=DD2eq0cxIWj46UPKpNMa5gTgXCzglAyfIf4eYnnVI8xynw6Og23dkra2--

Subject: Re: (usr-tc) changing IP pool
From: Justin <sysadmin@nebi.com>
Date: 2000-01-10 11:10:32

Kirk, You need to add an address from the subnet of the pool that you added to the ethernet interface of the HiperArc that doles out those ip's. For instance, if you added a pool of size 200, starting address 192.168.1.10, you would need to add an unused IP from that range to the ethernet port of the hiperArc; ie: "add ip network somename address 192.168.1.2 interface eth:1 enabled yes". Of course, you would need 192.168.1.1 (or other unassigned IP from that range) assigned to the corresponding interface on your Cisco to complete the route. HTH, Justin >I was able to get the new pool in over the weekend with Krish's help, but >the ARC isn't routing to the new pool. Apparently I'm missing something. > > >-- >Kirk Mitchell-General Manager mitch@keyconn.net >Keystone Connect Unlock Your World >Altoona, PA 814-941-5000 http://www.keyconn.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) changing IP pool
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-10 11:15:54

At 09:34 PM 1/9/00 -0500, Jeff Mcadams wrote: >Thus spake Tatai SV Krishnan >>On Sun, 9 Jan 2000, K Mitchell wrote: >>> I want to change the IP pool on my chassis from one class C to another >>> one, while leaving the ARC and NMC with their original IPs from the first >>> class C. Will simply resetting the IP pool in ARC work ok, or do I need to >>> make any special provisions for the changeover? Will the ARC still route to >>> the old addresses on current calls? > >>Well - you will have to first create a new IP pool with the new IP >>address, and then disable the first IP pool. If you have users currently >>dialed in - they will be using the first IP pool - thus you cannot >>disable and delete the pool. > >Actually...I've found you can actually issue the delete command and it >works like a charm. The pool will still be there when you do a list ip >pools command, since there are still addresses in use, but no new ones >will be assigned from it, and when all the addresses in use from that >pool are released, the pool does indeed disappear. I was able to get the new pool in over the weekend with Krish's help, but the ARC isn't routing to the new pool. Apparently I'm missing something. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) changing IP pool
From: System Administrator <sysadmin@nebi.com>
Date: 2000-01-10 12:16:23

> You had me for a second there, than ya lost me :) > My apologies for not being router clue'd, and again for not having a > Cisco(I'm working on changing both). My router's an OpenRoute, and does > have the 2nd class C listed and appears to be routing to it ok. I assigned > an IP from the new class C to a server NIC and was able to get to a test > website in that IP from outside my network. If that's the case, then it should be safe to assume (remember what your English teacher told you?)that routing is working except to the HARC. > Back to the TC...I take it then that I need to assign an > address from the > new class C to the ARC. I wasn't aware that the ARC could have more than 1 > address, and was hoping to leave it with the address it has from my > original class C. Your HARC can have more than one IP address assigned to the ethernet interface. I can shuffle things though if that's not possible. I'd > imagine that I should assign the NMC a new address also. My NMC is on a different subnet than my HARC. 3Com said that's not the way it was intended, but it works fine for me. > Is there any way > to find out the name of the network that's already assigned? li ip net > Here's what I have currently...the pool is from the 204.171.31.0/24 and > the new class C is 204.171.145.0/24 > CONFIGURED DEFAULT ROUTERS > Address Mask Gateway Metric State > 0.0.0.0 0.0.0.0 204.171.31.1 1 ENABLED > HiPer>> sh ip rou > > IP ROUTER SETTINGS > IP Router Administrative Status: ENABLED > IP Static Remote Routes: ENABLED > IP LAN Host Address: 204.171.31.2 > IP Autonomous System Number 1 > IP Max Table Size: 11400 > IP Max Metric Entries: 512 > IP RIP ENABLED > IP Number RIP Interfaces: 0 > IP Number RIP Neighbors: 0 > IP RIP Flags: METRICS > SEND_REQUEST OK, so here's what we need to do: Add the new pool to the HARC: add ip pool poolname init 204.171.145.x size xx Add new IP address to ethernet interface: add ip network somename address 204.171.145.x interface eth:1 enabled yes Add new default gateway for new IP Pool (point it to your router): add ip defaultroute gateway 204.171.145.1 Save it: save all That should get you going! __________________________________ Justin Ellison System Administrator InternetUSA sysadmin@nebi.com http://nebi.com 800-603-3502

Subject: Re: (usr-tc) changing IP pool
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-10 12:43:43

At 11:10 AM 1/10/00 -0600, Justin wrote: >Kirk, > > You need to add an address from the subnet of the pool that you added to the ethernet interface of the HiperArc that doles out those ip's. For instance, if you added a pool of size 200, starting address 192.168.1.10, you would need to add an unused IP from that range to the ethernet port of the hiperArc; ie: "add ip network somename address 192.168.1.2 interface eth:1 enabled yes". Of course, you would need 192.168.1.1 (or other unassigned IP from that range) assigned to the corresponding interface on your Cisco to complete the route. You had me for a second there, than ya lost me :) My apologies for not being router clue'd, and again for not having a Cisco(I'm working on changing both). My router's an OpenRoute, and does have the 2nd class C listed and appears to be routing to it ok. I assigned an IP from the new class C to a server NIC and was able to get to a test website in that IP from outside my network. Back to the TC...I take it then that I need to assign an address from the new class C to the ARC. I wasn't aware that the ARC could have more than 1 address, and was hoping to leave it with the address it has from my original class C. I can shuffle things though if that's not possible. I'd imagine that I should assign the NMC a new address also. Is there any way to find out the name of the network that's already assigned? Here's what I have currently...the pool is from the 204.171.31.0/24 and the new class C is 204.171.145.0/24 CONFIGURED DEFAULT ROUTERS Address Mask Gateway Metric State 0.0.0.0 0.0.0.0 204.171.31.1 1 ENABLED HiPer>> sh ip rou IP ROUTER SETTINGS IP Router Administrative Status: ENABLED IP Static Remote Routes: ENABLED IP LAN Host Address: 204.171.31.2 IP Autonomous System Number 1 IP Max Table Size: 11400 IP Max Metric Entries: 512 IP RIP ENABLED IP Number RIP Interfaces: 0 IP Number RIP Neighbors: 0 IP RIP Flags: METRICS SEND_REQUEST Thanks, -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) changing IP pool
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-10 14:22:03

At 12:16 PM 1/10/00 -0600, System Administrator wrote: >If that's the case, then it should be safe to assume (remember what your >English teacher told you?)that routing is working except to the HARC. That's a safe assumption :) >Your HARC can have more than one IP address assigned to the ethernet >interface. Does it need to have an address from the class C it's using as pool? >My NMC is on a different subnet than my HARC. 3Com said that's not the way >it was intended, but it works fine for me. It's be easier for me to keep ARC and NMC within the same class C, whichever one it ends up being. >> Is there any way >> to find out the name of the network that's already assigned? > >li ip net But that only...ah...I see...what threw me was the original network was named "IP". I wonder what dummy picked that name 2 years ago :) Name Prot Interface State Type Network Address ip IP eth:1 ENA STAT 204.171.31.2/C >OK, so here's what we need to do: >Add the new pool to the HARC: > add ip pool poolname init 204.171.145.x size xx Done >Add new IP address to ethernet interface: > add ip network somename address 204.171.145.x interface eth:1 enabled yes So what's there won't work for 204.171.145.x? CONFIGURED DEFAULT ROUTERS Address Mask Gateway Metric State 0.0.0.0 0.0.0.0 204.171.31.1 1 ENABLED >Add new default gateway for new IP Pool (point it to your router): > add ip defaultroute gateway 204.171.145.1 My router is at 204.171.31.1, so I need to add an 204.171.145.x IP to it also? Many thanks, -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) IAS accounting problem with HiperArc
From: USRobotics TC Mailing List <usroboticstcmailinglist@imagenisp.com>
Date: 2000-01-10 15:17:26

That's the first thing I did when I ran into the problem. I even verified the secrets on the HipeArc using the _show accounting radius secret. Anyone have any other suggestions? Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820 -----Original Message----- Sent: Monday, January 10, 2000 8:44 AM Check your secondary-server's shared secret. STeve Valiunas USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> on 01/09/2000 03:01:53 PM Please respond to usr-tc@lists.xmission.com Sent by: USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> cc: (Steve Valiunas/MW/US/3Com) I am having a problem with my HiperArc and accounting using Microsoft IAS. I have my first accounting server specified as the primary accounting server, and everything is working fine as is. The problem I'm having is related to my second server, which I intend to use as a backup in case the first one goes down. When my second server is set as the secondary server, everything works okay. However, when I have my second server set as the primary first backup, no accounting records are recorded and the NT event log is full of malformed packets. What is different about the packets when they are sent to the server configured as the primary first backup versus the secondary? My other chassis which runs a NSC has no problem at all with the second server. Thanks for your help. Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820

Subject: (usr-tc) State of the Hub (part 1)(take 2)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-10 15:34:33

We've recently seen the release of HiPer Arc releases 4.2.32 and 4.1.22. So now seems to be an appropriate time to take a look at the State of the Hub (with apologies to the U.S. Government and Larry Wall for the name). I'm trying to bring about some structure to these messages that I post to give people a bit more assistance in finding the content that they need/are interested in out of my greater ramblings. I'll start off with some specific issues and questions that I have (essentially like the rest of my messages), and then go into some rather more broad thoughts. First, with release of 4.1.22, 3Com seems to have added some support, or at least control over directed broadcasting. Specifically disable/enable ip directed_bcast_forwarding. The release notes describe it as "When enabled, it allows directed broadcast forwarding from the user." My question is...how does this work? It seems to imply that it magically figures out what's going to be a directed broadcast that the user is sending out and drops it on the floor. I hope this isn't the case, but that it only drops directed broadcasts for directly connected networks. This, of course, because there is no way for the Arc to know if something is going to be a directed broadcast on a remote network. :) Second, SAA (Source Address Assurance) now pays attention to the netmask assigned on a connection to check to make sure that the source address coming in from that connection is indeed supposed to be able to be sourced from there. Previously, this only worked for /32's, but the description in the Release Notes indicates that it now considers the netmask for that. Does it consider a seperate route? I can understand if it wouldn't...that's considerably less trivial, but it would be good functionality to add to this feature. Even further...would be to allow it if the address is reachable (As best the Arc can tell) from that connection...which means that it may not even be in the routing table. You'd have to consult with the OSPF table (well...not in 4.1.x, but in later code), as well as any other routing protocol tables and static routes that aren't preferred. Anyway...just a question that I'm sure will come up before long that will be good to get clarified. :) OK...now on to greater, broader, longer-standing issues. :) 3Com's release numbering (at least on the total control stuff) is still nuts. I'm not sure what would be a good solution...but some releases counting up, and some releases counting down is just completely confusing to customers. Even long-time customers can have difficulty figuring out what the status of a particular release is, and which releases are newer than others. New customers are usually totally baffled, and understandbly so. This really needs to be changed...its been a call that those of us on the list have been making for many years, with no result. The best response (and given the people that are responding, this is understandable) that we get is yet another explanation of the current release numbering system, which isn't what is needed. I applaud Mike Wronski's and Krish's and Chuck Stace's, and the rest of the crew's patience in explaining this time and time again to new folks, and clarifying the status of releases when they're asked about. Really though, 3Com as a whole, would be much better served by letting these people do the job they were hired to do, not looking up (I know, most of you know them well enough that you don't have to look them up) what the status of a specific version of code is. Security releases are still taking *WAY* too long to be made widely available. There have been several security issues that have been made public in the last year or so, ER's have been made available that address these issues. Due to the nature of ER's though, these are not widely available, or publicized, or clearly understood (see the release number issue above ;). HiPerBomb was announced (I believe by Ed Taylor?) in mid-August. I had announced an SNMP security hole before that...both of which affected 4.1.59-6. Though ER's were available, it has taken 5 months for an SR to be made available (in the 4.1.x tree) that includes these fixes. This is an order of magnitude or two off from the amount of time this should be. Security fixes for problems of the magnitude represented by HiPerBomb and the SNMP issues that had been brought should have code widely available that addresses these on the order of a week or so from the time that they are made known to 3Com. I still get reports of people running into problems with NETServers, and 3Com continues to be unresponsive in dealing with thier handling of the practical end of support for this product. At this point, support contracts for the NETServer products should have all expired (unless 3Com continued to sell support for NETServers after they lost access to the source code which would be even worse!), so complaints have less of a basis at this point, but given the poor way that 3Com originally handled the NETServer to HiPer Arc transition, some complaints still are valid. Hopefully, 3Com has at least learned from the NETServer fiasco and won't repeat the same mistake twice, but that's little consolation for people that are still making do with buggy NETServer code as a result of 3Com's abrupt transition from the NETServer platform to the HiPer Arc platform. (cont. due to message size limitations) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) State of the Hub (part 2)(take 2)
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-10 15:35:11

(cont. from previous message due to message size limitations) I have received no reports, either positive or negative about the current state of 3Com support contract rules. A perusal of relevant 3Com web sites seems to indicate that some progress has been made on this issue. If you go to 3Com's web site, to the support section, and click on 3Com Care service offerings, under Maintenance Services, you'll see a section entitled "Unbundled Services." There are sub-sections for InfoPak telephone support (which is at the time of this writing a broken link), software updates (all of the latest software upgrades for a year for one low price...this has promise), Advanced Hardware Replacement (one contract covers multiple pieces of equipment...new equip. can be added at a pro-rated cost...this has potential *if* you can pick and choose which hardware is covered and are not required to cover all your hardware with the same coverage), and Multi-Year Warranty (also a broken link at the time of writing). I have a call in to my great sales-rep Tom Goodman to get more in depth information about the requirements of these service offerings (and prices), and will post what information I get when I get it. This covers the major outstanding issues that I'm aware of. Some further discussion points that have been brought up in the past are discussed below. Customer involvement in software development. I've not seen much progress here, it seems that most software development on the TC equipment is still done with very little connection to customer requests (very cathedral style, with apologies to ESR). There has been recent calls for more participation on the beta list for TCS 4.0, I wholeheartedly encourage this...unfortunately, I haven't had the opportunity to work with the beta software as I would like. The beta list (and I'm under the beta NDA, so I need to be a little careful here ;) seems primarily to be a list for customer feedback to 3Com folks about the problems we're having. It would be nice, (and this isn't just restricted to the beta list) to have the possibility to be part of the discussion about how things get implemented. Had more customer input been solicited, perhaps we wouldn't have ended up with ip pool aggregation reserving a network and broadcast address unnecessarily, and similar types of issues...none are critical, but all would make the TC equipment that much nicer to use. Another access server type of feature request to be re-iterated (this has been a long term request)...the ability to define, by an administrator, what traffic will reset the idle timer on a port. The ability to set this via RADIUS would be an added bonus. Beaurocracy (and I'm still not sure if I'm spelling this right). There seems to have been made a *little* progress in this area, however, this requires a disclaimer. I, personally, apparently, have achieved some...ah...notoriety within 3Com...particularly in the Rolling Meadows facilities. As such, I must consider the possibility that I've been getting contact with people within 3Com that its not common to have direct customer contact with. :) Even this, however, is an improvement. Perhaps this gives me the opportunity to be a sort of liason between 3Com and 3Com's customers. I fear that I'm sounding cocky ("I have better contacts than you do"), and assure you that this isn't my intention. I'd rather people have direct contact...I have plenty of things on my plate to do that the time taken up being such a liason could be used elsewhere, but if I do have better contacts, and can be useful as a sort of liason, I'm certainly willing to do so for the betterment of 3Com-customer relations. :) Direction. Specifically with the HiPer Arc card (which is where I'm particularly knowledgeable within the TC product group), it seems that 3Com is beginning to see the possibilities that the HiPer Arc (at least) provides beyond just being a dial-up access server. Again, I have to be careful here because of the restrictions of the beta NDA...but the direction of the development seems to be towards making the HiPer Arc a full-fledged router. Some things that need to be worked on still: - 3500 route limit needs to be removed, or at least upped - more routing protocols...OSPF is a great start...more needed (BGP?) - OSPF needs to be able to be an ABR - more control over routing protocols...summarization, redistribution - route selection still somewhat buggy (Mike Andrews is the expert on these problems ;) And some things that I think are important, but not necessarily to the point of being *needed*: - bridging - QoS...this is apparently a company wide push for 3Com...so I suspect its going to be done in a big way - wider array of interface types And, just for kicks, a gee-whiz cool feature that the TC lends itself to: - packet bus interface...the ability to treat the internal packet of the chassis as an interface in the Arc...some cool things can be done when this is combined with bridging support above Even as an access server, the Arc needs to be developed to adapt to changing times. As modem and ISDN access becomes less and less prevelent with the proliferation of broadband, the Arc needs to adapt. There seems to be some work on this front (again, TCS 4.0 beta), the bridging support mentioned above is needed for this as many DSL providers transport DSP and other broadband access methods to ISP via a bridging over frame-relay or bridging over ATM. The Arc already has support for frame and ATM, but can't (from what I've seen) do bridging over top of it. I encourage people to submit their own feature requests, etc. to the list and/or me. I've been keeping some notes recently for inclusion into this and future "State of the Hub" messages. :) Like I said...I'm willing to take up the role of liason between 3Com and customers if that's necessary/desireable, let me know. I also encourage feedback to me and to this forum regarding this message and others of mine. My philosophy is that I own my words. I'll take responsibility for what I say, I encourage forwarding of my messages on to people who would benefit from my messages, all I ask is that you keep attribution and contact info in tact so that I can continue to take responsibility for my words. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) BETA: EdgeServer Pro v2.6 (estimated start date - 2/1/2000)
From: Chuck Stace <chuck_stace@mw.3com.com>
Date: 2000-01-10 16:31:55

--0__=Hic2pMcPD4BBxIMF9LDemLINMUlQx5ArRN0x2IV320I8l54KDMuagL4x Content-type: text/plain; charset=us-ascii Content-Disposition: inline 3Com Customers, 3Com is now accepting applications for beta testers for the release of EdgeServer Pro version 2.6 This release has added performance and feature enhancements including support for Microsoft NT4 Service Pack 6. To apply for this beta, please go to the TotalService website at: http://totalservice.3com.com/ and click on 'Beta Program' and then 'Upcoming Beta Projects'. At this time, you will have to log into your TotalService account to enter into this beta. If you are a customer that does not currently have an account with TotalService, please apply for an account at: http://totalservice.3com.com/create.html Once your application has been completed and reviewed, you will receive email informing you of your status in the beta program and more details on how to participate once the EdgeServer Pro 2.6 beta begins field trials. For more information on Total Control EdgeServer --0__=Hic2pMcPD4BBxIMF9LDemLINMUlQx5ArRN0x2IV320I8l54KDMuagL4x Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable ? Pro Integrated NT Server, you can visit our website at: http://www.3com.com/solutions/svprovider/products/rac/edgpro.html If you have any questions or comments on this beta, please email me at = the address listed below, and if you have anyone that would be interested i= n participating in this program, please feel free to forward this email t= o their attention. Thank you for your time, Chuck Stace CSO Customer Service Product Planning Chuck_Stace@3Com.com = --0__=Hic2pMcPD4BBxIMF9LDemLINMUlQx5ArRN0x2IV320I8l54KDMuagL4x--

Subject: RE: (usr-tc) IAS accounting problem with HiperArc
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-10 17:45:54

Anu, That would have been primary-accounting-server-2, not secondary-server as I wrote, but I'm sure you checked that as well. What version of Harc code? If you want to capture a bit of MonitorRadius in hex mode (while sending Malformed packets of course), and send it to me along with the accounting sercret used, I can see see if anything looks whacky. Steve Valiunas steve_valiunas@3com.com USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> on 01/10/2000 05:17:26 PM Please respond to usr-tc@lists.xmission.com Sent by: USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> cc: (Steve Valiunas/MW/US/3Com) That's the first thing I did when I ran into the problem. I even verified the secrets on the HipeArc using the _show accounting radius secret. Anyone have any other suggestions? Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820 -----Original Message----- Sent: Monday, January 10, 2000 8:44 AM Check your secondary-server's shared secret. STeve Valiunas USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> on 01/09/2000 03:01:53 PM Please respond to usr-tc@lists.xmission.com Sent by: USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> cc: (Steve Valiunas/MW/US/3Com) I am having a problem with my HiperArc and accounting using Microsoft IAS. I have my first accounting server specified as the primary accounting server, and everything is working fine as is. The problem I'm having is related to my second server, which I intend to use as a backup in case the first one goes down. When my second server is set as the secondary server, everything works okay. However, when I have my second server set as the primary first backup, no accounting records are recorded and the NT event log is full of malformed packets. What is different about the packets when they are sent to the server configured as the primary first backup versus the secondary? My other chassis which runs a NSC has no problem at all with the second server. Thanks for your help. Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) DS3 Based TC Hub
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-10 18:14:24

<musing> If 3Com is listening, as I've mentioned to TG in the past, like to see 3Com come out with a DS3 <-> CT1/PRI interface internal to the hub. Even if it'd take up an entire chassis to do it, it'd be really cool to be able to plug in twin coax on the back of a chassis and be done with it, turning things up as needed but working on the DS3 level instead of having a mess of wires running around everywhere from the DS3 interface to the mux, to the dsx panel to the DSP's, etc. I don't know if the packet or TDM bus is designed to handle that much data, however. I would hope that it is. Heck, I wouldn't mind having a DS3 card which would interface to the DSP's across the TDM bus as long as we could get dual PRI or dual T1 DSP's in place. Wouldn't that be cool? :) It would mean making those LED's a bit smaller so we could see if span 1 is working vs span 2 on the dual DSP. Let's see... 28 / 2 = 14. If the DS3 card took up one one slot, that'd be 15 slots with the DSP's. Hmmm :) One for the serving gateway card, and one for the NMC... :) Sounds like just the right size to me... Am I the only one who thought of this? :) The only real disadvantage to doing this is putting so many eggs in one basket with the chassis being required to be up. If we were going to do this, we'd definitely have spare DS3 equipment on hand and thanks to a very nice arrangement with our telco, they've installed an FLM150 in our offices where we have DS3 and that's their responsiblity. As far as dual DSP's, we'd probably keep a couple on hand along with spare power supplies and a chassis. If we were going to put that much $ into a box, though, I'd definitely want to be able to peel off some of those DS1's into external RJ45's to be used by other CSU/DSU's so we could put DAP customers, etc. on it. </musing> Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) DS3 Based TC Hub
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-10 18:41:11

Thus spake Kevin Benton >I don't know if the packet or TDM bus is designed to handle that much >data, however. Unfortunately, I believe the answer to that is, no, it isn't designed to handle that much data. The TDM bus on the chassis has (if I remember correctly) 512 timeslots...a fairly significant number short of the 672 needed to handle DS3 ingress. :/ Now, in theory, you could change the clocking in the chassis and crank the number of timeslots higher, and assuming that 3Com has overengineered the TDM bus like they did the rest of the chassis, this might even be feasible. I'm certainly not a guru when it comes to this area, so I don't know for sure, but I wouldn't rule it out. The downside of this is that you probably would not be able to have any of the current cards that use the TDM bus in a chassis with cards that would use the faster TDM bus as they pull their clocking off the bus itself and the current crop of cards (unless they're also rather overengineered) couldn't handle the higher speed clocking. Minor drawback, and one that I, for one, would certainly be willing to live with. There are probably other obstacles to this that I'm not aware of, but the theory seems pretty simple. :) The thought that I had was that you had a master/slave ds3 card setup...master in one chassis took the ds3 in, split off half the channels and sent them across the packet bus to the DSP cards, then the other half of the channels were daisy chained to another chassis where it connects to another ds3 ingress card and the rest of the channels were handled. Shoot, if this were done right, you could then daisy-chain that over to a third chassis as a full hot-spare chassis...if one of the first two chassis failed, the calls would get passed through to the third. I discussed all of this with Tom Goodman when I was up for Networks3, so there's at least one person in 3Com who I've talked to about these ideas. :) >Let's see... 28 / 2 = 14. If the DS3 card took up one one slot, that'd be >15 slots with the DSP's. Hmmm :) One for the serving gateway card, and >one for the NMC... :) Sounds like just the right size to me... Am I the >only one who thought of this? :) Ai...not sure I like the idea of a full ds3 worth of calls terminating on a gateway card with no hot spare available. :/ >The only real disadvantage to doing this is putting so many eggs in one >basket with the chassis being required to be up. Particularly the gateway card (HiPer Arc, or whatever a beast that could handle 600 calls would be called). >If we were going to put that much $ into a box, though, I'd definitely >want to be able to peel off some of those DS1's into external RJ45's to be >used by other CSU/DSU's so we could put DAP customers, etc. on it. I've thought that the DSP's should be more general purpuse anyway. Take the DSP NAC, and rather than making it a T1/PRI/modem board, use that mondo processing power there (and with 3 PPC's, its got plenty) give it a T3 NIC and let it do packet T3. Then you could also use those PPC's as a distributed route-cache/forwarding engine, or a compression or encryption engine. Certainly it would at least do the framing work that it currently does with PPP. Its quite possible that you could even relegate the HiPer Arc to being a control engine type of thing, where the routing protocols and such are processed by the Arc, a forwarding table is built which is then pushed out to the DSP cards which do the actual forwarding. This isn't exactly unheard of in other vendor products as it is. :) Most vendors are going to a processing engine, and one or more forwarding engines...certainly a DSP/Arc equipped chassis has more than enough processing power available to handle a huge amount of throughput/pps. Careful coding should let you have transparent failover of the Arcs that way too. You could at least do this for plain packet forwarding...you'd lose telnet sessions to the Arc, probably BGP sessions (assuming BGP is available then), but with a draft I saw the other day...kind of like a soft restart of BGP...you could prevent that from stopping packet forwarding even. There are so many possibilities here...I don't think any one person can conceive of them all...that's one of the reasons that I've been trying to get people to post some blue-sky thinking here...give 3Com some ideas of what could be possible. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) NetServer 3.8.1 not Y2K Compliant
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-11 10:55:25

Hi, I haven't touched our one Netserver-based chassis for a while, and it's running: Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.7.73 Build date: Mar 19 1998 Build time: 21:32:39 The date/time seems OK (synced via ntp): January 11, 2000 15:54:53 UT For the life of me I can't remember what the update fixed, though... Can someone refresh my memory? Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Sat, 8 Jan 2000, Bob Purdon (Lists) wrote: > > > The NetServer 3.8.1 code running on two of our tc's is not Y2K > > Compliant. It's running NTP to accept the time from our time servers > > and shows the date to be incorrectly something with the year of 1900. > > Hmmm, we have 10 units operating at the moment, all using NTP, and they're > all spot on. This must either be a really obscure bug, or be > configuration dependent. > > > would require new code for the NetServer. The 3Com case number for > > this problem is 154529. > > Let us all know if they make new code available to fix it :-) > > ------------------------------------------------------------------------ > Bob Purdon, Ground Floor, Marine Board Building > Technical Manager (Tas/Vic), 1 Franklin Wharf, Tas 7000 > Southern Internet Services. +61 (3) 6234 7444 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Software recommendations
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-11 11:04:41

Hi, I'm long overdue for an upgrade on a large number of chassis, and while I've been following the list, I've had a hard time coming up with what is a good, stable version of code to be running everywhere... I have HAs, HDSPs, and Quads in these chassis. I would like OSPF (took the time to learn more about it than RIP), but it's not a necessity. We currently have horrid problems with disconnects on most all modems, iMac troubles (although Mindspring does too; only really occurred for me when the connection was above 46.6K), and really BAD Global Village (blech, barf, erk) problems. We've not seen the "two modems hung" problem. So what's the recommended, stable code you folks are using? What is the rule with mixing DSP and ARC code? Can I run a newer DSP code (2.x) w/older ARC code (4.1)? Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: (usr-tc) 3Com Beta Programs
From: Ken Kirchner <kenk@shreve.net>
Date: 2000-01-11 11:29:47

On Mon, 10 Jan 2000, Chuck Stace wrote: > 3Com Customers, > > 3Com is now accepting applications for beta testers for the release of > EdgeServer Pro version 2.6 This release has added performance and feature > enhancements including support for Microsoft NT4 Service Pack 6. What ever happened to the 3Com "Gamer's Modem"? Did anyone on this list get into that program?

Subject: RE: (usr-tc) IAS accounting problem with HiperArc
From: USRobotics TC Mailing List <usroboticstcmailinglist@imagenisp.com>
Date: 2000-01-11 14:00:43

The problem went away when I upgraded the Harc to 4.1.22. Thanks for your help. Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820 -----Original Message----- Sent: Monday, January 10, 2000 3:46 PM Anu, That would have been primary-accounting-server-2, not secondary-server as I wrote, but I'm sure you checked that as well. What version of Harc code? If you want to capture a bit of MonitorRadius in hex mode (while sending Malformed packets of course), and send it to me along with the accounting sercret used, I can see see if anything looks whacky. Steve Valiunas steve_valiunas@3com.com USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> on 01/10/2000 05:17:26 PM Please respond to usr-tc@lists.xmission.com Sent by: USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> cc: (Steve Valiunas/MW/US/3Com) That's the first thing I did when I ran into the problem. I even verified the secrets on the HipeArc using the _show accounting radius secret. Anyone have any other suggestions? Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820 -----Original Message----- Sent: Monday, January 10, 2000 8:44 AM Check your secondary-server's shared secret. STeve Valiunas USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> on 01/09/2000 03:01:53 PM Please respond to usr-tc@lists.xmission.com Sent by: USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> cc: (Steve Valiunas/MW/US/3Com) I am having a problem with my HiperArc and accounting using Microsoft IAS. I have my first accounting server specified as the primary accounting server, and everything is working fine as is. The problem I'm having is related to my second server, which I intend to use as a backup in case the first one goes down. When my second server is set as the secondary server, everything works okay. However, when I have my second server set as the primary first backup, no accounting records are recorded and the NT event log is full of malformed packets. What is different about the packets when they are sent to the server configured as the primary first backup versus the secondary? My other chassis which runs a NSC has no problem at all with the second server. Thanks for your help. Anu Jolliffe Network Administrator Imagen Communications Inc. (250) 538-0406 FAX (250) 537-5820 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) WTB: Hiper DSP NAC/NIC Sets
From: Steve Rivera <sales@wrca.net>
Date: 2000-01-11 15:16:11

I am in the market to purchase up to 5 of these cards today. If you have them available please email me off the list. .................................................... Steve Rivera - http://www.ISP-NetworkHardware.com (WRCA) sales@wrca.net v-732-833-2111 cell/pgr-732-433-5890 ---WAN ACCESS SPECIALIST--- Cisco, Ascend, Livingston, USR, Microcom, Computone, Kentrox, Adtran...and more

Subject: Re: (usr-tc) DSP cards rebooting
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-11 16:15:22

I upgraded all of mine to 2.0.51 with no adverse effects so far. At 05:37 PM 1/11/00 -0500, you wrote: >If your cards are hardware revision 0.55 or 0.54, try loading 2.0.51 on >them... > > >Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ >VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY >Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville >"It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." > >On Tue, 11 Jan 2000, Cheryl Johnson wrote: > > > Anyone else have this problem using the 2.0.60 version on the HiPerDSP > cards? This code is supposed to help with the modem pair problem. > Although this problem has not been as noticeable as the past, I still > have various modem problems and recently noticed DSP cards rebooting. I > just recently upgraded the TC chassis to the code above and seem to > having problems with it. I have also been experimenting with increasing > the Carrier Loss Detect Delay on the DSP cards, anyone had any luck with > increasing this setting? I am not sure if this may be causing problems or not. > > > > Cheryl Johnson > > netadmin@seidata.com > > SEI Data Network Services, Inc. > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: (usr-tc) RADIUS check items?
From: Jesse Sipprell <jss@evcom.net>
Date: 2000-01-11 16:54:42

Can anyone tell me what RADIUS check attributes are sent (by the HARC) in the initial auth request packet in order to determine an Async or ISDN call? Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800.496.4736 * Finger jss@evcom.net for my PGP Public Key *

Subject: (usr-tc) DSP cards rebooting
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-11 17:24:34

This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BF5C58.BA710630 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Anyone else have this problem using the 2.0.60 version on the HiPerDSP = cards? This code is supposed to help with the modem pair problem. = Although this problem has not been as noticeable as the past, I still = have various modem problems and recently noticed DSP cards rebooting. I = just recently upgraded the TC chassis to the code above and seem to = having problems with it. I have also been experimenting with increasing = the Carrier Loss Detect Delay on the DSP cards, anyone had any luck with = increasing this setting? I am not sure if this may be causing problems = or not.=20 Cheryl Johnson netadmin@seidata.com SEI Data Network Services, Inc. ------=_NextPart_000_000B_01BF5C58.BA710630 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Anyone else have this problem using the = 2.0.60=20 version on the HiPerDSP cards? This code is supposed to help = with the=20 modem pair problem. Although this problem has not been as = noticeable as the=20 past, I still have various modem problems and recently = noticed DSP=20 cards rebooting. I just recently upgraded the TC chassis to the = code above=20 and seem to having problems with it. I have also been experimenting with = increasing the Carrier Loss Detect Delay on the DSP cards, anyone had = any luck=20 with increasing this setting? I am not sure if this may be causing = problems or=20 not. </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Cheryl Johnson</FONT></DIV> <DIV><FONT face=3DArial size=3D2><A=20 href=3D"mailto:netadmin@seidata.com">netadmin@seidata.com</A></FONT></DIV= > <DIV><FONT face=3DArial size=3D2>SEI Data Network Services,=20 Inc.</FONT></DIV></BODY></HTML> ------=_NextPart_000_000B_01BF5C58.BA710630--

Subject: Re: (usr-tc) DSP cards rebooting
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-11 17:37:22

If your cards are hardware revision 0.55 or 0.54, try loading 2.0.51 on them... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." On Tue, 11 Jan 2000, Cheryl Johnson wrote: > Anyone else have this problem using the 2.0.60 version on the HiPerDSP cards? This code is supposed to help with the modem pair problem. Although this problem has not been as noticeable as the past, I still have various modem problems and recently noticed DSP cards rebooting. I just recently upgraded the TC chassis to the code above and seem to having problems with it. I have also been experimenting with increasing the Carrier Loss Detect Delay on the DSP cards, anyone had any luck with increasing this setting? I am not sure if this may be causing problems or not. > > Cheryl Johnson > netadmin@seidata.com > SEI Data Network Services, Inc. >

Subject: (usr-tc) Disconnect reasons
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-11 19:35:08

This is a multi-part message in MIME format. ------=_NextPart_000_001B_01BF5C6A.F810C2C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Looking at the Total Control It will list several types of disconnect = reasons.....rcvdGatewayDiscCmd, NormalUserCallClear,v42DisconnectCm, = along with several others...Where can I find a explanation of these = reasons. Which ones other than CarrierLoss should alert me to problems = other than the users just logged off. Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_001B_01BF5C6A.F810C2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Looking at the Total Control It will = list several=20 types of disconnect reasons.....rcvdGatewayDiscCmd,=20 NormalUserCallClear,v42DisconnectCm, along with several others...Where = can I=20 find a explanation of these reasons. Which ones other than = CarrierLoss=20 should alert me to problems other than the users just logged off. =20 Thanks</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A>=20 </FONT></DIV></BODY></HTML> ------=_NextPart_000_001B_01BF5C6A.F810C2C0--

Subject: RE; (usr-tc) DSP cards rebooting
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-11 19:38:12

This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BF5C6B.65AC25E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cheryl...We have been running this code for about a month now and have = not had to reset a modem since. Have not noticed any ill effects from = the upgrade. We raised our carrier loss detect setting to 20 I believe = the default is 6 or 7. Can't say it helped anything but has not done = any harm either. Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ----- Original Message -----=20 From: Cheryl Johnson=20 To: usr-tc@lists.xmission.com=20 Sent: Tuesday, January 11, 2000 4:24 PM Subject: (usr-tc) DSP cards rebooting Anyone else have this problem using the 2.0.60 version on the HiPerDSP = cards? This code is supposed to help with the modem pair problem. = Although this problem has not been as noticeable as the past, I still = have various modem problems and recently noticed DSP cards rebooting. I = just recently upgraded the TC chassis to the code above and seem to = having problems with it. I have also been experimenting with increasing = the Carrier Loss Detect Delay on the DSP cards, anyone had any luck with = increasing this setting? I am not sure if this may be causing problems = or not.=20 Cheryl Johnson netadmin@seidata.com SEI Data Network Services, Inc. Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_000D_01BF5C6B.65AC25E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2> <DIV><FONT face=3DArial size=3D2>Cheryl...We have been running this code = for about a=20 month now and have not had to reset a modem since. Have not noticed any = ill=20 effects from the upgrade. We raised our carrier loss detect setting to = 20 I=20 believe the  default is 6 or 7. Can't say it helped anything but = has not=20 done any harm either.</FONT></DIV> <DIV>Greg Owens<BR>Magnolia Internet Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:netadmin@seidata.com" = title=3Dnetadmin@seidata.com>Cheryl=20 Johnson</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Tuesday, January 11, 2000 = 4:24=20 PM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> (usr-tc) DSP cards=20 rebooting</DIV> <DIV><BR></DIV> <DIV><FONT face=3DArial size=3D2>Anyone else have this problem using = the 2.0.60=20 version on the HiPerDSP cards? This code is supposed to help=20 with the modem pair problem. Although this problem has not = been as=20 noticeable as the past, I still have various modem problems and = recently=20 noticed DSP cards rebooting. I just recently upgraded the TC = chassis=20 to the code above and seem to having problems with it. I have also = been=20 experimenting with increasing the Carrier Loss Detect Delay on the DSP = cards,=20 anyone had any luck with increasing this setting? I am not sure if = this may be=20 causing problems or not. </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Cheryl Johnson</FONT></DIV> <DIV><FONT face=3DArial size=3D2><A=20 = href=3D"mailto:netadmin@seidata.com">netadmin@seidata.com</A></FONT></DIV= > <DIV><FONT face=3DArial size=3D2>SEI Data Network Services,=20 Inc.</FONT></DIV></BLOCKQUOTE></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A>=20 </FONT></DIV></BODY></HTML> ------=_NextPart_000_000D_01BF5C6B.65AC25E0--

Subject: Re: (usr-tc) Disconnect reasons
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-12 02:19:47

3Com has a website somewhere that explains them all. But off the top of my head, the common ones are: Gateway Disconnect Command: the ARC dropped the session, maybe because you did a "disconnect user" or rebooted the card, or more likely PPP negotiation or authentication failed. v.42 disconnect command received: The remote modem specifically told yours to hang up cleanly. Normal disconnect. Normal user call clearing: same thing. DS0 teardown: Could be normal, or could be that they hung up on you. (Call waiting, user's computer lost power, Windows crashed, whatever) Retransmit limit or unable to retrain: Usually serious line noise (maybe call waiting) killed the connnection off. Or maybe the user's got a crummy Winmodem. Protocol error event: There's probably a Rockwell HCF at the other end. Send 'em to http://808hi.com/56k/rockhcf.htm if so. :-) Anyway, that's the quick version... 3Com has a better list somewhere. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Tue, 11 Jan 2000, Greg owens wrote: > Looking at the Total Control It will list several types of disconnect reasons.....rcvdGatewayDiscCmd, NormalUserCallClear,v42DisconnectCm, along with several others...Where can I find a explanation of these reasons. Which ones other than CarrierLoss should alert me to problems other than the users just logged off. Thanks > Greg Owens > Magnolia Internet Services > http://www.magnolia-net.com >

Subject: Re: (usr-tc) v.42bis problems
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-12 02:20:11

Hm. So far it seems to be isolated to version 0.49 cards. 3Com? Any insight here? Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Sun, 9 Jan 2000, Horace Demmink wrote: > On Sun, 9 Jan 2000, Mike Andrews wrote: > > > Interesting. > > > > Any idea what hardware revision the card was? 0.49 maybe? I'm just > > trying to see if there's any pattern to these at all... > > > > > > No idea, I didn't keep record on what revision the card was. It very well > could be 0.49 (why are the hardware revisions 0.xx, are these beta release > cards? :-) as the others I installed at the same time are. > > -- > Horace Demmink > PathWay Computing > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) I just HARCed up
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-12 08:20:05

The idea is to make a smooth transition from harc v4.0.30 to v4.1.22 by putting in my cold-spare harc card in the chassis and upgrading that. Then I can move dsps to it one at a time such that we're never down and nobody gets arbitrarialy disconnected. Before I stuck another harc in the chassis, tho, I figured I'd better make sure that the dsps were owned by the existing harc so the new one wouldn't try to grab 'em. So I go into my semi-trusty HARM (v1.0.8), pick "Tables->Chassis Configuration", and for each card, I select it, hit 'Edit', click the 'owner' checkbox, and hit 'Ok'. Then click 'Set' to configure the changes. And immediately knock off all current connections, and begin refusing calls with a fast busy. I quickly go back in and put things back, and everything returns to normal. So I guess my question is, "huh?". I guess I have another question too, one which I should pose before I do anything anyway. First, my relevant version numbers: s/w h/w HDSP: 1.2.5 0.49.0 HARC: 4.0.30 1.0.0 NMC: 5.5.5 6.0 TCMW: 5.5.1 HARM: 1.0.8 I want to give hdsp v2.0.51 a shot as well as the aforementioned upgrade of the harc to 4.1.22. I have a couple of concerns about this, however. First off, my versions of nmc, tcmw, and harm are not listed in the compatability lists in the release notes for the new harc/hdsp software releases. And of course, those upgrades are unavailable to me since I let my service contract expire last year. So, I'm stuck with those. I can either use my system as it was represented to me when I bought it and live with security problems on the harc (and relatively broken code on the hdsps)....or I can upgrade to these current software versions and lose the functionality of a nmc and windows-based management. Or maybe it's not all that bad? And is there an issue with the new hdsp version on v0.49.0 dsp hardware? What's the summary on that one?

Subject: Re: (usr-tc) Disconnect reasons
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-12 10:07:43

--0__=ofJv12H3SWeAfTGjmDfTYPxnlRcjjTNf1EEIfqlVjNvanEhOG709uwPB Content-type: text/plain; charset=us-ascii Content-Disposition: inline Greg, See the Hiper Network Management Card SNMP and MIB Reference (# 1.024.1661-00), available on http://totalservice.3com.com. Chapter 24: Modem Disconnect and Fail to Connect Reason Reference is what you'll be interested in. STeve Valiunas "Greg owens" <gowens@magnolia-net.com> on 01/11/2000 07:35:08 PM Please respond to usr-tc@lists.xmission.com Sent by: "Greg owens" <gowens@magnolia-net.com> cc: (Steve Valiunas/MW/US/3Com) Looking at the Total Control It will list several types of disconnect reasons.....rcvdGatewayDiscCmd, NormalUserCallClear,v42DisconnectCm, along with several others...Where can I find a explanation of these reasons. Which ones other than CarrierLoss should alert me to problems other than the users just logged off. Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com --0__=ofJv12H3SWeAfTGjmDfTYPxnlRcjjTNf1EEIfqlVjNvanEhOG709uwPB Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgY29udGVudD0iTVNIVE1M IDUuMDAuMjYxNC4zNDAxIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT48L1NUWUxFPg0KPC9IRUFE Pg0KPEJPRFkgYmdDb2xvcj0jZmZmZmZmPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5M b29raW5nIGF0IHRoZSBUb3RhbCBDb250cm9sIEl0IHdpbGwgbGlzdCBzZXZlcmFsIA0KdHlwZXMg b2YgZGlzY29ubmVjdCByZWFzb25zLi4uLi5yY3ZkR2F0ZXdheURpc2NDbWQsIA0KTm9ybWFsVXNl ckNhbGxDbGVhcix2NDJEaXNjb25uZWN0Q20sIGFsb25nIHdpdGggc2V2ZXJhbCBvdGhlcnMuLi5X aGVyZSBjYW4gSSANCmZpbmQmbmJzcDthIGV4cGxhbmF0aW9uIG9mIHRoZXNlIHJlYXNvbnMuIFdo aWNoIG9uZXMgb3RoZXIgdGhhbiBDYXJyaWVyTG9zcyANCnNob3VsZCBhbGVydCBtZSB0byBwcm9i bGVtcyBvdGhlciB0aGFuIHRoZSB1c2VycyBqdXN0IGxvZ2dlZCBvZmYuJm5ic3A7IA0KVGhhbmtz PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5HcmVnIE93ZW5zPEJS Pk1hZ25vbGlhIEludGVybmV0IFNlcnZpY2VzPEJSPjxBIA0KaHJlZj0iaHR0cDovL3d3dy5tYWdu b2xpYS1uZXQuY29tIj5odHRwOi8vd3d3Lm1hZ25vbGlhLW5ldC5jb208L0E+IA0KPC9GT05UPjwv RElWPjwvQk9EWT48L0hUTUw+DQo= --0__=ofJv12H3SWeAfTGjmDfTYPxnlRcjjTNf1EEIfqlVjNvanEhOG709uwPB--

Subject: Re: (usr-tc) Disconnect reasons
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-12 10:23:56

This is a multi-part message in MIME format. ------=_NextPart_000_0019_01BF5CE7.222034C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks....Much obliged :-) ----- Original Message -----=20 From: Steve Valiunas=20 To: usr-tc@lists.xmission.com=20 Sent: Wednesday, January 12, 2000 10:07 AM Subject: Re: (usr-tc) Disconnect reasons Greg, See the Hiper Network Management Card SNMP and MIB Reference (# 1.024.1661-00), available on http://totalservice.3com.com. Chapter = 24: Modem Disconnect and Fail to Connect Reason Reference is what you'll be = interested in. STeve Valiunas "Greg owens" <gowens@magnolia-net.com> on 01/11/2000 07:35:08 PM Please respond to usr-tc@lists.xmission.com Sent by: "Greg owens" <gowens@magnolia-net.com> To: usr-tc@lists.xmission.com cc: (Steve Valiunas/MW/US/3Com) Subject: (usr-tc) Disconnect reasons Looking at the Total Control It will list several types of disconnect reasons.....rcvdGatewayDiscCmd, NormalUserCallClear,v42DisconnectCm, = along with several others...Where can I find a explanation of these reasons. = Which ones other than CarrierLoss should alert me to problems other than the = users just logged off. Thanks Greg Owens Magnolia Internet Services http://www.magnolia-net.com ------=_NextPart_000_0019_01BF5CE7.222034C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: = 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px"> <DIV style=3D"FONT: 10pt arial">Thanks....Much obliged :-)</DIV> <DIV style=3D"FONT: 10pt arial"> </DIV> <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV> <DIV=20 style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: = black"><B>From:</B>=20 <A href=3D"mailto:Steve_Valiunas@mw.3com.com"=20 title=3DSteve_Valiunas@mw.3com.com>Steve Valiunas</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20 href=3D"mailto:usr-tc@lists.xmission.com"=20 title=3Dusr-tc@lists.xmission.com>usr-tc@lists.xmission.com</A> </DIV> <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Wednesday, January 12, = 2000 10:07=20 AM</DIV> <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: (usr-tc) = Disconnect=20 reasons</DIV> <DIV><BR></DIV><BR><BR>Greg,<BR>     See the Hiper = Network=20 Management Card SNMP and MIB Reference (#<BR>1.024.1661-00), available = on <A=20 = href=3D"http://totalservice.3com.com">http://totalservice.3com.com</A>.&n= bsp;  =20 Chapter 24: Modem<BR>Disconnect and Fail to Connect Reason Reference = is what=20 you'll be interested in.<BR><BR>STeve = Valiunas<BR><BR><BR><BR><BR>"Greg owens"=20 <<A = href=3D"mailto:gowens@magnolia-net.com">gowens@magnolia-net.com</A>>=20 on 01/11/2000 07:35:08 PM<BR><BR>Please respond to=20 usr-tc@lists.xmission.com<BR><BR>Sent by:  "Greg owens"=20 <gowens@magnolia-net.com><BR><BR><BR>To:  =20 usr-tc@lists.xmission.com<BR>cc:    (Steve=20 Valiunas/MW/US/3Com)<BR>Subject:  (usr-tc) Disconnect=20 reasons<BR><BR><BR><BR>Looking at the Total Control It will list = several types=20 of disconnect<BR>reasons.....rcvdGatewayDiscCmd,=20 NormalUserCallClear,v42DisconnectCm, along with<BR>several = others...Where can=20 I find a explanation of these reasons. Which ones<BR>other than = CarrierLoss=20 should alert me to problems other than the users just<BR>logged = off. =20 Thanks<BR>Greg Owens<BR>Magnolia Internet=20 = Services<BR>http://www.magnolia-net.com<BR></BLOCKQUOTE></FONT></DIV></BO= DY></HTML> ------=_NextPart_000_0019_01BF5CE7.222034C0--

Subject: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG
From: Greg Long <greg@coastlink.com>
Date: 2000-01-12 10:37:49

I want to setup MRTG to monitor modem usage on my TC hub, I have the MIB's that come with the USR Suite Management Software. Can I use these MIB's or do I need to get other MIB's? Thanks, Greg Long Tech Support Coastlink 801-532-6212 ext 32 techsupp@coastlink.com http://www.coastlink.com

Subject: Re: (usr-tc) DSP cards rebooting
From: Fred Williams <fwilliams@gtnet.gov.uk>
Date: 2000-01-12 10:57:57

I have had this problem on one or two occasions. The solution in my case was to power cycle the rack. Problem then went away. On 11 Jan 00, at 17:24, Cheryl Johnson wrote: Date sent: Tue, 11 Jan 2000 17:24:34 -0500 Send reply to: usr-tc@lists.xmission.com Anyone else have this problem using the 2.0.60 version on the HiPerDSP cards?This code is supposed to help withthe modem pair problem. Althoughthis problem has not been as noticeable as the past, I still havevarious modem problems and recently noticedDSP cards rebooting.I just recently upgraded the TC chassis to the code above and seem to having problems with it. I have also been experimenting with increasing the Carrier Loss Detect Delay on the DSP cards, anyone had any luck with increasing this setting? I am not sure if this may be causing problems or not. Cheryl Johnson netadmin@seidata.com SEI Data Network Services, Inc. **************************************************************** * Fred Williams email fwilliams@gtnet.gov.uk * * CCTA voice 01603 704706 * * Rosebery Court GTN 3040 4706 * * St Andrews Business Park fax 01603 704817 * * NORWICH GTN fax 3040 4817 * * NR7 0HS UK * ****************************************************************

Subject: (usr-tc) HARC Accounting Problems/Bug???
From: John Verreault <verreaul@aei.ca>
Date: 2000-01-12 11:02:16

I have several chassis' with HARC's set up to perform Accounting as follows: Primary Server is: A Primary First Backup Server is: B When the Primary server (A) is down the accounting packets do not make it to Primary First Backup Server (B) I am using livingston radius 2.1b6 I have some HARC's with 4.1.59-6 However, I also have some HARC's running 4.2.32-1 These do fail over correctly. Is this a known problem??? Thanks John (Currently upgrading all HARCS to 4.2.32-1) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of USRobotics TC > Mailing List > Sent: Tuesday, January 11, 2000 5:01 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) IAS accounting problem with HiperArc > > > The problem went away when I upgraded the Harc to 4.1.22. > > Thanks for your help. > > Anu Jolliffe > Network Administrator > Imagen Communications Inc. > (250) 538-0406 FAX (250) 537-5820 > > > > -----Original Message----- > From: Steve Valiunas [mailto:Steve_Valiunas@mw.3com.com] > Sent: Monday, January 10, 2000 3:46 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) IAS accounting problem with HiperArc > > > > > Anu, > That would have been primary-accounting-server-2, not > secondary-server > as I > wrote, but I'm sure you checked that as well. What version of Harc code? > If > you want to capture a bit of MonitorRadius in hex mode (while sending > Malformed > packets of course), and send it to me along with the accounting sercret > used, I > can see see if anything looks whacky. > > Steve Valiunas > steve_valiunas@3com.com > > > > > > USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> on > 01/10/2000 > 05:17:26 PM > > Please respond to usr-tc@lists.xmission.com > > Sent by: USRobotics TC Mailing List > <USRoboticsTCMailingList@imagenisp.com> > > > To: "'usr-tc @lists.xmission.com'" <usr-tc@lists.xmission.com> > cc: (Steve Valiunas/MW/US/3Com) > Subject: RE: (usr-tc) IAS accounting problem with HiperArc > > > > That's the first thing I did when I ran into the problem. I even verified > the secrets on the HipeArc using the _show accounting radius secret. > > Anyone have any other suggestions? > > Anu Jolliffe > Network Administrator > Imagen Communications Inc. > (250) 538-0406 FAX (250) 537-5820 > > > > -----Original Message----- > From: Steve Valiunas [mailto:Steve_Valiunas@mw.3com.com] > Sent: Monday, January 10, 2000 8:44 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) IAS accounting problem with HiperArc > > > > > Check your secondary-server's shared secret. > > STeve Valiunas > > > > > USRobotics TC Mailing List <USRoboticsTCMailingList@imagenisp.com> on > 01/09/2000 > 03:01:53 PM > > Please respond to usr-tc@lists.xmission.com > > Sent by: USRobotics TC Mailing List > <USRoboticsTCMailingList@imagenisp.com> > > > To: "USRobotics TC Mailing List > cc: (Steve Valiunas/MW/US/3Com) > Subject: (usr-tc) IAS accounting problem with HiperArc > > > > I am having a problem with my HiperArc and accounting using Microsoft IAS. > I have my first accounting server specified as the primary accounting > server, and everything is working fine as is. > > The problem I'm having is related to my second server, which I > intend to use > as a backup in case the first one goes down. > > When my second server is set as the secondary server, everything > works okay. > However, when I have my second server set as the primary first backup, no > accounting records are recorded and the NT event log is full of malformed > packets. > > What is different about the packets when they are sent to the server > configured as the primary first backup versus the secondary? > > My other chassis which runs a NSC has no problem at all with the second > server. > > Thanks for your help. > Anu Jolliffe > Network Administrator > Imagen Communications Inc. > (250) 538-0406 FAX (250) 537-5820 > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51
From: pferraro@wna-linknet.com
Date: 2000-01-12 11:18:48

Would like to hear from anyone who has been running this code for a few weeks... We are looking to upgrade our hubs, but want to make sure there are no inherent problems with moving to this code combination. We are currently running 4.1.59-6 and DSP 2.0.81 without any problems. We also have 2 hubs that have quads running the latest TC3.6 suite and HiperArcs Also want to make sure there are no problems moving the HiperArcs in those chassis to 4.1.22 Any and all comments welcome! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: Re: (usr-tc) RADIUS check items?
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 2000-01-12 11:36:19

On Tue, 11 Jan 2000, Jesse Sipprell wrote: > Can anyone tell me what RADIUS check attributes are sent (by the HARC) in the > initial auth request packet in order to determine an Async or ISDN call? Run radiusd -x to be sure, but for starters check the dictionary: ATTRIBUTE NAS-Port-Type 61 integer VALUE NAS-Port-Type Async 0 VALUE NAS-Port-Type Sync 1 VALUE NAS-Port-Type ISDN 2 VALUE NAS-Port-Type ISDN-V120 3 VALUE NAS-Port-Type ISDN-V110 4 > > Thanks! > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800.496.4736 > > * Finger jss@evcom.net for my PGP Public Key * > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > ============================================================================ Jeffrey A. Lynch | JORSM Internet, Regional Internet Services email: jeff@jorsm.com | 7 Area Codes in Chicagoland and NW Indiana Voice: (219)322-2180 | 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN Autoresponse: info@jorsm.com | Quality Service, Affordable Prices http://www.jorsm.com | Serving Gov, Biz, Residential Since 1995

Subject: (usr-tc) IPX Config Help
From: Chris Hanes <chanes@usacars.com>
Date: 2000-01-12 11:55:07

I'm having trouble getting IPX to work on my boxes. Each box is receiving ipx routes and sap info from my Cisco, but that info is not being propagated to dialin sessions. Currently routing is set to listen only; does this need to be set to broadcast in order for the routes to be sent to the modem connections? Also, radius is sending Framed-Routing = Listen and Framed-IPX-Network = 255.255.255.254. What am I missing here? Thanks. Chris Hanes Network Admin Internet Connections

Subject: Re: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG
From: Steve McConnell <stevem@emji.net>
Date: 2000-01-12 12:41:30

you should be able to use Eric Billeters scripts that come with MRTG in the contrib directory under TCH ( I am still using MRTG2.7.2- so these may have changed) works like a dream. steve --On Wednesday, January 12, 2000 10:37 AM -0700 Greg Long <greg@coastlink.com> wrote: > I want to setup MRTG to monitor modem usage on my TC hub, I have the MIB's > that come with the USR Suite Management Software. Can I use these MIB's > or do I need to get other MIB's? > > Thanks, > Greg Long > Tech Support > Coastlink > 801-532-6212 ext 32 > techsupp@coastlink.com > http://www.coastlink.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Steve McConnell EMJI 919-303-3217x126 888-258-8959

Subject: (usr-tc) DSP Problems/Losing modems
From: Christopher Berry <berryc@rof.net>
Date: 2000-01-12 12:45:42

This is a multi-part message in MIME format. ------=_NextPart_000_004C_01BF5CFA.F015C080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have had perennial problems with Hiper modems suddenly not = responding. Every other day I get a random modem or two that stops = responding per card. Rarely a software reset will return the modem to = service. Usually, I wait a week until I have several, then do a hardware = reset. This returns most to service, except the occasional bad channel.=20 I am running 2.0.60 per 3com. I am not using 2.0.51 as I am under the = impression it is for a newer hardware version than we own. I have not yet upgraded the Hiperarc software to the latest-I am waiting = for the next time I do aforementioned hardware resets. (Day traders get = very upset if they get booted : ). Suggestions and questions? Thanks Christopher Berry rof.net Web Design and Technical Support (970) 945-4920 x17 ------=_NextPart_000_004C_01BF5CFA.F015C080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2919.6307" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>We have had perennial problems with Hiper modems = suddenly not=20 responding. Every other day I get a random modem or two that stops = responding=20 per card. Rarely a software reset will return the modem to service. = Usually, I=20 wait a week until I have several, then do a hardware reset. This returns = most to=20 service, except the occasional bad channel. </FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>I am running 2.0.60 per 3com. I am not using 2.0.51 = as I am=20 under the impression it is for a newer hardware version than we=20 own.</FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>I have not yet upgraded the Hiperarc software to the = latest-I=20 am waiting for the next time I do aforementioned hardware resets. (Day = traders=20 get very upset if they get booted : ).</FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>Suggestions and questions?</FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>Thanks</FONT></DIV> <DIV> </DIV> <DIV><FONT size=3D2>Christopher Berry<BR>rof.net Web Design and = Technical=20 Support<BR>(970) 945-4920 x17<BR></FONT></DIV></BODY></HTML> ------=_NextPart_000_004C_01BF5CFA.F015C080--

Subject: RE: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG
From: Greg Long <greg@coastlink.com>
Date: 2000-01-12 13:51:55

Aha! I think I've got it running now. Thanks for the info. I really didn't want to create something from scratch. I can tweak this now if need be. -Greg -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve McConnell Sent: Wednesday, January 12, 2000 10:42 AM you should be able to use Eric Billeters scripts that come with MRTG in the contrib directory under TCH ( I am still using MRTG2.7.2- so these may have changed) works like a dream. steve --On Wednesday, January 12, 2000 10:37 AM -0700 Greg Long <greg@coastlink.com> wrote: > I want to setup MRTG to monitor modem usage on my TC hub, I have the MIB's > that come with the USR Suite Management Software. Can I use these MIB's > or do I need to get other MIB's? > > Thanks, > Greg Long > Tech Support > Coastlink > 801-532-6212 ext 32 > techsupp@coastlink.com > http://www.coastlink.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Steve McConnell EMJI 919-303-3217x126 888-258-8959 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51
From: Ronald Kushner <ron@glis.net>
Date: 2000-01-12 13:52:18

pferraro@wna-linknet.com wrote: > > Would like to hear from anyone who has been running this code for > a few weeks... We are looking to upgrade our hubs, but want to make sure > there are no inherent problems with moving to this code combination. We > are currently running 4.1.59-6 and DSP 2.0.81 without any problems. I went to upgrade one ARC to 4.1.22 from 4.1.59-6 and ran into problems with routes added by netmgr not being broadcast out with RIP. After dicking with it for a couple hours I gave up. I am running 2.0.51 without a problem on the DSPs. BTW: Why the hell is poison reverse and split horizon both turned on by default? Doesn't poison reverse defeat split horizon? -Ron GLISnet, Inc. +1 810/939.9885

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Mark E. Levy <mark@fsi.net>
Date: 2000-01-12 14:36:04

Not that I can see. I'm running 2.0.51 on 0.49 & 0.53 rev DSPs. I had problems with 2.0.60 with Rockwell modems (so much so that I went back to 2.0.19), and although the release notes indicate that there is still an unresolved issue with 2.0.51 & Rockwell disconnects on the speed shift, it's working much better. John Verreault wrote: > > Is there a problem running 2.0.51 on older revs??? > > Thanks > John -- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.net

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Nicolas St-Pierre <nstpierre@iasl.com>
Date: 2000-01-12 15:03:43

The HiPer DSP code 2.0.60 will usually put timeslots Local Out of Service when a modem pair fails to reset. While this is still better than 2.0.81 where you may get fast busies or no answer, it's still not a complete solution. This scenario is true when the DSP mdmfail is set to Combo mode and the call routing method mdmrmeth is set to fixed assignment. You should only run 2.0.51 if you have a rev 0.55 with Alliance SRAM chips on it instead of ISSI chips. Other 0.55 boards and older revs should run fine on 2.0.60 eventhough we have to put up with this annoying bug until 3Com fixes it. Nick -- Nicolas St-Pierre Systems Engineer Internet Access Solutions Ltd. Tel (905) 469-4953 Fax (905) 469-4954

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-12 15:17:40

At 12:45 PM 1/12/00 -0700, Christopher Berry wrote: > We have had perennial problems with Hiper modems suddenly not >responding. Every other day I get a random modem or two that stops >responding per card. Rarely a software reset will return the modem to >service. Usually, I wait a week until I have several, then do a hardware >reset. This returns most to service, except the occasional bad channel. You can soft-busy the modems through TCM to bypass them. Normally what I'll do is soft-busy the rest of the card when my nightime useage decreases. This won't knock anybody off but will prevent new connections, By morning, everyone's off the card and I can reset it without affecting anybody. >I am running 2.0.60 per 3com. I am not using 2.0.51 as I am under the >impression it is for a newer hardware version than we own. I have not >yet upgraded the Hiperarc software to the latest-I am waiting for the next >time I do aforementioned hardware resets. (Day traders get very upset if >they get booted : ). Suggestions and questions? I had been seeing modem lockups at least weekly with 3 DSPs(0.49.0). I upgraded to ARC 4.2.32/DSP 2.0.81 about 3 months ago. Since then, I had my first modem lockup last night. Needless to say, this has been a great inprovement. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) DSP Problems/Losing modems
From: John Verreault <verreaul@aei.ca>
Date: 2000-01-12 15:27:56

Is there a problem running 2.0.51 on older revs??? Thanks John > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Nicolas St-Pierre > Sent: Wednesday, January 12, 2000 3:04 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) DSP Problems/Losing modems > > > > > The HiPer DSP code 2.0.60 will usually put timeslots Local Out of > Service when a modem pair fails to reset. While this is still better > than 2.0.81 where you may get fast busies or no answer, it's still not a > complete solution. This scenario is true when the DSP mdmfail is set to > Combo mode and the call routing method mdmrmeth is set to fixed > assignment. > > You should only run 2.0.51 if you have a rev 0.55 with Alliance SRAM > chips on it instead of ISSI chips. Other 0.55 boards and older revs > should run fine on 2.0.60 eventhough we have to put up with this > annoying bug until 3Com fixes it. > > > Nick > > > > -- > Nicolas St-Pierre > Systems Engineer > Internet Access Solutions Ltd. > Tel (905) 469-4953 > Fax (905) 469-4954 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Christopher Berry <berryc@rof.net>
Date: 2000-01-12 16:04:39

Thanks- I will try this on a card or two and see. We have problems with Rockwell modems anyway-Compaqs and Macs-But suggest that the users update via softpaq (for Compaqs) or go with v.34 (for Macs-most lines here are phone company limited to 26400 anyway). Will post any relevant data. Christopher Berry rof.net Web Design and Technical Support (970) 945-4920 x17 ----- Original Message ----- Sent: Wednesday, January 12, 2000 1:36 PM > Not that I can see. I'm running 2.0.51 on 0.49 & 0.53 rev DSPs. I had > problems with 2.0.60 with Rockwell modems (so much so that I went back > to 2.0.19), and although the release notes indicate that there is still > an unresolved issue with 2.0.51 & Rockwell disconnects on the speed > shift, it's working much better. > > John Verreault wrote: > > > > Is there a problem running 2.0.51 on older revs??? > > > > Thanks > > John > -- > --------------------------------------------------------------------- > Mark E. Levy, President > FSINet, Inc. > 800-827-6085 x202 > 847-753-6832 fax > www.fsi.net > mark@fsi.net > --------------------------------------------------------------------- > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) HiperARC 4.1.22 and 5.10.9 Quads
From: Andrew Smith <smitha@rciol.com>
Date: 2000-01-12 17:02:43

Will HiperArc version 4.1.22 work with: NMC 5.5.5 Quad Modem version 5.10.9 Dual Channelized T1 (386) 4.2.1 I'm scared to upgrade to 6.1.6 on the Single-Sided Quads. 5.10.9 is very stable for us. Anyone running 6.1.6 fine??? - andrew

Subject: (usr-tc) HyperARC/DSP Problem
From: Scot bethke <kbethke@ezy.net>
Date: 2000-01-12 17:31:06

This is a multi-part message in MIME format. ------=_NextPart_000_03A0_01BF5D22.CED3C700 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am having the absolute worst time trying to get my HyperDSP cards = working in any capacity what-so-ever. Hoping someone from here has seen = this or can tell me what to check. First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 = Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both = 1.2.5 and 2.0.51 software. Im using PRI's and they both show up as UP = and OPERATIONAL. (2) Problems... First of all I cant manage the cards (any of them) with = TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What = happenes is I select the card, click on configure, click on card level = and then click ok. I can get the=20 Hyper DSP/ARC Information item, and all values come in and display fine. = However I click on "Routing Method" and it comes up with this: Error Type: No Data Available Parameter: Modem Routing Method Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 Same type of message comes up on every query except info. I can = communicate with the NMC card just fine (its an older NMC, not a = HyperNMC). So I had to go in and USE HARM to program the HyperARC (that = works fine btw), and I programmed the DSP's with a terminal. Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell = atlantic says everything is fine with both of them. But they refuse to = hunt from the first hyperDSP to the second. I plug in the first PRI = into either DSP card and it takes calls and works like a charm till it = gets to channel 23, where we get a fast busy from then on. Im hoping = there is a special "Oh you havemore than one hyperDSP" button that I = need to push. anyone know what might cause this? -Scott ------=_NextPart_000_03A0_01BF5D22.CED3C700 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>I am having the absolute worst time = trying to get=20 my HyperDSP cards working in any capacity what-so-ever.  Hoping = someone=20 from here has seen this or can tell me what to check.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>First i'm running HyperARC HW Version = 19.0.0, with=20 Version 4.1.59 Software.  HyperDSP's are HW V 0.49.0, and I have = thus far=20 tried both 1.2.5 and 2.0.51 software.  Im using PRI's and they both = show up=20 as UP and OPERATIONAL.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>(2) Problems...  First of all I = cant manage=20 the cards (any of them) with TCM.  Running 6.0.23, had the same = problem on=20 5.X TCM as well.  What happenes is I select the card, click on = configure,=20 click on card level and then click ok.  I can get the </FONT></DIV> <DIV><FONT face=3DArial size=3D2>Hyper DSP/ARC Information item, and all = values come=20 in and display fine.  However I click on "Routing Method" and it = comes up=20 with this:</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Error Type:    No Data=20 Available</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Parameter:    Modem = Routing=20 Method</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Object ID:    =20 1.3.6.1.4.1.429.1.26.1.1.1.2.14000</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Same type of message comes up on every = query except=20 info.  I can communicate with the NMC card just fine (its an older = NMC, not=20 a HyperNMC).  So I had to go in and USE HARM to program the = HyperARC (that=20 works fine btw), and I programmed the DSP's with a = terminal.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Second Issue (and this is the big one) = I have two=20 PRI's, 23B+D, Bell atlantic says everything is fine with both of = them.  But=20 they refuse to hunt from the first hyperDSP to the second.  I plug = in the=20 first PRI into either DSP card and it takes calls and works like a charm = till it=20 gets to channel 23, where we get a fast busy from then on.  Im = hoping there=20 is a special "Oh you havemore than one hyperDSP" button that I need to=20 push.  anyone know what might cause this?</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>-Scott</FONT></DIV></BODY></HTML> ------=_NextPart_000_03A0_01BF5D22.CED3C700--

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-12 19:07:22

The docs actually mention rev 54 & 55 for it. I have put it on all of mine which are 53's and 54's with no ill effects so far. Its been about a week. At 03:03 PM 1/12/00 -0500, you wrote: > The HiPer DSP code 2.0.60 will usually put timeslots Local Out of >Service when a modem pair fails to reset. While this is still better >than 2.0.81 where you may get fast busies or no answer, it's still not a >complete solution. This scenario is true when the DSP mdmfail is set to >Combo mode and the call routing method mdmrmeth is set to fixed >assignment. > >You should only run 2.0.51 if you have a rev 0.55 with Alliance SRAM >chips on it instead of ISSI chips. Other 0.55 boards and older revs >should run fine on 2.0.60 eventhough we have to put up with this >annoying bug until 3Com fixes it. > > >Nick > > > >-- >Nicolas St-Pierre >Systems Engineer >Internet Access Solutions Ltd. >Tel (905) 469-4953 >Fax (905) 469-4954 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) HiperARC 4.1.22 and 5.10.9 Quads
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-12 19:17:01

We've been running it for weeks with no apparent problems. I don't know if its any better but it's certainly not any worse. At 05:02 PM 1/12/00 -0600, you wrote: >Will HiperArc version 4.1.22 work with: > >NMC 5.5.5 >Quad Modem version 5.10.9 >Dual Channelized T1 (386) 4.2.1 > >I'm scared to upgrade to 6.1.6 on the Single-Sided Quads. 5.10.9 is very >stable for us. Anyone running 6.1.6 fine??? > >- > andrew > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-12 22:28:03

Thus spake Scot bethke >Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell >atlantic says everything is fine with both of them. But they refuse to >hunt from the first hyperDSP to the second. I plug in the first PRI >into either DSP card and it takes calls and works like a charm till it >gets to channel 23, where we get a fast busy from then on. Im hoping >there is a special "Oh you havemore than one hyperDSP" button that I >need to push. anyone know what might cause this? Get Hell Atlantic back on the line and smack them upside the head with a clue by four. :) If the both cards are taking calls, then there's a problem with the hunting and that's all telco there. There is no way to configure your equipment to control the hunt group in any way. The originating side (the telco in this case) decides where to send the call, the receiving side has no say in the matter other than to possibly reject the call (resulting in either a fast busy/reorder tone type of response to the caller, or a user busy if its rejected with cause code 17). I suspect that they've set it up as two seperate trunk groups and not got the hunting between them configured correctly. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-12 23:52:58

Are you sure that you don't have a hung modem that is stopping the hunt group (not answering the phone)? Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Wed, 12 Jan 2000, Scot bethke wrote: > I am having the absolute worst time trying to get my HyperDSP cards working in any capacity what-so-ever. Hoping someone from here has seen this or can tell me what to check. > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 and 2.0.51 software. Im using PRI's and they both show up as UP and OPERATIONAL. > > (2) Problems... First of all I cant manage the cards (any of them) with TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What happenes is I select the card, click on configure, click on card level and then click ok. I can get the > Hyper DSP/ARC Information item, and all values come in and display fine. However I click on "Routing Method" and it comes up with this: > > Error Type: No Data Available > Parameter: Modem Routing Method > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > Same type of message comes up on every query except info. I can communicate with the NMC card just fine (its an older NMC, not a HyperNMC). So I had to go in and USE HARM to program the HyperARC (that works fine btw), and I programmed the DSP's with a terminal. > > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell atlantic says everything is fine with both of them. But they refuse to hunt from the first hyperDSP to the second. I plug in the first PRI into either DSP card and it takes calls and works like a charm till it gets to channel 23, where we get a fast busy from then on. Im hoping there is a special "Oh you havemore than one hyperDSP" button that I need to push. anyone know what might cause this? > > -Scott >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-12 23:52:58

Subject: Re: (usr-tc) HiperARC 4.1.22 and 5.10.9 Quads
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-13 00:01:07

6.1.6 seems safe here; we've been running it for months. We're a PRI shop though. Is 5.5.5 the newest NMC code you can run? The newer the better... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Wed, 12 Jan 2000, Andrew Smith wrote: > > Will HiperArc version 4.1.22 work with: > > NMC 5.5.5 > Quad Modem version 5.10.9 > Dual Channelized T1 (386) 4.2.1 > > I'm scared to upgrade to 6.1.6 on the Single-Sided Quads. 5.10.9 is very > stable for us. Anyone running 6.1.6 fine???

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-13 00:03:12

What software version is your NMC? It almost sounds like you've got a 4 meg NMC, which isn't going to be able to manage a DSP at all -- gotta have 16 meg and the 16 meg code. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Wed, 12 Jan 2000, Scot bethke wrote: > I am having the absolute worst time trying to get my HyperDSP cards working in any capacity what-so-ever. Hoping someone from here has seen this or can tell me what to check. > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 and 2.0.51 software. Im using PRI's and they both show up as UP and OPERATIONAL. > > (2) Problems... First of all I cant manage the cards (any of them) with TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What happenes is I select the card, click on configure, click on card level and then click ok. I can get the > Hyper DSP/ARC Information item, and all values come in and display fine. However I click on "Routing Method" and it comes up with this: > > Error Type: No Data Available > Parameter: Modem Routing Method > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > Same type of message comes up on every query except info. I can communicate with the NMC card just fine (its an older NMC, not a HyperNMC). So I had to go in and USE HARM to program the HyperARC (that works fine btw), and I programmed the DSP's with a terminal. > > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell atlantic says everything is fine with both of them. But they refuse to hunt from the first hyperDSP to the second. I plug in the first PRI into either DSP card and it takes calls and works like a charm till it gets to channel 23, where we get a fast busy from then on. Im hoping there is a special "Oh you havemore than one hyperDSP" button that I need to push. anyone know what might cause this? > > -Scott >

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-13 00:07:48

2.0.51 works on my 0.53 rev modems just as well as it works on the 0.54 ones. Same with 0.49, save one v.42bis related problem I mentioned earlier -- and I'm 99.99% sure that has nothing to do with the fact that I've got 2.0.51 on it. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Wed, 12 Jan 2000, Mark E. Levy wrote: > Not that I can see. I'm running 2.0.51 on 0.49 & 0.53 rev DSPs. I had > problems with 2.0.60 with Rockwell modems (so much so that I went back > to 2.0.19), and although the release notes indicate that there is still > an unresolved issue with 2.0.51 & Rockwell disconnects on the speed > shift, it's working much better. > > John Verreault wrote: > > > > Is there a problem running 2.0.51 on older revs??? > > > > Thanks > > John > -- > --------------------------------------------------------------------- > Mark E. Levy, President > FSINet, Inc. > 800-827-6085 x202 > 847-753-6832 fax > www.fsi.net > mark@fsi.net > --------------------------------------------------------------------- > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) DSP cards rebooting
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-13 08:28:54

The hardware revision on our DSP cards are 0.49. I specifically upgraded to this code because it was supposed to help with the pair modem issue. I may try the 2.0.51 in a test lab before implementing this for a while. Cheryl Johnson netadmin@seidata.com SEI Data Network Services, Inc. ----- Original Message ----- Sent: Tuesday, January 11, 2000 5:37 PM > If your cards are hardware revision 0.55 or 0.54, try loading 2.0.51 on > them... > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville > "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." > > On Tue, 11 Jan 2000, Cheryl Johnson wrote: > > > Anyone else have this problem using the 2.0.60 version on the HiPerDSP cards? This code is supposed to help with the modem pair problem. Although this problem has not been as noticeable as the past, I still have various modem problems and recently noticed DSP cards rebooting. I just recently upgraded the TC chassis to the code above and seem to having problems with it. I have also been experimenting with increasing the Carrier Loss Detect Delay on the DSP cards, anyone had any luck with increasing this setting? I am not sure if this may be causing problems or not. > > > > Cheryl Johnson > > netadmin@seidata.com > > SEI Data Network Services, Inc. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) DSP cards rebooting
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-13 08:41:27

Just thought of this..is the 2.0.51 recommended for hardware revision 0.49 or just for 0.54 or 0.55? ' ----- Original Message ----- Sent: Tuesday, January 11, 2000 5:37 PM > If your cards are hardware revision 0.55 or 0.54, try loading 2.0.51 on > them... > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, & Shelbyville > "It's a dog-eat-dog world, and I'm wearing Milk-Bone underwear." > > On Tue, 11 Jan 2000, Cheryl Johnson wrote: > > > Anyone else have this problem using the 2.0.60 version on the HiPerDSP cards? This code is supposed to help with the modem pair problem. Although this problem has not been as noticeable as the past, I still have various modem problems and recently noticed DSP cards rebooting. I just recently upgraded the TC chassis to the code above and seem to having problems with it. I have also been experimenting with increasing the Carrier Loss Detect Delay on the DSP cards, anyone had any luck with increasing this setting? I am not sure if this may be causing problems or not. > > > > Cheryl Johnson > > netadmin@seidata.com > > SEI Data Network Services, Inc. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Scot bethke <kbethke@ezy.net>
Date: 2000-01-13 08:46:08

How would I tell if I had a hung modem? well wait now if I had a hung modem though wouldnt it be caught when I pluged the initial PRI into the next card.. When I do that it will take all calls to capacity and still not hunt over to the next set of PRI's -Scott ----- Original Message ----- Cc: <usr-tc@xmission.com> Sent: Wednesday, January 12, 2000 11:52 PM > Are you sure that you don't have a hung modem that is stopping the hunt > group (not answering the phone)? > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Wed, 12 Jan 2000, Scot bethke wrote: > > > I am having the absolute worst time trying to get my HyperDSP cards working in any capacity what-so-ever. Hoping someone from here has seen this or can tell me what to check. > > > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 and 2.0.51 software. Im using PRI's and they both show up as UP and OPERATIONAL. > > > > (2) Problems... First of all I cant manage the cards (any of them) with TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What happenes is I select the card, click on configure, click on card level and then click ok. I can get the > > Hyper DSP/ARC Information item, and all values come in and display fine. However I click on "Routing Method" and it comes up with this: > > > > Error Type: No Data Available > > Parameter: Modem Routing Method > > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > > > Same type of message comes up on every query except info. I can communicate with the NMC card just fine (its an older NMC, not a HyperNMC). So I had to go in and USE HARM to program the HyperARC (that works fine btw), and I programmed the DSP's with a terminal. > > > > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell atlantic says everything is fine with both of them. But they refuse to hunt from the first hyperDSP to the second. I plug in the first PRI into either DSP card and it takes calls and works like a charm till it gets to channel 23, where we get a fast busy from then on. Im hoping there is a special "Oh you havemore than one hyperDSP" button that I need to push. anyone know what might cause this? > > > > -Scott > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-13 10:06:21

Just something to check.... never overlook the obvious because *sometimes* telco is right. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 13 Jan 2000, Scot bethke wrote: > How would I tell if I had a hung modem? well wait now if I had a hung > modem though wouldnt it be caught when I pluged the initial PRI into the > next card.. When I do that it will take all calls to capacity and still not > hunt over to the next set of PRI's > > -Scott > > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Cc: <usr-tc@xmission.com> > Sent: Wednesday, January 12, 2000 11:52 PM > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > > Are you sure that you don't have a hung modem that is stopping the hunt > > group (not answering the phone)? > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Wed, 12 Jan 2000, Scot bethke wrote: > > > > > I am having the absolute worst time trying to get my HyperDSP cards > working in any capacity what-so-ever. Hoping someone from here has seen > this or can tell me what to check. > > > > > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 > Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 > and 2.0.51 software. Im using PRI's and they both show up as UP and > OPERATIONAL. > > > > > > (2) Problems... First of all I cant manage the cards (any of them) with > TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What > happenes is I select the card, click on configure, click on card level and > then click ok. I can get the > > > Hyper DSP/ARC Information item, and all values come in and display fine. > However I click on "Routing Method" and it comes up with this: > > > > > > Error Type: No Data Available > > > Parameter: Modem Routing Method > > > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > > > > > Same type of message comes up on every query except info. I can > communicate with the NMC card just fine (its an older NMC, not a HyperNMC). > So I had to go in and USE HARM to program the HyperARC (that works fine > btw), and I programmed the DSP's with a terminal. > > > > > > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell > atlantic says everything is fine with both of them. But they refuse to hunt > from the first hyperDSP to the second. I plug in the first PRI into either > DSP card and it takes calls and works like a charm till it gets to channel > 23, where we get a fast busy from then on. Im hoping there is a special "Oh > you havemore than one hyperDSP" button that I need to push. anyone know > what might cause this? > > > > > > -Scott > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Scot bethke <kbethke@ezy.net>
Date: 2000-01-13 10:20:57

Well that gets me back to my original question though how do I check modem status for a hung modem. -Scott ----- Original Message ----- Sent: Thursday, January 13, 2000 10:06 AM > Just something to check.... never overlook the obvious because *sometimes* > telco is right. > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Thu, 13 Jan 2000, Scot bethke wrote: > > > How would I tell if I had a hung modem? well wait now if I had a hung > > modem though wouldnt it be caught when I pluged the initial PRI into the > > next card.. When I do that it will take all calls to capacity and still not > > hunt over to the next set of PRI's > > > > -Scott > > > > ----- Original Message ----- > > From: "Paul Farber" <farber@admin.f-tech.net> > > To: <usr-tc@lists.xmission.com> > > Cc: <usr-tc@xmission.com> > > Sent: Wednesday, January 12, 2000 11:52 PM > > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > > > > > Are you sure that you don't have a hung modem that is stopping the hunt > > > group (not answering the phone)? > > > > > > Paul Farber > > > Farber Technology > > > farber@admin.f-tech.net > > > Ph 570-628-5303 > > > Fax 570-628-5545 > > > > > > On Wed, 12 Jan 2000, Scot bethke wrote: > > > > > > > I am having the absolute worst time trying to get my HyperDSP cards > > working in any capacity what-so-ever. Hoping someone from here has seen > > this or can tell me what to check. > > > > > > > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 > > Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 > > and 2.0.51 software. Im using PRI's and they both show up as UP and > > OPERATIONAL. > > > > > > > > (2) Problems... First of all I cant manage the cards (any of them) with > > TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What > > happenes is I select the card, click on configure, click on card level and > > then click ok. I can get the > > > > Hyper DSP/ARC Information item, and all values come in and display fine. > > However I click on "Routing Method" and it comes up with this: > > > > > > > > Error Type: No Data Available > > > > Parameter: Modem Routing Method > > > > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > > > > > > > Same type of message comes up on every query except info. I can > > communicate with the NMC card just fine (its an older NMC, not a HyperNMC). > > So I had to go in and USE HARM to program the HyperARC (that works fine > > btw), and I programmed the DSP's with a terminal. > > > > > > > > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell > > atlantic says everything is fine with both of them. But they refuse to hunt > > from the first hyperDSP to the second. I plug in the first PRI into either > > DSP card and it takes calls and works like a charm till it gets to channel > > 23, where we get a fast busy from then on. Im hoping there is a special "Oh > > you havemore than one hyperDSP" button that I need to push. anyone know > > what might cause this? > > > > > > > > -Scott > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Netserver PRI Max connections
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-13 10:29:45

It sounds like the rest of the modems aren't set "active" on the netserver. You can see the current status like so: FX-1-NSVR> show modem Starting Slot: 2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - S1 S5 S9 S13 S17 - - - S33 S37 - - - - - - S2 S6 S10 S14 S18 - - - S34 S38 - - - - - - S3 S7 S11 S15 S19 - - - S35 S39 - - - - - - S4 S8 S12 S16 S20 - - - S36 S40 - - - - - You have to make sure each modem shows up in this table. The top row is the slot number. I'm a bit rusty on the netserver, but I think this will set a modem active: FX-1-NSVR> set modem s21 active S21 - active (s7 , c1 ) FX-1-NSVR> show modem Starting Slot: 2 \/ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - S1 S5 S9 S13 S17 S21 - - S33 S37 - - - - - - S2 S6 S10 S14 S18 - - - S34 S38 - - - - - - S3 S7 S11 S15 S19 - - - S35 S39 - - - - - - S4 S8 S12 S16 S20 - - - S36 S40 - - - - - Hope that helps, Charles On Thu, 13 Jan 2000, Phil Le Clercq wrote: > Hi all, I have a chassis with dual pri, 56 digital modems ( 14 quads) and > one Netserver (3.8.1). > My problem is the chassis never takes more than 30 calls. Both PRI's > (European) are working ok, I got the telco to busy out the other feeds so > all calls went to this chassis. > You can see the modem's taking the call but above 30 connections the user > gets "disconnected from the remote machine" as an error. > I believe the problem lies with the Netserver. I guess I'm just missing a > command to set max connections to 56 but I cant remember or find it! > I presumed that Netservers were set to 60 connections by default, this is > something I've not had to do before as all our others chassis' have 30 ports > only. > Thanks in advance for any help :-) > Cheers, Phil > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-13 10:30:01

At 08:46 AM 1/13/00 -0500, Scot bethke wrote: >How would I tell if I had a hung modem? well wait now if I had a hung >modem though wouldnt it be caught when I pluged the initial PRI into the >next card.. When I do that it will take all calls to capacity and still not >hunt over to the next set of PRI's I use a perl script to check for hung modems. You can see the output at http://www.keyconn.net/mrtg/modem-fail.htm When one(a pair actually) hangs, it won't be long till you're getting calls reporting "computer is not answering". My failure ratios don't exceed 2.5-3% unless I've got a pair hung, and it rapidly climbs above 5% when they do. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-13 11:01:34

On Thu, 13 Jan 2000, Paul Farber wrote: The easiest way I can think of to verify this to be true or not is to busy out the first PRI and then see if you can dial the number or not. If there's a question about a hung modem, reverse the PRI's on your chassis and then try it. It's been my experience that fast busy has usually been an issue on the telco side or that our DS1 span provisioning isn't right in the card. The other thing you will want to check (which wouldn't cause a fast busy but could cause standard busy) is to have them check the hunt group size on the PRI. Also, if you're talking with provisioning, have them do an ISDN trace and see which trunk is causing the fast busy not to mention how many trunks they're going into. Kevin Benton Network Administrator SOTANet LLC, A Voyager.net Company > Just something to check.... never overlook the obvious because *sometimes* > telco is right. > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Thu, 13 Jan 2000, Scot bethke wrote: > > > How would I tell if I had a hung modem? well wait now if I had a hung > > modem though wouldnt it be caught when I pluged the initial PRI into the > > next card.. When I do that it will take all calls to capacity and still not > > hunt over to the next set of PRI's > > > > -Scott > > > > ----- Original Message ----- > > From: "Paul Farber" <farber@admin.f-tech.net> > > To: <usr-tc@lists.xmission.com> > > Cc: <usr-tc@xmission.com> > > Sent: Wednesday, January 12, 2000 11:52 PM > > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > > > > > Are you sure that you don't have a hung modem that is stopping the hunt > > > group (not answering the phone)? > > > > > > Paul Farber > > > Farber Technology > > > farber@admin.f-tech.net > > > Ph 570-628-5303 > > > Fax 570-628-5545 > > > > > > On Wed, 12 Jan 2000, Scot bethke wrote: > > > > > > > I am having the absolute worst time trying to get my HyperDSP cards > > working in any capacity what-so-ever. Hoping someone from here has seen > > this or can tell me what to check. > > > > > > > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 > > Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 > > and 2.0.51 software. Im using PRI's and they both show up as UP and > > OPERATIONAL. > > > > > > > > (2) Problems... First of all I cant manage the cards (any of them) with > > TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What > > happenes is I select the card, click on configure, click on card level and > > then click ok. I can get the > > > > Hyper DSP/ARC Information item, and all values come in and display fine. > > However I click on "Routing Method" and it comes up with this: > > > > > > > > Error Type: No Data Available > > > > Parameter: Modem Routing Method > > > > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > > > > > > > Same type of message comes up on every query except info. I can > > communicate with the NMC card just fine (its an older NMC, not a HyperNMC). > > So I had to go in and USE HARM to program the HyperARC (that works fine > > btw), and I programmed the DSP's with a terminal. > > > > > > > > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell > > atlantic says everything is fine with both of them. But they refuse to hunt > > from the first hyperDSP to the second. I plug in the first PRI into either > > DSP card and it takes calls and works like a charm till it gets to channel > > 23, where we get a fast busy from then on. Im hoping there is a special "Oh > > you havemore than one hyperDSP" button that I need to push. anyone know > > what might cause this? > > > > > > > > -Scott > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: RE: (usr-tc) Netserver PRI Max connections
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-13 11:02:46

It's a dumb question, but you do have a big enough IP pool, right? :) Charles On Thu, 13 Jan 2000, Phil Le Clercq wrote: > Cheers for the reply, but that part is ok as you can see below. All modems > are taking calls, for round robin is set up on the chassis. Calls go through > the whole chassis no problems, but only in a maximum chunk of 30. The > trouble is this chassis is the last in the line of the telco's first > available PRI's. I guess I'll just have to stay up late tonight and and > double check the telco bit is correct.... > Heh if I was in the States and was only getting 26 calls then at least I > would know it was the telco setup for (fairly) sure! :-) > > Cheers, Phil > > > Starting Slot: 1 > > 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 > --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- > S1 S5 S9 S13 S17 S21 S25 S29 S33 S37 S41 S45 S49 S53 S57 - > S2 S6 S10 S14 S18 S22 S26 S30 S34 S38 S42 S46 S50 S54 S58 - > S3 S7 S11 S15 S19 S23 S27 S31 S35 S39 S43 S47 S51 S55 S59 - > S4 S8 S12 S16 S20 S24 S28 S32 S36 S40 S44 S48 S52 S56 S60 - > > -----Original Message----- > From: Charles Sprickman [mailto:spork@inch.com] > Sent: Thursday, January 13, 2000 3:30 PM > To: TCH List (E-mail) > Subject: Re: (usr-tc) Netserver PRI Max connections > > It sounds like the rest of the modems aren't set "active" on > the > netserver. You can see the current status like so: > > FX-1-NSVR> show modem > Starting Slot: 2 > > 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > 16 > --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- > --- > - S1 S5 S9 S13 S17 - - - S33 S37 - - - - > - > - S2 S6 S10 S14 S18 - - - S34 S38 - - - - > - > - S3 S7 S11 S15 S19 - - - S35 S39 - - - - > - > - S4 S8 S12 S16 S20 - - - S36 S40 - - - - > - > > You have to make sure each modem shows up in this table. > The top row is > the slot number. I'm a bit rusty on the netserver, but I > think this will > set a modem active: > > FX-1-NSVR> set modem s21 active > S21 - active (s7 , c1 ) > > FX-1-NSVR> show modem > Starting Slot: 2 > \/ > 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 > 16 > --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- > --- > - S1 S5 S9 S13 S17 S21 - - S33 S37 - - - - > - > - S2 S6 S10 S14 S18 - - - S34 S38 - - - - > - > - S3 S7 S11 S15 S19 - - - S35 S39 - - - - > - > - S4 S8 S12 S16 S20 - - - S36 S40 - - - - > - > > Hope that helps, > > Charles > > On Thu, 13 Jan 2000, Phil Le Clercq wrote: > > > Hi all, I have a chassis with dual pri, 56 digital modems > ( 14 quads) and > > one Netserver (3.8.1). > > My problem is the chassis never takes more than 30 calls. > Both PRI's > > (European) are working ok, I got the telco to busy out the > other feeds so > > all calls went to this chassis. > > You can see the modem's taking the call but above 30 > connections the user > > gets "disconnected from the remote machine" as an error. > > I believe the problem lies with the Netserver. I guess I'm > just missing a > > command to set max connections to 56 but I cant remember > or find it! > > I presumed that Netservers were set to 60 connections by > default, this is > > something I've not had to do before as all our others > chassis' have 30 ports > > only. > > Thanks in advance for any help :-) > > Cheers, Phil > > > > - > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your > message. > > > > > - > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old > messages send > "help" to the same address. Do not use quotes in your > message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-13 11:26:48

Call in to the rack and see if you get 'dead air'. IE pick up with no negotiation. Or if you get a busy but still have open modems. I don't think there is a way in TCM to check it. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Thu, 13 Jan 2000, Scot bethke wrote: > Well that gets me back to my original question though how do I check modem > status for a hung modem. > > -Scott > > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, January 13, 2000 10:06 AM > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > > Just something to check.... never overlook the obvious because *sometimes* > > telco is right. > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Thu, 13 Jan 2000, Scot bethke wrote: > > > > > How would I tell if I had a hung modem? well wait now if I had a hung > > > modem though wouldnt it be caught when I pluged the initial PRI into the > > > next card.. When I do that it will take all calls to capacity and still > not > > > hunt over to the next set of PRI's > > > > > > -Scott > > > > > > ----- Original Message ----- > > > From: "Paul Farber" <farber@admin.f-tech.net> > > > To: <usr-tc@lists.xmission.com> > > > Cc: <usr-tc@xmission.com> > > > Sent: Wednesday, January 12, 2000 11:52 PM > > > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > > > > > > > > Are you sure that you don't have a hung modem that is stopping the > hunt > > > > group (not answering the phone)? > > > > > > > > Paul Farber > > > > Farber Technology > > > > farber@admin.f-tech.net > > > > Ph 570-628-5303 > > > > Fax 570-628-5545 > > > > > > > > On Wed, 12 Jan 2000, Scot bethke wrote: > > > > > > > > > I am having the absolute worst time trying to get my HyperDSP cards > > > working in any capacity what-so-ever. Hoping someone from here has seen > > > this or can tell me what to check. > > > > > > > > > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 > > > Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both > 1.2.5 > > > and 2.0.51 software. Im using PRI's and they both show up as UP and > > > OPERATIONAL. > > > > > > > > > > (2) Problems... First of all I cant manage the cards (any of them) > with > > > TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What > > > happenes is I select the card, click on configure, click on card level > and > > > then click ok. I can get the > > > > > Hyper DSP/ARC Information item, and all values come in and display > fine. > > > However I click on "Routing Method" and it comes up with this: > > > > > > > > > > Error Type: No Data Available > > > > > Parameter: Modem Routing Method > > > > > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > > > > > > > > > Same type of message comes up on every query except info. I can > > > communicate with the NMC card just fine (its an older NMC, not a > HyperNMC). > > > So I had to go in and USE HARM to program the HyperARC (that works fine > > > btw), and I programmed the DSP's with a terminal. > > > > > > > > > > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell > > > atlantic says everything is fine with both of them. But they refuse to > hunt > > > from the first hyperDSP to the second. I plug in the first PRI into > either > > > DSP card and it takes calls and works like a charm till it gets to > channel > > > 23, where we get a fast busy from then on. Im hoping there is a special > "Oh > > > you havemore than one hyperDSP" button that I need to push. anyone know > > > what might cause this? > > > > > > > > > > -Scott > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-13 12:37:16

At 11:26 AM 1/13/00 -0500, Paul Farber wrote: >Call in to the rack and see if you get 'dead air'. IE pick up with no >negotiation. This isn't always conclusive. You may have a customer getting "dead air" and, since that channel's in use, you'll get rolled over to a working modem. >Or if you get a busy but still have open modems. I don't think there is a >way in TCM to check it. I'm not aware of any way to through TCM either. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: (usr-tc) Lt WinModems and TCR
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-13 13:00:24

What kind of problems is everybody experiencing with Lt WinModems connecting at v.90 to the TCH's? What have you guys done to fix this problem? We are using both the old TCH's and the HiPer TCH's. Bryan NOC Technician COX Internet

Subject: Re: (usr-tc) Lt WinModems and TCR
From: John Nelson <johnn@jorsm.com>
Date: 2000-01-13 13:02:00

Some people can make a V90 connection, but if there is any line noise at all kiss it goodbye. AT-V90=0 -John- "The NOC (COX Internet)" wrote: > What kind of problems is everybody experiencing with Lt WinModems connecting > at v.90 to the TCH's? What have you guys done to fix this problem? We are > using both the old TCH's and the HiPer TCH's. > > Bryan > NOC Technician > COX Internet > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ========================================================= \. -John Nelson \ email: \.--Technical Support \ johnn@jorsm.com \.---JORSM Internet \ \.----Toll Free 1-877-Jorsm95 \ ========================================================== ========================================================== \. JORSM Internet \. Regional Premium Internet Service Provider \. Serving Chicagoland and NW Indiana \. 927 Sheffield Ave Dyer, IN \. Tech hours: M-F 9-9, Sat 10-2 http://www.jorsm.com =========================================================

Subject: (usr-tc) Odd Problem
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-13 13:30:24

This problem as stumped us from a while. Here is the situation: We have a ISD that is using ISDN to dial into one of our older TCHs. They can dial in a connect. When they try to go to a web page using the DNS name they can not go to it. They can type in the ip address to get to it but not the dns. Here is where it gets strange. They can connect to two other isp's without any problems and they can surf the net just fine. We have checked just about everything that is possible to check, including making sure it wasn't looking for a auto-proxy. This ISD is the only person that is having this problem. As a side note, we have a profiles set up for our ISDN customers on that TCH. Bryan NOC Technician COX Internet

Subject: (usr-tc) Moving Profiles
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-13 13:42:26

How do you go about setting up profiles for ISDN on a HiPer machine? I cannot seem to find that information anywhere. Thanks, Bryan NOC Technician COX Internet

Subject: (usr-tc) Netserver PRI Max connections
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 2000-01-13 13:49:42

Hi all, I have a chassis with dual pri, 56 digital modems ( 14 quads) and one Netserver (3.8.1). My problem is the chassis never takes more than 30 calls. Both PRI's (European) are working ok, I got the telco to busy out the other feeds so all calls went to this chassis. You can see the modem's taking the call but above 30 connections the user gets "disconnected from the remote machine" as an error. I believe the problem lies with the Netserver. I guess I'm just missing a command to set max connections to 56 but I cant remember or find it! I presumed that Netservers were set to 60 connections by default, this is something I've not had to do before as all our others chassis' have 30 ports only. Thanks in advance for any help :-) Cheers, Phil

Subject: RE: (usr-tc) Odd Problem
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-13 13:50:28

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX |Internet) |Sent: Thursday, January 13, 2000 1:30 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Odd Problem | | | |This problem as stumped us from a while. Here is the situation: | |We have a ISD that is using ISDN to dial into one of our older TCHs. They |can dial in a connect. When they try to go to a web page using the DNS name |they can not go to it. They can type in the ip address to get to |it but not |the dns. Were you providing the ISD a valid DNS server address during IPCP? The symptom sounds like the client didnt have any DNS server configured. | Here is where it gets strange. They can connect to two other |isp's without any problems and they can surf the net just fine. We have |checked just about everything that is possible to check, including making |sure it wasn't looking for a auto-proxy. This ISD is the only person that |is having this problem. As a side note, we have a profiles set up for our |ISDN customers on that TCH. | |Bryan |NOC Technician |COX Internet | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |

Subject: Re: (usr-tc) Odd Problem
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-13 13:54:28

Honestly I do not remember. I was not the primary technician working on this problem. But I do believe it was either Cisco or the Ascend Pipeline ISDN router. The ISD gave us like a hour to fix the problem before they switched providers and obviously we didn't make the time limit. Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Thursday, January 13, 2000 1:24 PM > What ISDN equipment is the customer using? Is it Cisco perhaps? I've seen > this before with Cisco (don't recall what version of IOS though). I believe > the resolve was > > no ip mroute-cache > > -- > Scot > > > ----- Original Message ----- > From: The NOC (COX Internet) <usrtc@tyler.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, January 13, 2000 2:30 PM > Subject: (usr-tc) Odd Problem > > > > > > This problem as stumped us from a while. Here is the situation: > > > > We have a ISD that is using ISDN to dial into one of our older TCHs. They > > can dial in a connect. When they try to go to a web page using the DNS > name > > they can not go to it. They can type in the ip address to get to it but > not > > the dns. Here is where it gets strange. They can connect to two other > > isp's without any problems and they can surf the net just fine. We have > > checked just about everything that is possible to check, including making > > sure it wasn't looking for a auto-proxy. This ISD is the only person that > > is having this problem. As a side note, we have a profiles set up for our > > ISDN customers on that TCH. > > > > Bryan > > NOC Technician > > COX Internet > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Odd Problem
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-13 14:04:35

Kirk, Yes. This was done. Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Thursday, January 13, 2000 1:41 PM > At 01:30 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: > > > >This problem as stumped us from a while. Here is the situation: > > > >We have a ISD that is using ISDN to dial into one of our older TCHs. They > >can dial in a connect. When they try to go to a web page using the DNS name > >they can not go to it. They can type in the ip address to get to it but not > >the dns. Here is where it gets strange. They can connect to two other > >isp's without any problems and they can surf the net just fine. We have > >checked just about everything that is possible to check, including making > >sure it wasn't looking for a auto-proxy. This ISD is the only person that > >is having this problem. As a side note, we have a profiles set up for our > >ISDN customers on that TCH. > > Check TCP/IP's DNS settings in the connectoid, make sure it's set to your > servers or server assigned. > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Netserver PRI Max connections
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-13 14:08:17

> Heh if I was in the States and was only getting 26 calls then at least I > would know it was the telco setup for (fairly) sure! :-) Actually, in the states, it would be 23 calls on a PRI or 24 on a T1 ;-)

Subject: Re: (usr-tc) Odd Problem
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-13 14:24:10

What ISDN equipment is the customer using? Is it Cisco perhaps? I've seen this before with Cisco (don't recall what version of IOS though). I believe the resolve was no ip mroute-cache -- Scot ----- Original Message ----- Sent: Thursday, January 13, 2000 2:30 PM > > This problem as stumped us from a while. Here is the situation: > > We have a ISD that is using ISDN to dial into one of our older TCHs. They > can dial in a connect. When they try to go to a web page using the DNS name > they can not go to it. They can type in the ip address to get to it but not > the dns. Here is where it gets strange. They can connect to two other > isp's without any problems and they can surf the net just fine. We have > checked just about everything that is possible to check, including making > sure it wasn't looking for a auto-proxy. This ISD is the only person that > is having this problem. As a side note, we have a profiles set up for our > ISDN customers on that TCH. > > Bryan > NOC Technician > COX Internet > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Scot bethke <kbethke@ezy.net>
Date: 2000-01-13 14:25:59

Well Bell Atlantic just called back, they set up a protocol Analyzer on the trunks and said my HyperDSPs are returning a "NO CHANNELS AVAILABLE" error when they dial in past the last channel on my first PRI.. Now again I have swapped the PRI's so I know that both cards work. Would there be something I'm missing here to tell these cards (or the Harc) that they need to pass stuff over to the second PRI? -Scott ----- Original Message ----- Sent: Thursday, January 13, 2000 11:01 AM > On Thu, 13 Jan 2000, Paul Farber wrote: > > The easiest way I can think of to verify this to be true or not is to busy > out the first PRI and then see if you can dial the number or not. If > there's a question about a hung modem, reverse the PRI's on your chassis > and then try it. It's been my experience that fast busy has usually been > an issue on the telco side or that our DS1 span provisioning isn't right > in the card. The other thing you will want to check (which wouldn't cause > a fast busy but could cause standard busy) is to have them check the hunt > group size on the PRI. Also, if you're talking with provisioning, have > them do an ISDN trace and see which trunk is causing the fast busy not to > mention how many trunks they're going into. > > Kevin Benton > Network Administrator > SOTANet LLC, A Voyager.net Company > > > Just something to check.... never overlook the obvious because *sometimes* > > telco is right. > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Thu, 13 Jan 2000, Scot bethke wrote: > > > > > How would I tell if I had a hung modem? well wait now if I had a hung > > > modem though wouldnt it be caught when I pluged the initial PRI into the > > > next card.. When I do that it will take all calls to capacity and still not > > > hunt over to the next set of PRI's > > > > > > -Scott > > > > > > ----- Original Message ----- > > > From: "Paul Farber" <farber@admin.f-tech.net> > > > To: <usr-tc@lists.xmission.com> > > > Cc: <usr-tc@xmission.com> > > > Sent: Wednesday, January 12, 2000 11:52 PM > > > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > > > > > > > > Are you sure that you don't have a hung modem that is stopping the hunt > > > > group (not answering the phone)? > > > > > > > > Paul Farber > > > > Farber Technology > > > > farber@admin.f-tech.net > > > > Ph 570-628-5303 > > > > Fax 570-628-5545 > > > > > > > > On Wed, 12 Jan 2000, Scot bethke wrote: > > > > > > > > > I am having the absolute worst time trying to get my HyperDSP cards > > > working in any capacity what-so-ever. Hoping someone from here has seen > > > this or can tell me what to check. > > > > > > > > > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 > > > Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 > > > and 2.0.51 software. Im using PRI's and they both show up as UP and > > > OPERATIONAL. > > > > > > > > > > (2) Problems... First of all I cant manage the cards (any of them) with > > > TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What > > > happenes is I select the card, click on configure, click on card level and > > > then click ok. I can get the > > > > > Hyper DSP/ARC Information item, and all values come in and display fine. > > > However I click on "Routing Method" and it comes up with this: > > > > > > > > > > Error Type: No Data Available > > > > > Parameter: Modem Routing Method > > > > > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > > > > > > > > > Same type of message comes up on every query except info. I can > > > communicate with the NMC card just fine (its an older NMC, not a HyperNMC). > > > So I had to go in and USE HARM to program the HyperARC (that works fine > > > btw), and I programmed the DSP's with a terminal. > > > > > > > > > > Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell > > > atlantic says everything is fine with both of them. But they refuse to hunt > > > from the first hyperDSP to the second. I plug in the first PRI into either > > > DSP card and it takes calls and works like a charm till it gets to channel > > > 23, where we get a fast busy from then on. Im hoping there is a special "Oh > > > you havemore than one hyperDSP" button that I need to push. anyone know > > > what might cause this? > > > > > > > > > > -Scott > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-13 14:35:53

Is this an NFAS problem? Our PRI lines all appear as a single trunk at the telco, controlled by the NFAS functionality across as many PRI lines that are included in the NFAS group. At least that is how the switch guys described it to me. All I do at my end is make sure the second, third, etc. card are set up as being a member of the NFAS group, and determine whether I am going to add additional d channels for redundancy. If the PRI lines are not part of an NFAS group, then there must be some sort of hunting or rollover involved. It is very similar to the way our incoming T1's are handled, they all are piled into one big group as available lines with no hunting set up at all. While hunting would be beneficial in some troubleshooting situations we had it get messed up so many times they moved to this mode. Any time we add lines the switch tech just adds the transport layer to the group and whamo, there are additional lines at our site that work without the intervention of some other "programming tech" at the telco. Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-13 14:39:48

At 02:25 PM 1/13/00 -0500, Scot bethke wrote: >Well Bell Atlantic just called back, they set up a protocol Analyzer on the >trunks and said my HyperDSPs are returning a "NO CHANNELS AVAILABLE" error >when they dial in past the last channel on my first PRI.. Now again I have >swapped the PRI's so I know that both cards work. Would there be something >I'm missing here to tell these cards (or the Harc) that they need to pass >stuff over to the second PRI? Maybe this was asked or answered already, but are the switch and framing types set properly under trunk settings? -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Odd Problem
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-13 14:41:39

At 01:30 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: > >This problem as stumped us from a while. Here is the situation: > >We have a ISD that is using ISDN to dial into one of our older TCHs. They >can dial in a connect. When they try to go to a web page using the DNS name >they can not go to it. They can type in the ip address to get to it but not >the dns. Here is where it gets strange. They can connect to two other >isp's without any problems and they can surf the net just fine. We have >checked just about everything that is possible to check, including making >sure it wasn't looking for a auto-proxy. This ISD is the only person that >is having this problem. As a side note, we have a profiles set up for our >ISDN customers on that TCH. Check TCP/IP's DNS settings in the connectoid, make sure it's set to your servers or server assigned. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Moving Profiles
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-13 14:42:33

Kirk, We have our connection profiles stored on our TCH. We have an older TCH that is dying on us and we need to move the connection profiles over to the new HiPer TCH. Bryan ----- Original Message ----- Sent: Thursday, January 13, 2000 1:52 PM > At 01:42 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: > > > >How do you go about setting up profiles for ISDN on a HiPer machine? I > >cannot seem to find that information anywhere. > > The only difference between IDSN and dial-up is allowing concurrent > connections. > > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Moving Profiles
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-13 14:52:26

At 01:42 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: > >How do you go about setting up profiles for ISDN on a HiPer machine? I >cannot seem to find that information anywhere. The only difference between IDSN and dial-up is allowing concurrent connections. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Moving Profiles
From: Richard Lorbieski <richard@alpha1.net>
Date: 2000-01-13 15:03:45

It's much easier/management to setup as a radius profile than store them in the hiperARC. "The NOC (COX Internet)" wrote: > > Kirk, > > We have our connection profiles stored on our TCH. We have an older TCH > that is dying on us and we need to move the connection profiles over to the > new HiPer TCH. > > Bryan > > ----- Original Message ----- > From: "K Mitchell" <mitch@keyconn.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, January 13, 2000 1:52 PM > Subject: Re: (usr-tc) Moving Profiles > > > At 01:42 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: > > > > > >How do you go about setting up profiles for ISDN on a HiPer machine? I > > >cannot seem to find that information anywhere. > > > > The only difference between IDSN and dial-up is allowing concurrent > > connections. > > > > > > -- > > Kirk Mitchell-General Manager mitch@keyconn.net > > Keystone Connect Unlock Your World > > Altoona, PA 814-941-5000 http://www.keyconn.net > > -- Richard Lorbieski - richard@alpha1.net Chief Technical Officer - Senior System Administrator Alpha1 Internet http://www.alpha1.net 409.731.8236 - 877.4.alpha1 (877.425.7421)

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-13 15:19:08

On Thu, 13 Jan 2000, Scot bethke wrote: > Well Bell Atlantic just called back, they set up a protocol Analyzer on the > trunks and said my HyperDSPs are returning a "NO CHANNELS AVAILABLE" error > when they dial in past the last channel on my first PRI.. Now again I have > swapped the PRI's so I know that both cards work. Would there be something > I'm missing here to tell these cards (or the Harc) that they need to pass > stuff over to the second PRI? Nope. Absolutely nothing. Now, on the other hand, if you do a list interfaces, what does it give back to you? Is the HARC seeing the channels up and available on your second DSP? If not, what does list chassis give back to you? Here's the deal - hunting from PRI to PRI is a telco switch side issue. If all channels are up and running on your PRI's, then it's the telco's responsibility to pass those calls to you in some fashion. Did you ask them when they did an ISDN trace how many trunks were in the group? 1? 2? x? To do that trace, you'll need to give them the lead phone number for your hunt group. What I would do is the following... 1) Select the second DSP. 2) Click on the actions button. 3) Click on Hardware and change it to Software. 4) Click on No Command and change it to Restore T1/E1 and Modems from Default. 5) Click on Execute. 6) When the result is successful click on Save both T1/E1 and Modems to NVRAM. 7) Click on Execute. 8) When the result is successful, click on Software and change it to Hardware. 9) Click on Hardware No Command and change it to Hardware Reset. When the result is successful, close that window, then re-program your DSP's T1 level settings by hand after it comes back up. This will guard against old settings interfering with current issues. You know that DSP #1 works. The best way I've found to program these settings is to open up the programmed settings for both DSP's simultaneously by clicking on the first DSP's T1 then control clicking on the second DSP's T1. Then you should be able to manually set copy the information. I have personally run into a few cases where old settings did interfere with current settings and restoring to factory default has saved me a bunch of time and effort from past attempts to fix things. I have also found that using "Load From" isn't the best way to change settings and know that they're set accurately. Make sure that if you're expecting DNIS that the telco is sending it. If not, the DSP will not accept the call. If there is still an issue, have the telco provisioning people go back and compare PRI #1 versus #2. If they're not identical in translations, have them fix #2 to match #1. If they tell you that things are identical after all that, then maybe Krish would be willing to help you or your 3Com sales rep may send you over to an NC who might help. Nope, I don't work for 3Com. I just teach people how to use their stuff... :) Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Scot bethke <kbethke@ezy.net>
Date: 2000-01-13 15:26:29

> Maybe this was asked or answered already, but are the switch and framing > types set properly under trunk settings? Yes they are, we prove this by putting the working PRI on both DSP cards and it takes calls fine.

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-13 15:32:08

I *still* think there is a hunt group problem with that first PRI. If the BA switch does not know that there is a second trunk in the group, then of course, the HiperDSP will return NO CHANNELS, because the telco switch is trying to pass a 24th call to the first PRI. Telco switch is supposed to pass that 24th call to the next trunk in the hunt group which would be your 2nd PRI. Technically speaking, I don't know enough about PRI call control, so I don't know if the telco switch is keeping track of how many active channels there are on a PRI (via the D channel), and making it's own determination to bump the call the the next PRI in the hunt group, or it asks the HiperDSP (again, via the D channel) how many channels are available, and if it's 0, the telco switch moves to the next PRI in the hunt group..... Either way, I believe that the DSP is supposed to return that indicator when all channels are full. Telco switch should now hunt the call, which it does not appear to be doing. Have them try switching the hunt method -- if they are set to top-down (sequential), change to round-robin/random, or vice-versa. Maybe they have something funky in the hunt config. Just some ideas... -- Scot ----- Original Message ----- Sent: Thursday, January 13, 2000 2:25 PM > Well Bell Atlantic just called back, they set up a protocol Analyzer on the > trunks and said my HyperDSPs are returning a "NO CHANNELS AVAILABLE" error > when they dial in past the last channel on my first PRI.. Now again I have > swapped the PRI's so I know that both cards work. Would there be something > I'm missing here to tell these cards (or the Harc) that they need to pass > stuff over to the second PRI? > > -Scott > > ----- Original Message ----- > From: "Kevin Benton" <s1kevin@tims.net> > To: <usr-tc@lists.xmission.com> > Sent: Thursday, January 13, 2000 11:01 AM > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > > On Thu, 13 Jan 2000, Paul Farber wrote: > > > > The easiest way I can think of to verify this to be true or not is to busy > > out the first PRI and then see if you can dial the number or not. If > > there's a question about a hung modem, reverse the PRI's on your chassis > > and then try it. It's been my experience that fast busy has usually been > > an issue on the telco side or that our DS1 span provisioning isn't right > > in the card. The other thing you will want to check (which wouldn't cause > > a fast busy but could cause standard busy) is to have them check the hunt > > group size on the PRI. Also, if you're talking with provisioning, have > > them do an ISDN trace and see which trunk is causing the fast busy not to > > mention how many trunks they're going into. > > > > Kevin Benton > > Network Administrator > > SOTANet LLC, A Voyager.net Company > > > > > Just something to check.... never overlook the obvious because > *sometimes* > > > telco is right. > > > > > > Paul Farber > > > Farber Technology > > > farber@admin.f-tech.net > > > Ph 570-628-5303 > > > Fax 570-628-5545 > > > > > > On Thu, 13 Jan 2000, Scot bethke wrote: > > > > > > > How would I tell if I had a hung modem? well wait now if I had a > hung > > > > modem though wouldnt it be caught when I pluged the initial PRI into > the > > > > next card.. When I do that it will take all calls to capacity and > still not > > > > hunt over to the next set of PRI's > > > > > > > > -Scott > > > > > > > > ----- Original Message ----- > > > > From: "Paul Farber" <farber@admin.f-tech.net> > > > > To: <usr-tc@lists.xmission.com> > > > > Cc: <usr-tc@xmission.com> > > > > Sent: Wednesday, January 12, 2000 11:52 PM > > > > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > > > > > > > > > > > Are you sure that you don't have a hung modem that is stopping the > hunt > > > > > group (not answering the phone)? > > > > > > > > > > Paul Farber > > > > > Farber Technology > > > > > farber@admin.f-tech.net > > > > > Ph 570-628-5303 > > > > > Fax 570-628-5545 > > > > > > > > > > On Wed, 12 Jan 2000, Scot bethke wrote: > > > > > > > > > > > I am having the absolute worst time trying to get my HyperDSP > cards > > > > working in any capacity what-so-ever. Hoping someone from here has > seen > > > > this or can tell me what to check. > > > > > > > > > > > > First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 > > > > Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both > 1.2.5 > > > > and 2.0.51 software. Im using PRI's and they both show up as UP and > > > > OPERATIONAL. > > > > > > > > > > > > (2) Problems... First of all I cant manage the cards (any of > them) with > > > > TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What > > > > happenes is I select the card, click on configure, click on card level > and > > > > then click ok. I can get the > > > > > > Hyper DSP/ARC Information item, and all values come in and display > fine. > > > > However I click on "Routing Method" and it comes up with this: > > > > > > > > > > > > Error Type: No Data Available > > > > > > Parameter: Modem Routing Method > > > > > > Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 > > > > > > > > > > > > Same type of message comes up on every query except info. I can > > > > communicate with the NMC card just fine (its an older NMC, not a > HyperNMC). > > > > So I had to go in and USE HARM to program the HyperARC (that works > fine > > > > btw), and I programmed the DSP's with a terminal. > > > > > > > > > > > > Second Issue (and this is the big one) I have two PRI's, 23B+D, > Bell > > > > atlantic says everything is fine with both of them. But they refuse > to hunt > > > > from the first hyperDSP to the second. I plug in the first PRI into > either > > > > DSP card and it takes calls and works like a charm till it gets to > channel > > > > 23, where we get a fast busy from then on. Im hoping there is a > special "Oh > > > > you havemore than one hyperDSP" button that I need to push. anyone > know > > > > what might cause this? > > > > > > > > > > > > -Scott > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages > send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > E-Mail: s1kevin@tims.net > > Web: http://users.sota-oh.com/~s1kevin/ > > Unsolicited advertisements processing fee: $50 subject to change without > notice > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) v.42bis problems
From: David Bachta <david_bachta@mw.3com.com>
Date: 2000-01-13 15:36:14

Hi Mike, This is a hardware failure on that specific card. There are 2 separate processors for the data path (v42bis processing occurs in this portion of the card). Each one of these processors controls half of the modems on the card. You likely have some sort of failure in the first processor... which is why you only see the problem on the first 12 ports. Hope this helps. Regards, David Mike Andrews <mandrews@bit0.com> on 01/12/2000 01:20:11 AM Please respond to usr-tc@lists.xmission.com Sent by: Mike Andrews <mandrews@bit0.com> cc: (David Bachta/MW/US/3Com) Hm. So far it seems to be isolated to version 0.49 cards. 3Com? Any insight here? Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Sun, 9 Jan 2000, Horace Demmink wrote: > On Sun, 9 Jan 2000, Mike Andrews wrote: > > > Interesting. > > > > Any idea what hardware revision the card was? 0.49 maybe? I'm just > > trying to see if there's any pattern to these at all... > > > > > > No idea, I didn't keep record on what revision the card was. It very well > could be 0.49 (why are the hardware revisions 0.xx, are these beta release > cards? :-) as the others I installed at the same time are. > > -- > Horace Demmink > PathWay Computing > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Moving Profiles
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-13 15:37:37

Richard, You would think so but our Technical Guru in that market doesn't trust our new Radius server. Therefore we need to find out how to store those profiles on that HiPer TCH. Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Thursday, January 13, 2000 3:03 PM > It's much easier/management to setup as a radius profile than store them > in the hiperARC. > > "The NOC (COX Internet)" wrote: > > > > Kirk, > > > > We have our connection profiles stored on our TCH. We have an older TCH > > that is dying on us and we need to move the connection profiles over to the > > new HiPer TCH. > > > > Bryan > > > > ----- Original Message ----- > > From: "K Mitchell" <mitch@keyconn.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Thursday, January 13, 2000 1:52 PM > > Subject: Re: (usr-tc) Moving Profiles > > > > > At 01:42 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: > > > > > > > >How do you go about setting up profiles for ISDN on a HiPer machine? I > > > >cannot seem to find that information anywhere. > > > > > > The only difference between IDSN and dial-up is allowing concurrent > > > connections. > > > > > > > > > -- > > > Kirk Mitchell-General Manager mitch@keyconn.net > > > Keystone Connect Unlock Your World > > > Altoona, PA 814-941-5000 http://www.keyconn.net > > > > > -- > > Richard Lorbieski - richard@alpha1.net > Chief Technical Officer - Senior System Administrator > Alpha1 Internet http://www.alpha1.net > 409.731.8236 - 877.4.alpha1 (877.425.7421) > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Moving Profiles
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-13 15:37:37

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-13 15:38:42

At 03:26 PM 1/13/00 -0500, Scot bethke wrote: >> Maybe this was asked or answered already, but are the switch and framing >> types set properly under trunk settings? > >Yes they are, we prove this by putting the working PRI on both DSP cards and >it takes calls fine. My mistake, I overlooked the "swapped the PRI's so I know that both cards work" in your message. It would appear that this problem is unavoidably telco-based. One of the things we do when ordering PRI is specify that each one has it's own lead dial-in number for testing purposes. The PRI still works as usual within the hunt group, but you have the ability to dial into a specific PRI. This ability would help determine whether your problems are rollover based, or specific to the line itself. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: RE: (usr-tc) Netserver PRI Max connections
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 2000-01-13 15:48:17

Cheers for the reply, but that part is ok as you can see below. All modems are taking calls, for round robin is set up on the chassis. Calls go through the whole chassis no problems, but only in a maximum chunk of 30. The trouble is this chassis is the last in the line of the telco's first available PRI's. I guess I'll just have to stay up late tonight and and double check the telco bit is correct.... Heh if I was in the States and was only getting 26 calls then at least I would know it was the telco setup for (fairly) sure! :-) Cheers, Phil Starting Slot: 1 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- S1 S5 S9 S13 S17 S21 S25 S29 S33 S37 S41 S45 S49 S53 S57 - S2 S6 S10 S14 S18 S22 S26 S30 S34 S38 S42 S46 S50 S54 S58 - S3 S7 S11 S15 S19 S23 S27 S31 S35 S39 S43 S47 S51 S55 S59 - S4 S8 S12 S16 S20 S24 S28 S32 S36 S40 S44 S48 S52 S56 S60 - -----Original Message----- From: Charles Sprickman [mailto:spork@inch.com] Sent: Thursday, January 13, 2000 3:30 PM To: TCH List (E-mail) Subject: Re: (usr-tc) Netserver PRI Max connections It sounds like the rest of the modems aren't set "active" on the netserver. You can see the current status like so: FX-1-NSVR> show modem Starting Slot: 2 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - S1 S5 S9 S13 S17 - - - S33 S37 - - - - - - S2 S6 S10 S14 S18 - - - S34 S38 - - - - - - S3 S7 S11 S15 S19 - - - S35 S39 - - - - - - S4 S8 S12 S16 S20 - - - S36 S40 - - - - - You have to make sure each modem shows up in this table. The top row is the slot number. I'm a bit rusty on the netserver, but I think this will set a modem active: FX-1-NSVR> set modem s21 active S21 - active (s7 , c1 ) FX-1-NSVR> show modem Starting Slot: 2 \/ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- - S1 S5 S9 S13 S17 S21 - - S33 S37 - - - - - - S2 S6 S10 S14 S18 - - - S34 S38 - - - - - - S3 S7 S11 S15 S19 - - - S35 S39 - - - - - - S4 S8 S12 S16 S20 - - - S36 S40 - - - - - Hope that helps, Charles On Thu, 13 Jan 2000, Phil Le Clercq wrote: > Hi all, I have a chassis with dual pri, 56 digital modems ( 14 quads) and > one Netserver (3.8.1). > My problem is the chassis never takes more than 30 calls. Both PRI's > (European) are working ok, I got the telco to busy out the other feeds so > all calls went to this chassis. > You can see the modem's taking the call but above 30 connections the user > gets "disconnected from the remote machine" as an error. > I believe the problem lies with the Netserver. I guess I'm just missing a > command to set max connections to 56 but I cant remember or find it! > I presumed that Netservers were set to 60 connections by default, this is > something I've not had to do before as all our others chassis' have 30 ports > only. > Thanks in advance for any help :-) > Cheers, Phil > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Correction
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 2000-01-13 15:50:32

Ooops! You run 24 channels not 26 "over there" :-) doh! Phil

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-13 16:02:15

Thus spake Scot Desort >I *still* think there is a hunt group problem with that first PRI. If the BA >switch does not know that there is a second trunk in the group, then of >course, the HiperDSP will return NO CHANNELS, because the telco switch is >trying to pass a 24th call to the first PRI. Telco switch is supposed to >pass that 24th call to the next trunk in the hunt group which would be your >2nd PRI. >Technically speaking, I don't know enough about PRI call control, so I don't >know if the telco switch is keeping track of how many active channels there >are on a PRI (via the D channel), and making it's own determination to bump >the call the the next PRI in the hunt group, or it asks the HiperDSP (again, >via the D channel) how many channels are available, and if it's 0, the telco >switch moves to the next PRI in the hunt group..... The telco switch keeps track of how many channels are available. >Either way, I believe that the DSP is supposed to return that indicator when >all channels are full. Bzzt...no can do. There is no indication such as this. If the DSP (or any PRI equipment) returns an indication that it doesn't have any trunks available, the caller gets a busy indication of some kind (either regular user busy, or some sort of reorder tone), the call does *not* get re-hunted, its released. In all actuality, if all 23 channels are full, the telco switch shouldn't send a request on the D channel at all since it already knows that the span is already full. If it does send a D channel message, there's a *SERIOUS* bug in the telco switch code...and that's rather unlikely. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Netserver PRI Max connections
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 2000-01-13 16:10:50

Yep it's set to 60. "Assigned Pool Size: 60" Phil -----Original Message----- From: Charles Sprickman [mailto:spork@inch.com] Sent: Thursday, January 13, 2000 4:03 PM To: 'usr-tc@lists.xmission.com' Subject: RE: (usr-tc) Netserver PRI Max connections It's a dumb question, but you do have a big enough IP pool, right? :) Charles

Subject: Re: (usr-tc) Lt WinModems and TCR
From: Jim Faulkner <jlf@montrose-colo.com>
Date: 2000-01-13 16:13:05

I have problems with them all the time. I either give them my analog modem phone number and or suggest that they upgrade their winmodem drivers to the latest version which usually fixes the problem. Jim Faulkner GWE.NET ----- Original Message ----- Sent: Thursday, January 13, 2000 12:00 PM > > What kind of problems is everybody experiencing with Lt WinModems connecting > at v.90 to the TCH's? What have you guys done to fix this problem? We are > using both the old TCH's and the HiPer TCH's. > > Bryan > NOC Technician > COX Internet > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) HyperARC/DSP Problem
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-13 16:55:15

That was my original thought when this thread started. If that's the case, you need to set the NFAS Interface ID on your second card to whatever the telco has it set to on their end and the Logical Group Number to the same number as your first card. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Mark Thornton [mailto:mark@corridor.net] > Sent: Thursday, January 13, 2000 4:36 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > Is this an NFAS problem? Our PRI lines all appear as a single > trunk at the > telco, controlled by the NFAS functionality across as many > PRI lines that > are included in the NFAS group. At least that is how the switch guys > described it to me. All I do at my end is make sure the > second, third, etc. > card are set up as being a member of the NFAS group, and > determine whether I > am going to add additional d channels for redundancy. If the > PRI lines are > not part of an NFAS group, then there must be some sort of hunting or > rollover involved. > > It is very similar to the way our incoming T1's are handled, > they all are > piled into one big group as available lines with no hunting > set up at all. > While hunting would be beneficial in some troubleshooting > situations we had > it get messed up so many times they moved to this mode. Any > time we add > lines the switch tech just adds the transport layer to the > group and whamo, > there are additional lines at our site that work without the > intervention of > some other "programming tech" at the telco. > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) HyperARC/DSP Problem
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-13 16:57:51

erf...also, set NFAS Span D-Channel Type to dChannelNone and Logical Group Type to nfas on your second card. Also make sure your first card is set to dChannelPrimary and nfas. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Mark Thornton [mailto:mark@corridor.net] > Sent: Thursday, January 13, 2000 4:36 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HyperARC/DSP Problem > > > Is this an NFAS problem? Our PRI lines all appear as a single > trunk at the > telco, controlled by the NFAS functionality across as many > PRI lines that > are included in the NFAS group. At least that is how the switch guys > described it to me. All I do at my end is make sure the > second, third, etc. > card are set up as being a member of the NFAS group, and > determine whether I > am going to add additional d channels for redundancy. If the > PRI lines are > not part of an NFAS group, then there must be some sort of hunting or > rollover involved. > > It is very similar to the way our incoming T1's are handled, > they all are > piled into one big group as available lines with no hunting > set up at all. > While hunting would be beneficial in some troubleshooting > situations we had > it get messed up so many times they moved to this mode. Any > time we add > lines the switch tech just adds the transport layer to the > group and whamo, > there are additional lines at our site that work without the > intervention of > some other "programming tech" at the telco. > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Moving Profiles
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-13 17:24:16

Thus spake K Mitchell >At 01:42 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: >>How do you go about setting up profiles for ISDN on a HiPer machine? I >>cannot seem to find that information anywhere. >The only difference between IDSN and dial-up is allowing concurrent >connections. Not true...in the HiPer Arc, the only real difference between ISDN and analog modems is really just an informational setting on the port indicating whether its an analog or digital connection. You can just as easily to multi-link and/or simultaneous-use connections with analog as you can with ISDN connections. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Moving Profiles
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-13 17:53:40

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX |Internet) |Sent: Thursday, January 13, 2000 3:38 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Moving Profiles | | |Richard, | |You would think so but our Technical Guru in that market doesn't trust our |new Radius server. Therefore we need to find out how to store those |profiles on that HiPer TCH. | What do you mean by profile? If you want the harc to treat ISDN users differently than ANALOG, you are out of luck. The HARC does not differentiate between them.. This kind of granularity must be done on the RADIUS server. The netserver did not care either. The only way to make some kind of difference was to use the Munich Card to terminate ISDN, but this is not the preferred method due to performance differences between the Munich card and the Quad-I modems.. Munich was used at a time when ISDN could not be terminated on the QUADS.. -M

Subject: Re: (usr-tc) Lt WinModems and TCR
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-13 17:59:11

Go to http://808hi.com/56k/ltwin.htm and get the latest drivers. (Or rather, have the user do that.) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Thu, 13 Jan 2000, The NOC (COX Internet) wrote: > > What kind of problems is everybody experiencing with Lt WinModems connecting > at v.90 to the TCH's? What have you guys done to fix this problem? We are > using both the old TCH's and the HiPer TCH's. >

Subject: (usr-tc) Connect via the Arc to the Dsp
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-13 18:53:29

I've heard this can doen rather using console cables to each DSP. Can someone point me to right docs to figure this out. I can't find it anywhere. Meanwhile back to the PDF files. Thanks

Subject: (usr-tc) Limiting Sessions
From: Ed <ed@taylors.com>
Date: 2000-01-13 22:09:21

Has any come up with a sure fire way to limit sessions based on Radius without using Accounting? With 3com Accounting turned on our database becomes 100MB+ in a day so that seems out of the question. It used be done in netservers by using Traps... also you used to be able to use Traps to log to a Logserver and now you can't... it all seems to have to be run through a large Database file. We would rather not do this as Access just cannot handle 100MB files without croaking. Basically I wanted to know what others are using for solutions to these old problems... I know of various ways things can be done but none seem pratical for large volume systems with 20,000+ people logging onto in a day. Thanks! Ed ----- Original Message ----- Sent: Thursday, January 13, 2000 9:53 PM I've heard this can doen rather using console cables to each DSP. Can someone point me to right docs to figure this out. I can't find it anywhere. Meanwhile back to the PDF files. Thanks - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Connect via the Arc to the Dsp
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-13 23:22:28

Yup, if you have new enough code on all the cards, you can do something resembling the following on your ARC: arc> add network service dsp8cons server_type telnetd socket 8000 data "service_type=dialout,auth=off,interface=\"SLOT:8/CON:1\"" ...then telnet to port 8000 on your ARC and you'll be dumped directly to the console of the DSP in slot 8. You'll want to make sure you've got a console password set on your DSP's, of course. :) There is a way to set up a password on the ARC side, but I never got it to work right. I didn't try very hard though. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Thu, 13 Jan 2000, Terry Kennedy wrote: > I've heard this can doen rather using console cables to each > DSP. Can someone point me to right docs to figure this out. I > can't find it anywhere. Meanwhile back to the PDF files. > Thanks > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) v.42bis problems
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-13 23:34:08

OK... interesting... question though: What else runs on that CPU? (I'm assuming this is one of the PowerPC's, not one of the DSP's?) In other words, what else is going to be broken/flaky besides v.42bis? Something else important is bound to be running on there and causing other hard-to-find problems... What kind of hardware failure would show up in exactly the same way for multiple customers? You'd think it would be a little more random... I hope this card is still under hardware warranty so I can get it RMA'ed... if I get someone the serial number is there a way to check? (We don't have hardware support, so it'd have to be warranty repair.) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Thu, 13 Jan 2000, David Bachta wrote: > > > Hi Mike, > > This is a hardware failure on that specific card. There are 2 separate > processors for the data path (v42bis processing occurs in this portion of the > card). Each one of these processors controls half of the modems on the card. > You likely have some sort of failure in the first processor... which is why you > only see the problem on the first 12 ports. > > Hope this helps. > > Regards, > David > > > > > > > Mike Andrews <mandrews@bit0.com> on 01/12/2000 01:20:11 AM > > Please respond to usr-tc@lists.xmission.com > > Sent by: Mike Andrews <mandrews@bit0.com> > > > To: usr-tc@lists.xmission.com > cc: (David Bachta/MW/US/3Com) > Subject: Re: (usr-tc) v.42bis problems > > > > Hm. So far it seems to be isolated to version 0.49 cards. 3Com? Any > insight here? > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > "Don't sweat the petty things, and don't pet the sweaty things." > > On Sun, 9 Jan 2000, Horace Demmink wrote: > > > On Sun, 9 Jan 2000, Mike Andrews wrote: > > > > > Interesting. > > > > > > Any idea what hardware revision the card was? 0.49 maybe? I'm just > > > trying to see if there's any pattern to these at all... > > > > > > > > > > No idea, I didn't keep record on what revision the card was. It very well > > could be 0.49 (why are the hardware revisions 0.xx, are these beta release > > cards? :-) as the others I installed at the same time are. > > > > -- > > Horace Demmink > > PathWay Computing > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) State of the Hub (part 1)(take 2)
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-13 23:46:05

On Mon, 10 Jan 2000, Jeff Mcadams wrote: > 3Com's release numbering (at least on the total control stuff) is still > nuts. I'm not sure what would be a good solution...but some releases > counting up, and some releases counting down is just completely > confusing to customers. Even long-time customers can have difficulty [munch] > needed. I applaud Mike Wronski's and Krish's and Chuck Stace's, and the > rest of the crew's patience in explaining this time and time again to > new folks, and clarifying the status of releases when they're asked I think an FAQ for this list is overdue, actually. This question would easily make the list. Any volunteers? :) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things."

Subject: (usr-tc) VSA's
From: vanhalen@coredcs.com
Date: 2000-01-14 00:37:09

Anyone have or know of where one can find a current listing of all 3Com VSA's?

Subject: RE: (usr-tc) Connect via the Arc to the Dsp
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-14 00:47:03

go to 3kb and search for "reverse telnet"...that should get you the article that explains it in detail. > -----Original Message----- > From: Terry Kennedy [SMTP:terry@olypen.com] > Sent: Thursday, January 13, 2000 10:53 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Connect via the Arc to the Dsp > > I've heard this can doen rather using console cables to each > DSP. Can someone point me to right docs to figure this out. I > can't find it anywhere. Meanwhile back to the PDF files. > Thanks > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Connect via the Arc to the Dsp
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-14 00:47:54

At 12:47 AM 1/14/00 -0400, Stainforth, Matthew wrote: > >go to 3kb and search for "reverse telnet"...that should get you the article >that explains it in detail. While, kinda, on the subject of the knowledgebase's intuitivity, or lack thereof... Does anyone know what a failed logon with Event ID of 91 and Failure to Connect #73 is? A search for either in the KB resulted in plenty of relevant, but no specific, information. I seem to remember there being a listing of failure codes and their explanations somewhere, and even thought I had a copy, but I either lost the bookmark or the copy. Thanks, -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000 http://www.keyconn.net

Subject: Re: (usr-tc) Moving Profiles
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-14 08:28:14

M, What I mean is to set up a user profile on the TCH so that it doesn't go to our Radius server to authenicate. Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Thursday, January 13, 2000 5:53 PM > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX > |Internet) > |Sent: Thursday, January 13, 2000 3:38 PM > |To: usr-tc@lists.xmission.com > |Subject: Re: (usr-tc) Moving Profiles > | > | > |Richard, > | > |You would think so but our Technical Guru in that market doesn't trust our > |new Radius server. Therefore we need to find out how to store those > |profiles on that HiPer TCH. > | > > What do you mean by profile? If you want the harc to treat ISDN users > differently than ANALOG, you are out of luck. The HARC does not > differentiate between them.. This kind of granularity must be done on the > RADIUS server. The netserver did not care either. The only way to make some > kind of difference was to use the Munich Card to terminate ISDN, but this is > not the preferred method due to performance differences between the Munich > card and the Quad-I modems.. Munich was used at a time when ISDN could not > be terminated on the QUADS.. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Moving Profiles
From: Mike Wronski <mwronski@coredump.ae.usr.com>
Date: 2000-01-14 08:35:50

On Fri, 14 Jan 2000, The NOC (COX Internet) wrote: You can create the entire user record (unique id and password) on then HARC, but this is not recomended. THe local users option is intended for small quantities and testing.. Managing many users could be quite a task. If you do create the user "localy", you can specify all of the specific options to you ISDN customer.. -M > M, > > What I mean is to set up a user profile on the TCH so that it doesn't go to > our Radius server to authenicate. > > > > > > > > |-----Original Message----- > > |From: owner-usr-tc@lists.xmission.com > > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX > > |Internet) > > |Sent: Thursday, January 13, 2000 3:38 PM > > |To: usr-tc@lists.xmission.com > > |Subject: Re: (usr-tc) Moving Profiles > > | > > | > > |Richard, > > | > > |You would think so but our Technical Guru in that market doesn't trust > our > > |new Radius server. Therefore we need to find out how to store those > > |profiles on that HiPer TCH. > > | > > > > What do you mean by profile? If you want the harc to treat ISDN users > > differently than ANALOG, you are out of luck. The HARC does not > > differentiate between them.. This kind of granularity must be done on the > > RADIUS server. The netserver did not care either. The only way to make > some > > kind of difference was to use the Munich Card to terminate ISDN, but this > is > > not the preferred method due to performance differences between the Munich > > card and the Quad-I modems.. Munich was used at a time when ISDN could not > > be terminated on the QUADS.. > > > > -M > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > +--------------------------------------+ Mike Wronski (mike@coredump.ae.usr.com) 3Com Network Systems Engineer

Subject: Re: (usr-tc) Moving Profiles
From: Mike Wronski <mwronski@coredump.ae.usr.com>
Date: 2000-01-14 08:35:50

Subject: Re: (usr-tc) Moving Profiles
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-14 09:07:26

M, Ok, that is nice and all. But my original question was how to set that up? Where do I need to go to find that information. I cannot seem to find it anywhere. Thanks, Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Friday, January 14, 2000 8:35 AM > On Fri, 14 Jan 2000, The NOC (COX Internet) wrote: > > You can create the entire user record (unique id and password) on then > HARC, but this is not recomended. THe local users option is intended for > small quantities and testing.. Managing many users could be quite a task. > > If you do create the user "localy", you can specify all of the specific > options to you ISDN customer.. > > -M > > > M, > > > > What I mean is to set up a user profile on the TCH so that it doesn't go to > > our Radius server to authenicate. > > > > > > > > > > > > > |-----Original Message----- > > > |From: owner-usr-tc@lists.xmission.com > > > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX > > > |Internet) > > > |Sent: Thursday, January 13, 2000 3:38 PM > > > |To: usr-tc@lists.xmission.com > > > |Subject: Re: (usr-tc) Moving Profiles > > > | > > > | > > > |Richard, > > > | > > > |You would think so but our Technical Guru in that market doesn't trust > > our > > > |new Radius server. Therefore we need to find out how to store those > > > |profiles on that HiPer TCH. > > > | > > > > > > What do you mean by profile? If you want the harc to treat ISDN users > > > differently than ANALOG, you are out of luck. The HARC does not > > > differentiate between them.. This kind of granularity must be done on the > > > RADIUS server. The netserver did not care either. The only way to make > > some > > > kind of difference was to use the Munich Card to terminate ISDN, but this > > is > > > not the preferred method due to performance differences between the Munich > > > card and the Quad-I modems.. Munich was used at a time when ISDN could not > > > be terminated on the QUADS.. > > > > > > -M > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > +--------------------------------------+ > Mike Wronski (mike@coredump.ae.usr.com) > 3Com Network Systems Engineer > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Limiting Sessions
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-14 09:35:09

This might not be the best way to accomplish it, but (assuming you are using 3Com's S/A server) if you simply comment out the INSERT into the CALLS table, for session-start, session-stop, and interim-updates, you will be able to track session count (it's recorded in the user's record in the USERS table), without recording detailed accounting data. This isn't really a recommended or supported solution, but I don't see why it wouldn't work. Steve "Ed" <ed@taylors.com> on 01/13/2000 09:09:21 PM Please respond to usr-tc@lists.xmission.com Sent by: "Ed" <ed@taylors.com> cc: (Steve Valiunas/MW/US/3Com) Has any come up with a sure fire way to limit sessions based on Radius without using Accounting? With 3com Accounting turned on our database becomes 100MB+ in a day so that seems out of the question. It used be done in netservers by using Traps... also you used to be able to use Traps to log to a Logserver and now you can't... it all seems to have to be run through a large Database file. We would rather not do this as Access just cannot handle 100MB files without croaking. Basically I wanted to know what others are using for solutions to these old problems... I know of various ways things can be done but none seem pratical for large volume systems with 20,000+ people logging onto in a day. Thanks! Ed ----- Original Message ----- Sent: Thursday, January 13, 2000 9:53 PM I've heard this can doen rather using console cables to each DSP. Can someone point me to right docs to figure this out. I can't find it anywhere. Meanwhile back to the PDF files. Thanks - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Soft busy on HDM
From: Buzz Gould <buzzg@rconnect.com>
Date: 2000-01-14 10:43:30

After you hit the execute button, do you wait until every channel on the card shows "Success" in the result column? If you hit the close button before you get a success back for each channel, the command will fail and you will get calls on some of the channels. At 11:21 AM 1/14/00 +0900, you wrote: >Hi all, > >I'm having problems with soft busying HiperDSP cards. It seems that >even when I perform the soft busy on every channel, calls are still >able to come in on that card. Is there something that I am missing >on this concept? Could it be in any way related to the switch type? >I'm using INS1500. > >HDM -> 1.2.5 >HARC -> 4.1.59 > >Thanks > >das > > >-- >______________________________________________ >Alex Substanley Exodus Communications K.K. > Engineering Department >Das Man TEL: 81-3-5334-1700 >Systems Engineer FAX: 81-3-5334-1711 >______________________________________________ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Buzz Gould Information Systems Engineer Rural Connections - a OneMain.com Company www.rconnect.com 507 847-2700 Ext. 6119 buzzg@rconnect.com

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: mmm3@cornell.edu
Date: 2000-01-14 11:02:24

>How would I tell if I had a hung modem? well wait now if I had a hung >modem though wouldnt it be caught when I pluged the initial PRI into the >next card.. When I do that it will take all calls to capacity and still not >hunt over to the next set of PRI's > >-Scott > Tell Bell Atlantic to up the number of available channels. We had the same problem on one of our pools. Turns out, BA told their switch there were 46 channels available whereas, in reality, there were 69. They kept telling us the hunt was programmed properly; it took a bit of whooping and hollering to get 'em to check a little more carefully. 8-\ ********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************

Subject: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-14 11:21:27

Hi all, I'm having problems with soft busying HiperDSP cards. It seems that even when I perform the soft busy on every channel, calls are still able to come in on that card. Is there something that I am missing on this concept? Could it be in any way related to the switch type? I'm using INS1500. HDM -> 1.2.5 HARC -> 4.1.59 Thanks das -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: (usr-tc) DSP 2.0.51 Not Connecting with Sportster 28.8
From: John Verreault <verreaul@aei.ca>
Date: 2000-01-14 11:52:19

Since flashing my DSP's 2 days ago to 2.0.51 we are starting to get calls from users that have Older Sportster 28.8 modems who are unable to connect. Has anyone else seen this ???? Thanks John Verreault AEI Internet

Subject: RE: (usr-tc) Moving Profiles
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-14 13:09:00

You cant find information on adding a user to the HiperARC? Where have you looked? Chapter 5 (Network Dialin Access) in both the 4.1 and 4.2 manuals have a setion entitled "User configuration Overview". Those setions explain the "ADD USER ..." commands and give examples for PPP dialup.. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX |Internet) |Sent: Friday, January 14, 2000 9:07 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Moving Profiles | | |M, | |Ok, that is nice and all. But my original question was how to set that up? |Where do I need to go to find that information. I cannot seem to find it |anywhere. | |Thanks, |Bryan |NOC Technician |COX Internet | |----- Original Message ----- |From: "Mike Wronski" <mwronski@coredump.ae.usr.com> |To: <usr-tc@lists.xmission.com> |Sent: Friday, January 14, 2000 8:35 AM |Subject: Re: (usr-tc) Moving Profiles | | |> On Fri, 14 Jan 2000, The NOC (COX Internet) wrote: |> |> You can create the entire user record (unique id and password) on then |> HARC, but this is not recomended. THe local users option is intended for |> small quantities and testing.. Managing many users could be quite a task. |> |> If you do create the user "localy", you can specify all of the specific |> options to you ISDN customer.. |> |> -M |> |> > M, |> > |> > What I mean is to set up a user profile on the TCH so that it |doesn't go |to |> > our Radius server to authenicate. |> > |> > |> > > |> > > |> > > |-----Original Message----- |> > > |From: owner-usr-tc@lists.xmission.com |> > > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX |> > > |Internet) |> > > |Sent: Thursday, January 13, 2000 3:38 PM |> > > |To: usr-tc@lists.xmission.com |> > > |Subject: Re: (usr-tc) Moving Profiles |> > > | |> > > | |> > > |Richard, |> > > | |> > > |You would think so but our Technical Guru in that market doesn't |trust |> > our |> > > |new Radius server. Therefore we need to find out how to store those |> > > |profiles on that HiPer TCH. |> > > | |> > > |> > > What do you mean by profile? If you want the harc to treat ISDN users |> > > differently than ANALOG, you are out of luck. The HARC does not |> > > differentiate between them.. This kind of granularity must be done on |the |> > > RADIUS server. The netserver did not care either. The only way to |make |> > some |> > > kind of difference was to use the Munich Card to terminate ISDN, but |this |> > is |> > > not the preferred method due to performance differences between the |Munich |> > > card and the Quad-I modems.. Munich was used at a time when |ISDN could |not |> > > be terminated on the QUADS.. |> > > |> > > -M |> > > |> > > |> > > - |> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> > > with "unsubscribe usr-tc" in the body of the message. |> > > For information on digests or retrieving files and old messages send |> > > "help" to the same address. Do not use quotes in your message. |> > > |> > |> > |> > - |> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> > with "unsubscribe usr-tc" in the body of the message. |> > For information on digests or retrieving files and old messages send |> > "help" to the same address. Do not use quotes in your message. |> > |> |> +--------------------------------------+ |> Mike Wronski (mike@coredump.ae.usr.com) |> 3Com Network Systems Engineer |> |> |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |

Subject: Re: (usr-tc) Moving Profiles
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-14 13:29:08

I haven't done much of this, but I believe this will set someone up to dial in with specified user/pass and then give them an address out of the pool: HiPer-1>> add usER testuser netWORK_SERVICE ppp pasSWORD tester tyPE netWORK To set params later: HiPer-1>> set user testuser ? This field is a KEYWORD. The possible values are: ALTERNATE_PHONE_NUMBER INPUT_FILTER PHONE_NUMBER CHAT_SCRIPT_NAME MESSAGE PORT_LIMIT DNIS_REAUTHENTICATION MODEM_GROUP SESSION_TIMEOUT EXPIRATION OUTPUT_FILTER TYPE IDLE_TIMEOUT PASSWORD I believe you MUST use radius if you want to assign an IP and route a block to them. You'll find much more info in the HArc user's guide at http://totalservice.usr.com (no login required to download the manual). Good Luck, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Fri, 14 Jan 2000, The NOC (COX Internet) wrote: > M, > > Ok, that is nice and all. But my original question was how to set that up? > Where do I need to go to find that information. I cannot seem to find it > anywhere. > > Thanks, > Bryan > NOC Technician > COX Internet > > ----- Original Message ----- > From: "Mike Wronski" <mwronski@coredump.ae.usr.com> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 14, 2000 8:35 AM > Subject: Re: (usr-tc) Moving Profiles > > > > On Fri, 14 Jan 2000, The NOC (COX Internet) wrote: > > > > You can create the entire user record (unique id and password) on then > > HARC, but this is not recomended. THe local users option is intended for > > small quantities and testing.. Managing many users could be quite a task. > > > > If you do create the user "localy", you can specify all of the specific > > options to you ISDN customer.. > > > > -M > > > > > M, > > > > > > What I mean is to set up a user profile on the TCH so that it doesn't go > to > > > our Radius server to authenicate. > > > > > > > > > > > > > > > > > > |-----Original Message----- > > > > |From: owner-usr-tc@lists.xmission.com > > > > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX > > > > |Internet) > > > > |Sent: Thursday, January 13, 2000 3:38 PM > > > > |To: usr-tc@lists.xmission.com > > > > |Subject: Re: (usr-tc) Moving Profiles > > > > | > > > > | > > > > |Richard, > > > > | > > > > |You would think so but our Technical Guru in that market doesn't > trust > > > our > > > > |new Radius server. Therefore we need to find out how to store those > > > > |profiles on that HiPer TCH. > > > > | > > > > > > > > What do you mean by profile? If you want the harc to treat ISDN users > > > > differently than ANALOG, you are out of luck. The HARC does not > > > > differentiate between them.. This kind of granularity must be done on > the > > > > RADIUS server. The netserver did not care either. The only way to > make > > > some > > > > kind of difference was to use the Munich Card to terminate ISDN, but > this > > > is > > > > not the preferred method due to performance differences between the > Munich > > > > card and the Quad-I modems.. Munich was used at a time when ISDN could > not > > > > be terminated on the QUADS.. > > > > > > > > -M > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > +--------------------------------------+ > > Mike Wronski (mike@coredump.ae.usr.com) > > 3Com Network Systems Engineer > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Lt WinModems and TCR -Reply
From: Campbell Simpson <campbell.simpson@telecom.co.nz>
Date: 2000-01-14 15:12:44

We don't seem to be having any problems with LT-Win and the HiPer TCHs. = The only problems I experienced is a few random disconnections which was = fixed by telling the WinModem to connect at a slightly slower speed. Campbell

Subject: (usr-tc) Busy out a DSP modem from the DSP console?
From: zip-usrtc@ran.zipcon.net
Date: 2000-01-14 15:15:06

Is there a way to busy out a modem from the DSP console? I have TCM, but do not see how to busy out an individual modem on the DSP. The command line is more accessible anyway. Thanks for any tips. Dan

Subject: Re: (usr-tc) VSA's
From: D A Substanley <das@gol.com>
Date: 2000-01-14 15:51:23

This may work for you: http://totalservice.3com.com/ISP/rad/vendor.html das vanhalen@coredcs.com (vanhalen@coredcs.com) spake: > Anyone have or know of where one can find a current listing of all 3Com > VSA's? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: (usr-tc) Taking care of Vince
From: Brice Ligget <ligget@twoalpha.net>
Date: 2000-01-14 16:23:50

hmmm. 530 Main Street Madawaska, ME 04756 How lives close to this guy?

Subject: RE: (usr-tc) DSP Problems/Losing modems
From: Marius Strom <marius@alpha1.net>
Date: 2000-01-14 16:32:01

Vince, Please refrain from such purely childish abuses of the usr-tc mailing lists. -- Marius Strom <marius@alpha1.net> Professional Geek/Unix System Administrator Alpha1 Internet <http://www.alpha1.net> http://www.marius.org/marius.pgp 0x5645C228 In theory, there is no difference between theory and practice... ...In practice, there is a big difference. On Fri, 14 Jan 2000, Vincent Frallicciardi wrote: > Hi, > > I am looking for a used Total Control Chasse with power supply no other > cards if you know some one who has one let me know. > > Vince > > warlock@nci1.net > At 03:27 PM 1/12/00 -0500, you wrote: > >Is there a problem running 2.0.51 on older revs??? > > > >Thanks > >John > > > >> -----Original Message----- > >> From: owner-usr-tc@lists.xmission.com > >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Nicolas St-Pierre > >> Sent: Wednesday, January 12, 2000 3:04 PM > >> To: usr-tc@lists.xmission.com > >> Subject: Re: (usr-tc) DSP Problems/Losing modems > >> > >> > >> > >> > >> The HiPer DSP code 2.0.60 will usually put timeslots Local Out of > >> Service when a modem pair fails to reset. While this is still better > >> than 2.0.81 where you may get fast busies or no answer, it's still not a > >> complete solution. This scenario is true when the DSP mdmfail is set to > >> Combo mode and the call routing method mdmrmeth is set to fixed > >> assignment. > >> > >> You should only run 2.0.51 if you have a rev 0.55 with Alliance SRAM > >> chips on it instead of ISSI chips. Other 0.55 boards and older revs > >> should run fine on 2.0.60 eventhough we have to put up with this > >> annoying bug until 3Com fixes it. > >> > >> > >> Nick > >> > >> > >> > >> -- > >> Nicolas St-Pierre > >> Systems Engineer > >> Internet Access Solutions Ltd. > >> Tel (905) 469-4953 > >> Fax (905) 469-4954 > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > Vincent > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Can someone remove Vincent?
From: vanhalen@coredcs.com
Date: 2000-01-14 16:34:25

Soon!

Subject: (usr-tc) RADIUS attributes for VOPRadius
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-14 16:38:24

I am using the VOP Radius product with our TC units. I am trying to get VOP to recognize the "Connect-speed" attribute being returned by the HARC. I have the following in my VPRDict.txt file: VENDOR_CODE USR 429 vtype=integer as well as VSA USR Connect-Speed 36899 string However, in my accounting packets, I am getting this: Connect-Speed = "" What am I doing wrong? -- Scot Desort NJ Internet Access

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:09:09

Hi, I had the same problem so I upgraded to the latest code and it fixed the problem. Vince At 03:17 PM 1/12/00 -0500, you wrote: >At 12:45 PM 1/12/00 -0700, Christopher Berry wrote: >> We have had perennial problems with Hiper modems suddenly not >>responding. Every other day I get a random modem or two that stops >>responding per card. Rarely a software reset will return the modem to >>service. Usually, I wait a week until I have several, then do a hardware >>reset. This returns most to service, except the occasional bad channel. > >You can soft-busy the modems through TCM to bypass them. Normally what I'll >do is soft-busy the rest of the card when my nightime useage decreases. >This won't knock anybody off but will prevent new connections, By morning, >everyone's off the card and I can reset it without affecting anybody. > >>I am running 2.0.60 per 3com. I am not using 2.0.51 as I am under the >>impression it is for a newer hardware version than we own. I have not >>yet upgraded the Hiperarc software to the latest-I am waiting for the next >>time I do aforementioned hardware resets. (Day traders get very upset if >>they get booted : ). Suggestions and questions? > >I had been seeing modem lockups at least weekly with 3 DSPs(0.49.0). I >upgraded to ARC 4.2.32/DSP 2.0.81 about 3 months ago. Since then, I had my >first modem lockup last night. Needless to say, this has been a great >inprovement. > > >-- >Kirk Mitchell-General Manager mitch@keyconn.net >Keystone Connect Unlock Your World >Altoona, PA 814-941-5000 http://www.keyconn.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) RADIUS attributes for VOPRadius
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:15:32

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 04:38 PM 1/14/00 -0500, you wrote: >I am using the VOP Radius product with our TC units. > >I am trying to get VOP to recognize the "Connect-speed" attribute being >returned by the HARC. I have the following in my VPRDict.txt file: > >VENDOR_CODE USR 429 vtype=integer > > >as well as > > >VSA USR Connect-Speed 36899 string > > >However, in my accounting packets, I am getting this: > > >Connect-Speed = "" > > >What am I doing wrong? > > >-- >Scot Desort >NJ Internet Access > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:15:42

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 03:17 PM 1/12/00 -0500, you wrote: >At 12:45 PM 1/12/00 -0700, Christopher Berry wrote: >> We have had perennial problems with Hiper modems suddenly not >>responding. Every other day I get a random modem or two that stops >>responding per card. Rarely a software reset will return the modem to >>service. Usually, I wait a week until I have several, then do a hardware >>reset. This returns most to service, except the occasional bad channel. > >You can soft-busy the modems through TCM to bypass them. Normally what I'll >do is soft-busy the rest of the card when my nightime useage decreases. >This won't knock anybody off but will prevent new connections, By morning, >everyone's off the card and I can reset it without affecting anybody. > >>I am running 2.0.60 per 3com. I am not using 2.0.51 as I am under the >>impression it is for a newer hardware version than we own. I have not >>yet upgraded the Hiperarc software to the latest-I am waiting for the next >>time I do aforementioned hardware resets. (Day traders get very upset if >>they get booted : ). Suggestions and questions? > >I had been seeing modem lockups at least weekly with 3 DSPs(0.49.0). I >upgraded to ARC 4.2.32/DSP 2.0.81 about 3 months ago. Since then, I had my >first modem lockup last night. Needless to say, this has been a great >inprovement. > > >-- >Kirk Mitchell-General Manager mitch@keyconn.net >Keystone Connect Unlock Your World >Altoona, PA 814-941-5000 http://www.keyconn.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: RE: (usr-tc) HyperARC/DSP Problem
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:15:51

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 04:57 PM 1/13/00 -0400, you wrote: > >erf...also, set NFAS Span D-Channel Type to dChannelNone and Logical Group >Type to nfas on your second card. Also make sure your first card is set to >dChannelPrimary and nfas. > >Matthew Stainforth || Technical Services Manager || BrunNet Inc. > > >> -----Original Message----- >> From: Mark Thornton [mailto:mark@corridor.net] >> Sent: Thursday, January 13, 2000 4:36 PM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) HyperARC/DSP Problem >> >> >> Is this an NFAS problem? Our PRI lines all appear as a single >> trunk at the >> telco, controlled by the NFAS functionality across as many >> PRI lines that >> are included in the NFAS group. At least that is how the switch guys >> described it to me. All I do at my end is make sure the >> second, third, etc. >> card are set up as being a member of the NFAS group, and >> determine whether I >> am going to add additional d channels for redundancy. If the >> PRI lines are >> not part of an NFAS group, then there must be some sort of hunting or >> rollover involved. >> >> It is very similar to the way our incoming T1's are handled, >> they all are >> piled into one big group as available lines with no hunting >> set up at all. >> While hunting would be beneficial in some troubleshooting >> situations we had >> it get messed up so many times they moved to this mode. Any >> time we add >> lines the switch tech just adds the transport layer to the >> group and whamo, >> there are additional lines at our site that work without the >> intervention of >> some other "programming tech" at the telco. >> >> Mark Thornton >> San Marcos Internet, Inc. >> 512-393-5300 >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) Connect via the Arc to the Dsp
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:16:00

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 06:53 PM 1/13/00 -0800, you wrote: >I've heard this can doen rather using console cables to each >DSP. Can someone point me to right docs to figure this out. I >can't find it anywhere. Meanwhile back to the PDF files. >Thanks > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) VSA's
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:16:11

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 12:37 AM 1/14/00 -0600, you wrote: >Anyone have or know of where one can find a current listing of all 3Com >VSA's? > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) HiperARC 4.1.22 and 5.10.9 Quads
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:16:20

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 12:01 AM 1/13/00 -0500, you wrote: >6.1.6 seems safe here; we've been running it for months. We're a PRI shop >though. > >Is 5.5.5 the newest NMC code you can run? The newer the better... > > >Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ >VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY >Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville >"Don't sweat the petty things, and don't pet the sweaty things." > >On Wed, 12 Jan 2000, Andrew Smith wrote: > >> >> Will HiperArc version 4.1.22 work with: >> >> NMC 5.5.5 >> Quad Modem version 5.10.9 >> Dual Channelized T1 (386) 4.2.1 >> >> I'm scared to upgrade to 6.1.6 on the Single-Sided Quads. 5.10.9 is very >> stable for us. Anyone running 6.1.6 fine??? > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: RE: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:16:28

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 01:51 PM 1/12/00 -0700, you wrote: >Aha! I think I've got it running now. Thanks for the info. I really >didn't want to create something from scratch. I can tweak this now if need >be. > >-Greg > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Steve McConnell >Sent: Wednesday, January 12, 2000 10:42 AM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG > > >you should be able to use Eric Billeters scripts that come with MRTG in the >contrib directory under TCH ( I am still using MRTG2.7.2- so these may have >changed) > >works like a dream. > >steve > >--On Wednesday, January 12, 2000 10:37 AM -0700 Greg Long ><greg@coastlink.com> wrote: > >> I want to setup MRTG to monitor modem usage on my TC hub, I have the MIB's >> that come with the USR Suite Management Software. Can I use these MIB's >> or do I need to get other MIB's? >> >> Thanks, >> Greg Long >> Tech Support >> Coastlink >> 801-532-6212 ext 32 >> techsupp@coastlink.com >> http://www.coastlink.com >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > > >Steve McConnell >EMJI >919-303-3217x126 >888-258-8959 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) Moving Profiles
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:16:37

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 03:37 PM 1/13/00 -0600, you wrote: >Richard, > >You would think so but our Technical Guru in that market doesn't trust our >new Radius server. Therefore we need to find out how to store those >profiles on that HiPer TCH. > >Bryan >NOC Technician >COX Internet > > >----- Original Message ----- >From: "Richard Lorbieski" <richard@alpha1.net> >To: <usr-tc@lists.xmission.com> >Sent: Thursday, January 13, 2000 3:03 PM >Subject: Re: (usr-tc) Moving Profiles > > >> It's much easier/management to setup as a radius profile than store them >> in the hiperARC. >> >> "The NOC (COX Internet)" wrote: >> > >> > Kirk, >> > >> > We have our connection profiles stored on our TCH. We have an older TCH >> > that is dying on us and we need to move the connection profiles over to >the >> > new HiPer TCH. >> > >> > Bryan >> > >> > ----- Original Message ----- >> > From: "K Mitchell" <mitch@keyconn.net> >> > To: <usr-tc@lists.xmission.com> >> > Sent: Thursday, January 13, 2000 1:52 PM >> > Subject: Re: (usr-tc) Moving Profiles >> > >> > > At 01:42 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: >> > > > >> > > >How do you go about setting up profiles for ISDN on a HiPer machine? >I >> > > >cannot seem to find that information anywhere. >> > > >> > > The only difference between IDSN and dial-up is allowing concurrent >> > > connections. >> > > >> > > >> > > -- >> > > Kirk Mitchell-General Manager mitch@keyconn.net >> > > Keystone Connect Unlock Your World >> > > Altoona, PA 814-941-5000 http://www.keyconn.net >> > > >> >> -- >> >> Richard Lorbieski - richard@alpha1.net >> Chief Technical Officer - Senior System Administrator >> Alpha1 Internet http://www.alpha1.net >> 409.731.8236 - 877.4.alpha1 (877.425.7421) >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:16:51

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 10:28 PM 1/12/00 -0500, you wrote: >Thus spake Scot bethke >>Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell >>atlantic says everything is fine with both of them. But they refuse to >>hunt from the first hyperDSP to the second. I plug in the first PRI >>into either DSP card and it takes calls and works like a charm till it >>gets to channel 23, where we get a fast busy from then on. Im hoping >>there is a special "Oh you havemore than one hyperDSP" button that I >>need to push. anyone know what might cause this? > >Get Hell Atlantic back on the line and smack them upside the head with a >clue by four. :) If the both cards are taking calls, then there's a >problem with the hunting and that's all telco there. There is no way to >configure your equipment to control the hunt group in any way. The >originating side (the telco in this case) decides where to send the >call, the receiving side has no say in the matter other than to >possibly reject the call (resulting in either a fast busy/reorder tone >type of response to the caller, or a user busy if its rejected with >cause code 17). > >I suspect that they've set it up as two seperate trunk groups and not >got the hunting between them configured correctly. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:17:01

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 11:52 PM 1/12/00 -0500, you wrote: >Are you sure that you don't have a hung modem that is stopping the hunt >group (not answering the phone)? > >Paul Farber >Farber Technology >farber@admin.f-tech.net >Ph 570-628-5303 >Fax 570-628-5545 > >On Wed, 12 Jan 2000, Scot bethke wrote: > >> I am having the absolute worst time trying to get my HyperDSP cards working in any capacity what-so-ever. Hoping someone from here has seen this or can tell me what to check. >> >> First i'm running HyperARC HW Version 19.0.0, with Version 4.1.59 Software. HyperDSP's are HW V 0.49.0, and I have thus far tried both 1.2.5 and 2.0.51 software. Im using PRI's and they both show up as UP and OPERATIONAL. >> >> (2) Problems... First of all I cant manage the cards (any of them) with TCM. Running 6.0.23, had the same problem on 5.X TCM as well. What happenes is I select the card, click on configure, click on card level and then click ok. I can get the >> Hyper DSP/ARC Information item, and all values come in and display fine. However I click on "Routing Method" and it comes up with this: >> >> Error Type: No Data Available >> Parameter: Modem Routing Method >> Object ID: 1.3.6.1.4.1.429.1.26.1.1.1.2.14000 >> >> Same type of message comes up on every query except info. I can communicate with the NMC card just fine (its an older NMC, not a HyperNMC). So I had to go in and USE HARM to program the HyperARC (that works fine btw), and I programmed the DSP's with a terminal. >> >> Second Issue (and this is the big one) I have two PRI's, 23B+D, Bell atlantic says everything is fine with both of them. But they refuse to hunt from the first hyperDSP to the second. I plug in the first PRI into either DSP card and it takes calls and works like a charm till it gets to channel 23, where we get a fast busy from then on. Im hoping there is a special "Oh you havemore than one hyperDSP" button that I need to push. anyone know what might cause this? >> >> -Scott >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:17:12

Subject: Re: (usr-tc) Lt WinModems and TCR
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:18:33

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 01:00 PM 1/13/00 -0600, you wrote: > >What kind of problems is everybody experiencing with Lt WinModems connecting >at v.90 to the TCH's? What have you guys done to fix this problem? We are >using both the old TCH's and the HiPer TCH's. > >Bryan >NOC Technician >COX Internet > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: RE: (usr-tc) DSP Problems/Losing modems
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:18:52

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 03:27 PM 1/12/00 -0500, you wrote: >Is there a problem running 2.0.51 on older revs??? > >Thanks >John > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Nicolas St-Pierre >> Sent: Wednesday, January 12, 2000 3:04 PM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) DSP Problems/Losing modems >> >> >> >> >> The HiPer DSP code 2.0.60 will usually put timeslots Local Out of >> Service when a modem pair fails to reset. While this is still better >> than 2.0.81 where you may get fast busies or no answer, it's still not a >> complete solution. This scenario is true when the DSP mdmfail is set to >> Combo mode and the call routing method mdmrmeth is set to fixed >> assignment. >> >> You should only run 2.0.51 if you have a rev 0.55 with Alliance SRAM >> chips on it instead of ISSI chips. Other 0.55 boards and older revs >> should run fine on 2.0.60 eventhough we have to put up with this >> annoying bug until 3Com fixes it. >> >> >> Nick >> >> >> >> -- >> Nicolas St-Pierre >> Systems Engineer >> Internet Access Solutions Ltd. >> Tel (905) 469-4953 >> Fax (905) 469-4954 >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:19:08

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 12:45 PM 1/12/00 -0700, you wrote: > We have had perennial problems with Hiper modems suddenly not >responding. Every other day I get a random modem or two that stops >responding per card. Rarely a software reset will return the modem to >service. Usually, I wait a week until I have several, then do a hardware >reset. This returns most to service, except the occasional bad channel. >I am running 2.0.60 per 3com. I am not using 2.0.51 as I am under the >impression it is for a newer hardware version than we own. I have not >yet upgraded the Hiperarc software to the latest-I am waiting for the next >time I do aforementioned hardware resets. (Day traders get very upset if >they get booted : ). Suggestions and questions? Thanks Christopher Berry >rof.net Web Design and Technical Support >(970) 945-4920 x17 > Vincent

Subject: RE: (usr-tc) Moving Profiles
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:19:18

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 05:53 PM 1/13/00 -0600, you wrote: > > >|-----Original Message----- >|From: owner-usr-tc@lists.xmission.com >|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX >|Internet) >|Sent: Thursday, January 13, 2000 3:38 PM >|To: usr-tc@lists.xmission.com >|Subject: Re: (usr-tc) Moving Profiles >| >| >|Richard, >| >|You would think so but our Technical Guru in that market doesn't trust our >|new Radius server. Therefore we need to find out how to store those >|profiles on that HiPer TCH. >| > >What do you mean by profile? If you want the harc to treat ISDN users >differently than ANALOG, you are out of luck. The HARC does not >differentiate between them.. This kind of granularity must be done on the >RADIUS server. The netserver did not care either. The only way to make some >kind of difference was to use the Munich Card to terminate ISDN, but this is >not the preferred method due to performance differences between the Munich >card and the Quad-I modems.. Munich was used at a time when ISDN could not >be terminated on the QUADS.. > >-M > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) v.42bis problems
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:19:30

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 03:36 PM 1/13/00 -0600, you wrote: > > >Hi Mike, > >This is a hardware failure on that specific card. There are 2 separate >processors for the data path (v42bis processing occurs in this portion of the >card). Each one of these processors controls half of the modems on the card. >You likely have some sort of failure in the first processor... which is why you >only see the problem on the first 12 ports. > >Hope this helps. > >Regards, >David > > > > > > >Mike Andrews <mandrews@bit0.com> on 01/12/2000 01:20:11 AM > >Please respond to usr-tc@lists.xmission.com > >Sent by: Mike Andrews <mandrews@bit0.com> > > >To: usr-tc@lists.xmission.com >cc: (David Bachta/MW/US/3Com) >Subject: Re: (usr-tc) v.42bis problems > > > >Hm. So far it seems to be isolated to version 0.49 cards. 3Com? Any >insight here? > > >Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ >VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY >Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville >"Don't sweat the petty things, and don't pet the sweaty things." > >On Sun, 9 Jan 2000, Horace Demmink wrote: > >> On Sun, 9 Jan 2000, Mike Andrews wrote: >> >> > Interesting. >> > >> > Any idea what hardware revision the card was? 0.49 maybe? I'm just >> > trying to see if there's any pattern to these at all... >> > >> > >> >> No idea, I didn't keep record on what revision the card was. It very well >> could be 0.49 (why are the hardware revisions 0.xx, are these beta release >> cards? :-) as the others I installed at the same time are. >> >> -- >> Horace Demmink >> PathWay Computing >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) HyperARC/DSP Problem
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:19:46

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 03:26 PM 1/13/00 -0500, you wrote: >> Maybe this was asked or answered already, but are the switch and framing >> types set properly under trunk settings? > >Yes they are, we prove this by putting the working PRI on both DSP cards and >it takes calls fine. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) Lt WinModems and TCR -Reply
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:20:00

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 03:12 PM 1/14/00 +1300, you wrote: >We don't seem to be having any problems with LT-Win and the HiPer TCHs. The only problems I experienced is a few random disconnections which was fixed by telling the WinModem to connect at a slightly slower speed. > >Campbell > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) Moving Profiles
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:20:09

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 05:24 PM 1/13/00 -0500, you wrote: >Thus spake K Mitchell >>At 01:42 PM 1/13/00 -0600, The NOC $COX Internet$ wrote: >>>How do you go about setting up profiles for ISDN on a HiPer machine? I >>>cannot seem to find that information anywhere. > >>The only difference between IDSN and dial-up is allowing concurrent >>connections. > >Not true...in the HiPer Arc, the only real difference between ISDN and >analog modems is really just an informational setting on the port >indicating whether its an analog or digital connection. You can just as >easily to multi-link and/or simultaneous-use connections with analog as >you can with ISDN connections. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) DSP Problems/Losing modems
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:20:35

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 07:07 PM 1/12/00 -0700, you wrote: >The docs actually mention rev 54 & 55 for it. I have put it on all of mine >which are 53's and 54's with no ill effects so far. Its been about a week. > > > >At 03:03 PM 1/12/00 -0500, you wrote: > > >> The HiPer DSP code 2.0.60 will usually put timeslots Local Out of >>Service when a modem pair fails to reset. While this is still better >>than 2.0.81 where you may get fast busies or no answer, it's still not a >>complete solution. This scenario is true when the DSP mdmfail is set to >>Combo mode and the call routing method mdmrmeth is set to fixed >>assignment. >> >>You should only run 2.0.51 if you have a rev 0.55 with Alliance SRAM >>chips on it instead of ISSI chips. Other 0.55 boards and older revs >>should run fine on 2.0.60 eventhough we have to put up with this >>annoying bug until 3Com fixes it. >> >> >>Nick >> >> >> >>-- >>Nicolas St-Pierre >>Systems Engineer >>Internet Access Solutions Ltd. >>Tel (905) 469-4953 >>Fax (905) 469-4954 >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >Thanks, Greg Coffey <gcoffey@vcn.com> >Visionary Communications V 307-234-5443 F 307-234-5446 >100 N. Center #100, Casper, WY 82601 www.vcn.com > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: RE: (usr-tc) Netserver PRI Max connections
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:20:49

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 11:02 AM 1/13/00 -0500, you wrote: >It's a dumb question, but you do have a big enough IP pool, right? :) > >Charles > >On Thu, 13 Jan 2000, Phil Le Clercq wrote: > >> Cheers for the reply, but that part is ok as you can see below. All modems >> are taking calls, for round robin is set up on the chassis. Calls go through >> the whole chassis no problems, but only in a maximum chunk of 30. The >> trouble is this chassis is the last in the line of the telco's first >> available PRI's. I guess I'll just have to stay up late tonight and and >> double check the telco bit is correct.... >> Heh if I was in the States and was only getting 26 calls then at least I >> would know it was the telco setup for (fairly) sure! :-) >> >> Cheers, Phil >> >> >> Starting Slot: 1 >> >> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 >> --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- >> S1 S5 S9 S13 S17 S21 S25 S29 S33 S37 S41 S45 S49 S53 S57 - >> S2 S6 S10 S14 S18 S22 S26 S30 S34 S38 S42 S46 S50 S54 S58 - >> S3 S7 S11 S15 S19 S23 S27 S31 S35 S39 S43 S47 S51 S55 S59 - >> S4 S8 S12 S16 S20 S24 S28 S32 S36 S40 S44 S48 S52 S56 S60 - >> >> -----Original Message----- >> From: Charles Sprickman [mailto:spork@inch.com] >> Sent: Thursday, January 13, 2000 3:30 PM >> To: TCH List (E-mail) >> Subject: Re: (usr-tc) Netserver PRI Max connections >> >> It sounds like the rest of the modems aren't set "active" on >> the >> netserver. You can see the current status like so: >> >> FX-1-NSVR> show modem >> Starting Slot: 2 >> >> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >> 16 >> --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- >> --- >> - S1 S5 S9 S13 S17 - - - S33 S37 - - - - >> - >> - S2 S6 S10 S14 S18 - - - S34 S38 - - - - >> - >> - S3 S7 S11 S15 S19 - - - S35 S39 - - - - >> - >> - S4 S8 S12 S16 S20 - - - S36 S40 - - - - >> - >> >> You have to make sure each modem shows up in this table. >> The top row is >> the slot number. I'm a bit rusty on the netserver, but I >> think this will >> set a modem active: >> >> FX-1-NSVR> set modem s21 active >> S21 - active (s7 , c1 ) >> >> FX-1-NSVR> show modem >> Starting Slot: 2 >> \/ >> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 >> 16 >> --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- >> --- >> - S1 S5 S9 S13 S17 S21 - - S33 S37 - - - - >> - >> - S2 S6 S10 S14 S18 - - - S34 S38 - - - - >> - >> - S3 S7 S11 S15 S19 - - - S35 S39 - - - - >> - >> - S4 S8 S12 S16 S20 - - - S36 S40 - - - - >> - >> >> Hope that helps, >> >> Charles >> >> On Thu, 13 Jan 2000, Phil Le Clercq wrote: >> >> > Hi all, I have a chassis with dual pri, 56 digital modems >> ( 14 quads) and >> > one Netserver (3.8.1). >> > My problem is the chassis never takes more than 30 calls. >> Both PRI's >> > (European) are working ok, I got the telco to busy out the >> other feeds so >> > all calls went to this chassis. >> > You can see the modem's taking the call but above 30 >> connections the user >> > gets "disconnected from the remote machine" as an error. >> > I believe the problem lies with the Netserver. I guess I'm >> just missing a >> > command to set max connections to 56 but I cant remember >> or find it! >> > I presumed that Netservers were set to 60 connections by >> default, this is >> > something I've not had to do before as all our others >> chassis' have 30 ports >> > only. >> > Thanks in advance for any help :-) >> > Cheers, Phil >> > >> > - >> > To unsubscribe to usr-tc, send an email to >> "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old >> messages send >> > "help" to the same address. Do not use quotes in your >> message. >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to >> "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old >> messages send >> "help" to the same address. Do not use quotes in your >> message. >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: Re: (usr-tc) Moving Profiles
From: Vincent Frallicciardi <warlock@nci1.net>
Date: 2000-01-14 17:21:10

Hi, I am looking for a used Total Control Chasse with power supply no other cards if you know some one who has one let me know. Vince warlock@nci1.net At 09:07 AM 1/14/00 -0600, you wrote: >M, > >Ok, that is nice and all. But my original question was how to set that up? >Where do I need to go to find that information. I cannot seem to find it >anywhere. > >Thanks, >Bryan >NOC Technician >COX Internet > >----- Original Message ----- >From: "Mike Wronski" <mwronski@coredump.ae.usr.com> >To: <usr-tc@lists.xmission.com> >Sent: Friday, January 14, 2000 8:35 AM >Subject: Re: (usr-tc) Moving Profiles > > >> On Fri, 14 Jan 2000, The NOC (COX Internet) wrote: >> >> You can create the entire user record (unique id and password) on then >> HARC, but this is not recomended. THe local users option is intended for >> small quantities and testing.. Managing many users could be quite a task. >> >> If you do create the user "localy", you can specify all of the specific >> options to you ISDN customer.. >> >> -M >> >> > M, >> > >> > What I mean is to set up a user profile on the TCH so that it doesn't go >to >> > our Radius server to authenicate. >> > >> > >> > > >> > > >> > > |-----Original Message----- >> > > |From: owner-usr-tc@lists.xmission.com >> > > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of The NOC (COX >> > > |Internet) >> > > |Sent: Thursday, January 13, 2000 3:38 PM >> > > |To: usr-tc@lists.xmission.com >> > > |Subject: Re: (usr-tc) Moving Profiles >> > > | >> > > | >> > > |Richard, >> > > | >> > > |You would think so but our Technical Guru in that market doesn't >trust >> > our >> > > |new Radius server. Therefore we need to find out how to store those >> > > |profiles on that HiPer TCH. >> > > | >> > > >> > > What do you mean by profile? If you want the harc to treat ISDN users >> > > differently than ANALOG, you are out of luck. The HARC does not >> > > differentiate between them.. This kind of granularity must be done on >the >> > > RADIUS server. The netserver did not care either. The only way to >make >> > some >> > > kind of difference was to use the Munich Card to terminate ISDN, but >this >> > is >> > > not the preferred method due to performance differences between the >Munich >> > > card and the Quad-I modems.. Munich was used at a time when ISDN could >not >> > > be terminated on the QUADS.. >> > > >> > > -M >> > > >> > > >> > > - >> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > > with "unsubscribe usr-tc" in the body of the message. >> > > For information on digests or retrieving files and old messages send >> > > "help" to the same address. Do not use quotes in your message. >> > > >> > >> > >> > - >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> +--------------------------------------+ >> Mike Wronski (mike@coredump.ae.usr.com) >> 3Com Network Systems Engineer >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Vincent

Subject: (usr-tc) Flashing Dual T1/E1
From: Steve Rivera <sales@wrca.net>
Date: 2000-01-14 17:24:19

Is there a specific nic to be used with the dual t1/e1 card for it to support the e1 standard. In addition to the T1/E1 nac not accepting the E1 code.....Why? It accepts the T1 flash. ___________________________________________ ALSO IN THE MARKET FOR DSP's. Does anyone have Hiper DSP's available? WTB: HiperDSP...paying top dollar $$$$$ Available now, just out of service: All equipment Refurbished, flashed and tested Guaranteed working 1- Hiper NMC 4- Hiper ARC 1- Fan Tray 2- TC Chassis w/ Dual 45A Power 6- NMC 4- Netserver PRI 6- Dual T1/E1 1- Dual PRI 4- Quad Analog 30 -Quad Digital Modem Bundles: Dual 45A/Fan Tray/NMC v90/Netserver PRI/12x Quad Digital/Dual T1/PRI Single 70A/Integrated Fan Tray/NMC v90/Netserver PRI/12x Quad Digital/Dual T1/PRI Dual 70A/....... 5- MP8 v34 6- MP8I 8- MP16 v34 3- MP16I 5- Netserver 8I Plus 4- Netserver 16I Plus 5- Netserver 16I 5- Netserver 16 v34 Plus 25- Netserver 16 v34 .................................................... Steve Rivera - http://www.ISP-NetworkHardware.com (WRCA) sales@wrca.net v-732-833-2111 cell/pgr-732-433-5890 ---WAN ACCESS SPECIALIST--- Cisco, Ascend, Livingston, USR, Microcom, Computone, Kentrox, Adtran...and more .................................................... Steve Rivera - http://www.ISP-NetworkHardware.com (WRCA) sales@wrca.net v-732-833-2111 cell/pgr-732-433-5890 ---WAN ACCESS SPECIALIST--- Cisco, Ascend, Livingston, USR, Microcom, Computone, Kentrox, Adtran...and more

Subject: RE: (usr-tc) Busy out a DSP modem from the DSP console?
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-14 20:13:56

chdev tslot [# of timeslot] cmd tooserv (hard|soft) > -----Original Message----- > From: zip-usrtc@ran.zipcon.net [SMTP:zip-usrtc@ran.zipcon.net] > Sent: Friday, January 14, 2000 7:15 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Busy out a DSP modem from the DSP console? > > Is there a way to busy out a modem from the DSP console? I have TCM, > but do not see how to busy out an individual modem on the DSP. The > command line is more accessible anyway. Thanks for any tips. Dan > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Flashing Dual T1/E1
From: Marty Elliott <marty@2assetrecovery.com>
Date: 2000-01-15 06:13:51

Steve -- if you're trying to flash the old style T1/E1 card (with the 186 cpu) it won't hold. In many E1 areas, the T1/E1 card isn't even spec'd as the proper card for E1. We've had much better success just using the Dual PRI cards. The nic you need is a dual E1 nic -- p/n 000395-0x. But beware here too -- in many parts of the world 3Com sells a "different" E1 nic (same part number, same everything except the code on one IC [thanx to Bob Purdon in Tasmania for finding this even tho 3Com refuses to admit it or fix it or do anything else for us on this issue]). Chances are the dual E1 nic you acquire will only support one span in most areas of the E1 world. HTH Marty At 05:24 PM 1/14/00 -0500, you wrote: >Is there a specific nic to be used with the dual t1/e1 card for it to >support the e1 standard. >In addition to the T1/E1 nac not accepting the E1 code.....Why? It accepts >the T1 flash. > > >___________________________________________ >ALSO IN THE MARKET FOR DSP's. >Does anyone have Hiper DSP's available? >WTB: HiperDSP...paying top dollar $$$$$ > >Available now, just out of service: >All equipment Refurbished, flashed and tested >Guaranteed working > >1- Hiper NMC >4- Hiper ARC >1- Fan Tray >2- TC Chassis w/ Dual 45A Power >6- NMC >4- Netserver PRI >6- Dual T1/E1 >1- Dual PRI >4- Quad Analog >30 -Quad Digital Modem > >Bundles: >Dual 45A/Fan Tray/NMC v90/Netserver PRI/12x Quad Digital/Dual T1/PRI >Single 70A/Integrated Fan Tray/NMC v90/Netserver PRI/12x Quad Digital/Dual >T1/PRI >Dual 70A/....... > >5- MP8 v34 >6- MP8I >8- MP16 v34 >3- MP16I >5- Netserver 8I Plus >4- Netserver 16I Plus >5- Netserver 16I >5- Netserver 16 v34 Plus >25- Netserver 16 v34 >.................................................... >Steve Rivera - http://www.ISP-NetworkHardware.com (WRCA) >sales@wrca.net v-732-833-2111 cell/pgr-732-433-5890 >---WAN ACCESS SPECIALIST--- >Cisco, Ascend, Livingston, USR, Microcom, >Computone, Kentrox, Adtran...and more > >.................................................... >Steve Rivera - http://www.ISP-NetworkHardware.com (WRCA) >sales@wrca.net v-732-833-2111 cell/pgr-732-433-5890 > >---WAN ACCESS SPECIALIST--- > >Cisco, Ascend, Livingston, USR, Microcom, >Computone, Kentrox, Adtran...and more > > > > > > > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) 2.0.60
From: Jason A. Nunnelley <interests@linkfast.net>
Date: 2000-01-15 09:23:15

I have tried the "totalsupport" 3COM site and the download date has expired on this software. I have the little contract, but I can not get a copy of this code (DSP). ANYone have an idea? Jason A. Nunnelley President of Linkfast Internet Services, Linkfast Inc. 256-739-2008 VOICE CONTACT Linkfast Labs, GPN, MFG, MentionMe Studios, and, the Stupid Project http://www.linkfast.net http://www.lynkfast.com http://www.getpaidnet.com http://www.myfriendgeek.com http://www.mentionme.com http://www.helpimstupid.com

Subject: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51
From: pferraro@wna-linknet.com
Date: 2000-01-15 12:23:13

OK... I asked this in this forum earlier and it started a long thread of discussion about the different code congif, but I never got an answer. Are there any "GOTCHAS" when moving from 4.1.59-6 to 4.1.22? And is it safe to load the 2.0.51 code over the 2.0.81 code? I have seen all the comments about rev #'s, but still no comment on whether the above combination of code is "STABLE" Saw a couple of posts that "SETTINGS" were lost on the HiperArc after loading the 4.1.22 code? Would like to hear, private email if you like or to the list about the above software! Thanks again! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: Re: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-15 13:45:56

I did a 4.1.59-6 to 4.1.22 and nothing went wrong. It's mainly for the DOS against the ARC and a SNMP read fix. Some new VSA's and disconnect attributes. Seems that 3Com is really doing a lot of work with DNIS..... anybody use that stuff???? Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sat, 15 Jan 2000 pferraro@wna-linknet.com wrote: > > OK... I asked this in this forum earlier and it started a long > thread of discussion about the different code congif, but I never got an > answer. Are there any "GOTCHAS" when moving from 4.1.59-6 to 4.1.22? > And is it safe to load the 2.0.51 code over the 2.0.81 code? > > I have seen all the comments about rev #'s, but still no comment on > whether the above combination of code is "STABLE" Saw a couple of posts > that "SETTINGS" were lost on the HiperArc after loading the 4.1.22 code? > > Would like to hear, private email if you like or to the list about the > above software! > > Thanks again! > > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51
From: Ronald Kushner <ron@glis.net>
Date: 2000-01-15 14:07:56

Paul Farber wrote: > > I did a 4.1.59-6 to 4.1.22 and nothing went wrong. It's mainly for the > DOS against the ARC and a SNMP read fix. > > Some new VSA's and disconnect attributes. Seems that 3Com is really doing > a lot of work with DNIS..... anybody use that stuff???? Oh yeah, that's one more thing I ran into when I converted to 4.1.22, the VSA for framed_local_IP_Address in my dictionary file for SA 6.0.8 was set to a string type and it stopped working properly in the HiPer ARC, I had to change it as a ipaddr type. But it was the RIP problems what made me back off to 4.1.59-6. -Ron GLISnet, Inc. +1 810/939.9885

Subject: RE: (usr-tc) Connect via the Arc to the Dsp
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-15 18:01:52

arc> add network service dsp8cons server_type telnetd socket 8000 data "service_type=dialout,auth=off,interface=\"SLOT:8/CON:1\"" ...then telnet to port 8000 on your ARC and you'll be dumped directly to the console of the DSP in slot 8. Mike, Tried this and I am dropped back at the hiperarc's cli.3kb.com and found nothing on this. Is their a syntax problem here? A list of the network services show the I have also looked on 3kb.com and found nothing on this. All I found was some expalnation for doing telneting to a hiperarv from a netserver with a set of console cables hooked tied together with a null modem connector. Have no idea why anyone would want to do that. I'll keep looking. Thanks

Subject: RE: (usr-tc) Connect via the Arc to the Dsp
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-15 18:19:01

Wow, that was a screwed up response! let me try again.. arc> add network service dsp8cons server_type telnetd socket 8000 data "service_type=dialout,auth=off,interface=\"SLOT:8/CON:1\"" ...then telnet to port 8000 on your ARC and you'll be dumped directly to the console of the DSP in slot 8. Mike, Tried this and it telnets just fine back to the hiperarc. Is their a syntax problem here? A list of the network services show: CONFIGURED NETWORK SERVICES Server Admin Name Type Socket Close Status dsp12 TELNETD 8000 FALSE ENABLED DATA: service_type=dialout,auth=off,interface="slot:12/con:1" I also have looked at 3kb.com and all I found was some explanation for telneting to a hiperarc from a netserver with a set of console cables tied together with a null modem connector. Have no idea why anyone would want to do that. I'll keep looking. Thanks Terry - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-16 00:16:09

Hi, Thanks for the response. Yes, I do wait. I have tried the command several times but to no avail. It's frustrating to have a command that I know would be extremely useful, but no able to implement. das Buzz Gould (buzzg@rconnect.com) spake: > After you hit the execute button, do you wait until every channel on the > card shows "Success" in the result column? If you hit the close button > before you get a success back for each channel, the command will fail and > you will get calls on some of the channels. > > At 11:21 AM 1/14/00 +0900, you wrote: > >Hi all, > > > >I'm having problems with soft busying HiperDSP cards. It seems that > >even when I perform the soft busy on every channel, calls are still > >able to come in on that card. Is there something that I am missing > >on this concept? Could it be in any way related to the switch type? > >I'm using INS1500. > > > >HDM -> 1.2.5 > >HARC -> 4.1.59 > > > >Thanks > > > >das > > > > > >-- > >______________________________________________ > >Alex Substanley Exodus Communications K.K. > > Engineering Department > >Das Man TEL: 81-3-5334-1700 > >Systems Engineer FAX: 81-3-5334-1711 > >______________________________________________ > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > Buzz Gould > Information Systems Engineer > Rural Connections - a OneMain.com Company > www.rconnect.com > 507 847-2700 Ext. 6119 > buzzg@rconnect.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51
From: Clayton Zekelman <clayton@mnsi.net>
Date: 2000-01-16 10:44:51

At 01:45 PM 1/15/00 -0500, you wrote: >I did a 4.1.59-6 to 4.1.22 and nothing went wrong. It's mainly for the >DOS against the ARC and a SNMP read fix. > >Some new VSA's and disconnect attributes. Seems that 3Com is really doing >a lot of work with DNIS..... anybody use that stuff???? We use DNIS for on the fly modem reconfiguraitons. Works quite well actually. We defined a separate number for each of our pops that disables v.90/x2,v.42/bis, etc... Forces a plain v.34 connect - usefull for people who need to get a stable connection to download new drivers for their crappy winmodems. The original idea came from Lon Stockton quite some time ago. Thats about all we use DNIS for. We're going to probably start using it for numbered relams for a wholesale service we're going to be providing. We've got half a dozen POPs around Southwestern Ontario, and 35 rate centers in Southeastern Michigan, and giving the customer their own number would be nice. > >Paul Farber >Farber Technology >farber@admin.f-tech.net >Ph 570-628-5303 >Fax 570-628-5545 > >On Sat, 15 Jan 2000 pferraro@wna-linknet.com wrote: > >> >> OK... I asked this in this forum earlier and it started a long >> thread of discussion about the different code congif, but I never got an >> answer. Are there any "GOTCHAS" when moving from 4.1.59-6 to 4.1.22? >> And is it safe to load the 2.0.51 code over the 2.0.81 code? >> >> I have seen all the comments about rev #'s, but still no comment on >> whether the above combination of code is "STABLE" Saw a couple of posts >> that "SETTINGS" were lost on the HiperArc after loading the 4.1.22 code? >> >> Would like to hear, private email if you like or to the list about the >> above software! >> >> Thanks again! >> >> >> ============================================================================== >> Phillip Ferraro WorldNet Access, Inc >> pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service >> Voice (910) 346-0835 824 Gumbranch Square, Suite R3 >> FAX (910) 455-1933 Jacksonville, Nc 28540-6269 >> ============================================================================== >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) Problem with Hiper ARC and ISDN 128
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-16 13:06:37

MPIP. You must configure the HiPer arcs to do MPIP, check your documentation on MPIP or visit 3KB at http://totalservice.usr.com krish On Sun, 16 Jan 2000, Jorge Lozano wrote: > Hello everybody! > I have a problem with my ISDN 128 access... > I have a TCS with 2 HiperARC and 12 HiperDSP... the first ARC manage 8 = > DSP and the second manage 4... the first 10 DSP have a PRI number and = > the 11 and 12 DSP have a different number. > When any user try to connect by ISDN (128K), and he use both = > B-channels... sometimes happens that one channel is assigned in the = > first 8 DSP and the second is assigned in 9th or 10th DSP card, then the = > user have 2 differents IP address because each ARC assign an IP number. > > Can anybody tell me what is the solution for this problem??? > > Thanks for all.. > > Jorge Lozano jorge@andinet.com > Andinet On Line >

Subject: RE: (usr-tc) Connect via the Arc to the Dsp
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-16 13:32:32

This is live off of one of my ARCs: law-ts1> list network service CONFIGURED NETWORK SERVICES Server Admin Name Type Socket Close Status tftpd TFTPD 69 FALSE ENABLED DATA: telnetd TELNETD 23 FALSE ENABLED DATA: dsp8cons TELNETD 8000 FALSE ENABLED DATA: service_type=dialout,auth=off,interface="SLOT:8/CON:1" dsp9cons TELNETD 9000 FALSE ENABLED DATA: service_type=dialout,auth=off,interface="SLOT:9/CON:1" dsp10cons TELNETD 10000 FALSE ENABLED DATA: service_type=dialout,auth=off,interface="SLOT:10/CON:1" dsp11cons TELNETD 11000 FALSE ENABLED DATA: service_type=dialout,auth=off,interface="SLOT:11/CON:1" dsp12cons TELNETD 12000 FALSE ENABLED DATA: service_type=dialout,auth=off,interface="SLOT:12/CON:1" This is with DSP version 2.0.51 and ARC version 4.2.32. You must have at least DSP 2.0.x to make it work. With the above, I can telnet to port 11000 to get to the console of the DSP in slot 11... Does "list interface" show the console ports? If not, you probably don't have the newest release of code. If you do, try 'list chassis' and make sure console is set to yes on all your DSP's there. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Sat, 15 Jan 2000, Terry Kennedy wrote: > Tried this and it telnets just fine back to the hiperarc. Is their a syntax > problem here? A list of the network services show: > > CONFIGURED NETWORK SERVICES > Server Admin > Name Type Socket Close Status > dsp12 TELNETD 8000 FALSE ENABLED > DATA: service_type=dialout,auth=off,interface="slot:12/con:1" > > I also have looked at 3kb.com and all I found was some explanation for > telneting to a hiperarc from a > netserver with a set of console cables tied together with a null modem > connector. Have no idea why anyone would want to do that. I'll keep looking.

Subject: Re: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-16 13:34:29

On Sun, 16 Jan 2000, Clayton Zekelman wrote: > >Some new VSA's and disconnect attributes. Seems that 3Com is really doing > >a lot of work with DNIS..... anybody use that stuff???? > > We use DNIS for on the fly modem reconfiguraitons. Works quite well > actually. We defined a separate number for each of our pops that disables > v.90/x2,v.42/bis, etc... Forces a plain v.34 connect - usefull for people > who need to get a stable connection to download new drivers for their > crappy winmodems. We do that too, except we also have a third number that goes all the way down to 9600 bps for people stuck with mode 2 SLC's. We based it on Lon Stockton's stuff too. Handy stuff for all those Rockwell HCF problems... I've got our setup documents on my usrtoys web page. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things."

Subject: (usr-tc) Problem with Hiper ARC and ISDN 128
From: Jorge Lozano <jorge@andinet.com>
Date: 2000-01-16 13:55:04

This is a multi-part message in MIME format. ------=_NextPart_000_0011_01BF6029.4A2975E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello everybody! I have a problem with my ISDN 128 access... I have a TCS with 2 HiperARC and 12 HiperDSP... the first ARC manage 8 = DSP and the second manage 4... the first 10 DSP have a PRI number and = the 11 and 12 DSP have a different number. When any user try to connect by ISDN (128K), and he use both = B-channels... sometimes happens that one channel is assigned in the = first 8 DSP and the second is assigned in 9th or 10th DSP card, then the = user have 2 differents IP address because each ARC assign an IP number. Can anybody tell me what is the solution for this problem??? Thanks for all.. Jorge Lozano jorge@andinet.com Andinet On Line ------=_NextPart_000_0011_01BF6029.4A2975E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Hello everybody!</FONT></DIV> <DIV><FONT face=3DArial size=3D2>I have a problem with my ISDN 128=20 access...</FONT></DIV> <DIV><FONT face=3DArial size=3D2>I have a TCS with 2 HiperARC and 12 = HiperDSP... the=20 first ARC manage 8 DSP and the second manage 4... the first 10 DSP have = a PRI=20 number and the 11 and 12 DSP have a different number.</FONT></DIV> <DIV><FONT face=3DArial size=3D2>When any user try to connect by ISDN = (128K), and he=20 use both B-channels... sometimes happens that one channel is assigned in = the=20 first 8 DSP and the second is assigned in 9th or 10th DSP card, = then the=20 user have 2 differents IP address because each ARC assign an IP=20 number.</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Can anybody tell me what is the = solution for this=20 problem???</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Thanks for all..</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>Jorge Lozano <A=20 href=3D"mailto:jorge@andinet.com">jorge@andinet.com</A></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Andinet On = Line</FONT></DIV></BODY></HTML> ------=_NextPart_000_0011_01BF6029.4A2975E0--

Subject: Re: (usr-tc) MIB OID for Frequency attenuation
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-16 20:04:09

Try .1.3.6.1.4.1.429.1.6.9.1.1.75 and .1.3.6.1.4.1.429.1.6.9.1.1.76. 75 will give you the frequencies and 76 will give you the values (in negative tenths of a DB). Steve Valiunas "Campbell Simpson" <Campbell.Simpson@telecom.co.nz> on 01/16/2000 04:04:02 PM Please respond to usr-tc@lists.xmission.com Sent by: "Campbell Simpson" <Campbell.Simpson@telecom.co.nz> cc: (Steve Valiunas/MW/US/3Com) Hi I was wondering if anyone could help me find the OID for the mib that records the frequency attenuation response for the TCH modems (equivalent of ATY11). Been looking for ages and can't seem to find the right OID. Thanks Campbell Simpson - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) MIB OID for Frequency attenuation
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-16 21:32:26

Be warned that some versions of HiPer DSP code won't return an accurate list of frequencies. (All zeroes, if I remember right.) The Quads will. The values are all OK though. If you can't get the frequencies, they start at 150 hz and go up to 3750 hz in steps of 150. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Sun, 16 Jan 2000, Steve Valiunas wrote: > > > Try .1.3.6.1.4.1.429.1.6.9.1.1.75 and .1.3.6.1.4.1.429.1.6.9.1.1.76. 75 will > give you the frequencies and 76 will give you the values (in negative tenths of > a DB). > > Steve Valiunas > > > > > > > "Campbell Simpson" <Campbell.Simpson@telecom.co.nz> on 01/16/2000 04:04:02 PM > > Please respond to usr-tc@lists.xmission.com > > Sent by: "Campbell Simpson" <Campbell.Simpson@telecom.co.nz> > > > To: usr-tc@lists.xmission.com > cc: (Steve Valiunas/MW/US/3Com) > Subject: (usr-tc) MIB OID for Frequency attenuation > > > > Hi > > I was wondering if anyone could help me find the OID for the mib that records > the frequency attenuation response for the TCH modems (equivalent of ATY11). > Been looking for ages and can't seem to find the right OID. > > Thanks > > Campbell Simpson > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-17 09:47:18

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ronald Kushner |Sent: Saturday, January 15, 2000 1:08 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) HiperArc 4.1.22 and DSP 2.0.51 | | |Paul Farber wrote: |> |> I did a 4.1.59-6 to 4.1.22 and nothing went wrong. It's mainly for the |> DOS against the ARC and a SNMP read fix. |> |> Some new VSA's and disconnect attributes. Seems that 3Com is |really doing |> a lot of work with DNIS..... anybody use that stuff???? | |Oh yeah, that's one more thing I ran into when I converted to 4.1.22, the |VSA for framed_local_IP_Address in my dictionary file for SA 6.0.8 was set |to a string type and it stopped working properly in the HiPer ARC, I had to |change it as a ipaddr type. But it was the RIP problems what made me back |off to 4.1.59-6. | RIP Problems?? Did you post the details here?? Can you post a detailed example of your configs and exactly what RIP was doing/not doing ?? thanks, M

Subject: (usr-tc) MIB OID for Frequency attenuation
From: Campbell Simpson <campbell.simpson@telecom.co.nz>
Date: 2000-01-17 11:04:02

Hi I was wondering if anyone could help me find the OID for the mib that = records the frequency attenuation response for the TCH modems (equivalent = of ATY11). Been looking for ages and can't seem to find the right OID. Thanks Campbell Simpson

Subject: (usr-tc) Can't see TC NMC since changing subnets
From: Harry Landers <harryl@cruzers.com>
Date: 2000-01-17 14:45:50

We recently put all our in-house systems on a different subnet from the TC and now we can't see the NMC card on our chassis using the Total Control Manager nor can we ping it. The NMC and the NetServer PRI cards are on consecutive IP addresses on the same subnet and we can ping the PRI card and telnet into it with no problems from the in-house systems. Anybody run into this before? We don't want our in-house systems on the same subnet as our dialin chassis. thanks =============================================================== Harry Landers, President Panda Communications LLC 185 Walnut Avenue Santa Cruz CA 95060 Home of CRUZERS 831-457-CRUZ (2789) fax 831-457-056k

Subject: Re: (usr-tc) Soft busy on HDM
From: Christopher Berry <berryc@rof.net>
Date: 2000-01-17 16:01:15

When I need to busy out a time span on a T1, I do a hard busy as I was told that the CO can override a soft busy. Since I do not want any traffic to come in while flashing, I'm told, I always do this. Hope this helps. Christopher Berry rof.net Web Design and Technical Support (970) 945-4920 x17 ----- Original Message ----- Sent: Saturday, January 15, 2000 8:16 AM > Hi, > > Thanks for the response. Yes, I do wait. I have tried the command > several times but to no avail. It's frustrating to have a command > that I know would be extremely useful, but no able to implement. > > das > > Buzz Gould (buzzg@rconnect.com) spake: > > > After you hit the execute button, do you wait until every channel on the > > card shows "Success" in the result column? If you hit the close button > > before you get a success back for each channel, the command will fail and > > you will get calls on some of the channels. > > > > At 11:21 AM 1/14/00 +0900, you wrote: > > >Hi all, > > > > > >I'm having problems with soft busying HiperDSP cards. It seems that > > >even when I perform the soft busy on every channel, calls are still > > >able to come in on that card. Is there something that I am missing > > >on this concept? Could it be in any way related to the switch type? > > >I'm using INS1500. > > > > > >HDM -> 1.2.5 > > >HARC -> 4.1.59 > > > > > >Thanks > > > > > >das > > > > > > > > >-- > > >______________________________________________ > > >Alex Substanley Exodus Communications K.K. > > > Engineering Department > > >Das Man TEL: 81-3-5334-1700 > > >Systems Engineer FAX: 81-3-5334-1711 > > >______________________________________________ > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > Buzz Gould > > Information Systems Engineer > > Rural Connections - a OneMain.com Company > > www.rconnect.com > > 507 847-2700 Ext. 6119 > > buzzg@rconnect.com > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > ______________________________________________ > Alex Substanley Exodus Communications K.K. > Engineering Department > Das Man TEL: 81-3-5334-1700 > Systems Engineer FAX: 81-3-5334-1711 > ______________________________________________ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Asound modems
From: Network Administrator <netadmin@seidata.com>
Date: 2000-01-17 17:14:48

This is a multi-part message in MIME format. ------=_NextPart_000_01B7_01BF610E.5B5F1E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a customer that cannot connect to the TCH since upgrading to the = 2.0.60 DSP code. Modem type is Asound-Link:PCI Audio+modem 56k v.90 = (Leadman Electronics). Any suggestions? -Cheryl Johnson SEI Data Network Services =20 ------=_NextPart_000_01B7_01BF610E.5B5F1E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>I have a customer that cannot connect = to the TCH=20 since upgrading to the 2.0.60 DSP code. Modem type is=20 Asound-Link:PCI Audio+modem 56k v.90 (Leadman Electronics).=20 Any suggestions?</FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>-Cheryl Johnson</FONT></DIV> <DIV><FONT face=3DArial size=3D2>SEI Data Network = Services</FONT></DIV> <DIV> </DIV></BODY></HTML> ------=_NextPart_000_01B7_01BF610E.5B5F1E60--

Subject: Re: (usr-tc) Soft busy on HDM
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-17 17:35:48

It boots them all off very quickly. At 09:19 AM 1/18/00 +0900, you wrote: >Hi Christopher, > >Thanks for the response. When you do a hard busy on the span, does that >immediately disconnect all of the users currently connected to that card, >or is it friendlier? >Thanks > >das > >Christopher Berry (berryc@rof.net) spake: > > > When I need to busy out a time span on a T1, I do a hard busy as I was told > > that the CO can override a soft busy. Since I do not want any traffic to > > come in while flashing, I'm told, I always do this. > > > > Hope this helps. > > > > Christopher Berry > > rof.net Web Design and Technical Support > > (970) 945-4920 x17 > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) Can't see TC NMC since changing subnets
From: Clayton Zekelman <clayton@mnsi.net>
Date: 2000-01-17 18:04:14

Umm, did you set a default gateway on the NMC? At 02:45 PM 1/17/00 -0800, you wrote: >We recently put all our in-house systems on a different subnet from the TC >and now we can't see the NMC card on our chassis using the Total Control >Manager nor can we ping it. The NMC and the NetServer PRI cards are on >consecutive IP addresses on the same subnet and we can ping the PRI card and >telnet into it with no problems from the in-house systems. Anybody run into >this before? We don't want our in-house systems on the same subnet as our >dialin chassis. > >thanks > >=============================================================== >Harry Landers, President >Panda Communications LLC 185 Walnut Avenue Santa Cruz CA 95060 >Home of CRUZERS 831-457-CRUZ (2789) fax 831-457-056k > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: RE: (usr-tc) v.42bis problems
From: Jason A. Nunnelley <interests@linkfast.net>
Date: 2000-01-17 19:29:01

WOW! I would definitely get a tech contract. I just burned a DSP card and it started dumping - one call, one shipment, and I had a new DSP card. I would have never considered RMA had it not been for the tech. He told me the dumps were most likely due to the card being bad. I was still screaming at my telco (they earned it before this problem with a list of provisioning different switch types in a single hunt group - u know - standard Telco Crap. I saved myself countless thousands in tech support and lost revenues by not letting customers leave me while I wait to guess the problem. I'd definitely invest in the support contract. Jason A. Nunnelley President of Linkfast Internet Services, Linkfast Inc. 256-739-2008 VOICE CONTACT Linkfast Labs, GPN, MFG, MentionMe Studios, and, the Stupid Project http://www.linkfast.net -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Horace Demmink Sent: Saturday, January 08, 2000 11:08 AM On Fri, 7 Jan 2000, Mike Andrews wrote: > An old problem has just come back, but in only one weird case. > > I've got a crapload of people getting randomly bumped offline with v.42 or > v.42bis related problems. (I suspect v.42bis.) > > However... it's only happening on the first 12 channels of ONE DSP card. > I had a similar problem that turned out to be a DSP hardware problem. One of my DSP's would, after moderate use, not answer on the first 12 channels until it was reset. I had flashed several different versions of code, tried different lines (CT1 and PRI), different locations, chassis's, etc. Nothing made a difference. After jerking around with 3COM's RMA dept for a while (you can't RMA it until a tech says it's bad, you can't talk to a tech without a contract) my vendor offered to RMA it for me. I have not seen this symptom pop up on any other cards I have. -- Horace Demmink PathWay Computing - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Soft busy on HDM
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-17 20:15:01

Are you running PRI or Channelized T1? If PRI, this probably has a lot to do with the switch type. On the DMS100 we're on, I've never seen calls come into a card that's had all the channels soft-busied. Just set the card to soft-busy, flash the new code, wait for everyone to log out, then reboot the card. Voila. It's supposed to work the same on a 5ESS. On INS1500 things could be different, I guess... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Mon, 17 Jan 2000, Christopher Berry wrote: > When I need to busy out a time span on a T1, I do a hard busy as I was told > that the CO can override a soft busy. Since I do not want any traffic to > come in while flashing, I'm told, I always do this. > > Hope this helps. > > Christopher Berry > rof.net Web Design and Technical Support > (970) 945-4920 x17 > > ----- Original Message ----- > From: "D A Substanley" <das@gol.com> > To: <usr-tc@lists.xmission.com> > Sent: Saturday, January 15, 2000 8:16 AM > Subject: Re: (usr-tc) Soft busy on HDM > > > > Hi, > > > > Thanks for the response. Yes, I do wait. I have tried the command > > several times but to no avail. It's frustrating to have a command > > that I know would be extremely useful, but no able to implement. > > > > das > > > > Buzz Gould (buzzg@rconnect.com) spake: > > > > > After you hit the execute button, do you wait until every channel on the > > > card shows "Success" in the result column? If you hit the close button > > > before you get a success back for each channel, the command will fail > and > > > you will get calls on some of the channels. > > > > > > At 11:21 AM 1/14/00 +0900, you wrote: > > > >Hi all, > > > > > > > >I'm having problems with soft busying HiperDSP cards. It seems that > > > >even when I perform the soft busy on every channel, calls are still > > > >able to come in on that card. Is there something that I am missing > > > >on this concept? Could it be in any way related to the switch type? > > > >I'm using INS1500. > > > > > > > >HDM -> 1.2.5 > > > >HARC -> 4.1.59 > > > > > > > >Thanks > > > > > > > >das > > > > > > > > > > > >-- > > > >______________________________________________ > > > >Alex Substanley Exodus Communications K.K. > > > > Engineering Department > > > >Das Man TEL: 81-3-5334-1700 > > > >Systems Engineer FAX: 81-3-5334-1711 > > > >______________________________________________ > > > > > > > >- > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > Buzz Gould > > > Information Systems Engineer > > > Rural Connections - a OneMain.com Company > > > www.rconnect.com > > > 507 847-2700 Ext. 6119 > > > buzzg@rconnect.com > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > -- > > ______________________________________________ > > Alex Substanley Exodus Communications K.K. > > Engineering Department > > Das Man TEL: 81-3-5334-1700 > > Systems Engineer FAX: 81-3-5334-1711 > > ______________________________________________ > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Soft busy on HDM
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-17 23:28:51

Get together with your telco rep and make sure your translation supports service messages. I understand that NI-2 does not but most (if not all) others do. It just sounds like the switch is not listening to your RMB requests. > -----Original Message----- > From: D A Substanley [SMTP:das@gol.com] > Sent: Monday, January 17, 2000 9:34 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Soft busy on HDM > > Hi Mike, > > Thanks for the response. I'm using PRI. I have had two cards soft busied > for > about three days with no change. Customers are still logging in happily, > so it > must be something to do with the switch type. Unfortunately, I have no > access > to any kind of support over here as 3Com Japan won't give me the time of > day. > <sigh> > > Thanks for the help! > > das > > Mike Andrews (mandrews@bit0.com) spake: > > > Are you running PRI or Channelized T1? > > > > If PRI, this probably has a lot to do with the switch type. On the > DMS100 > > we're on, I've never seen calls come into a card that's had all the > > channels soft-busied. Just set the card to soft-busy, flash the new > code, > > wait for everyone to log out, then reboot the card. Voila. It's > supposed > > to work the same on a 5ESS. On INS1500 things could be different, I > > guess... > > > > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > > "Don't sweat the petty things, and don't pet the sweaty things." > > > > On Mon, 17 Jan 2000, Christopher Berry wrote: > > > > > When I need to busy out a time span on a T1, I do a hard busy as I was > told > > > that the CO can override a soft busy. Since I do not want any traffic > to > > > come in while flashing, I'm told, I always do this. > > > > > > Hope this helps. > > > > > > Christopher Berry > > > rof.net Web Design and Technical Support > > > (970) 945-4920 x17 > > > > > > ----- Original Message ----- > > > From: "D A Substanley" <das@gol.com> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Saturday, January 15, 2000 8:16 AM > > > Subject: Re: (usr-tc) Soft busy on HDM > > > > > > > > > > Hi, > > > > > > > > Thanks for the response. Yes, I do wait. I have tried the command > > > > several times but to no avail. It's frustrating to have a command > > > > that I know would be extremely useful, but no able to implement. > > > > > > > > das > > > > > > > > Buzz Gould (buzzg@rconnect.com) spake: > > > > > > > > > After you hit the execute button, do you wait until every channel > on the > > > > > card shows "Success" in the result column? If you hit the close > button > > > > > before you get a success back for each channel, the command will > fail > > > and > > > > > you will get calls on some of the channels. > > > > > > > > > > At 11:21 AM 1/14/00 +0900, you wrote: > > > > > >Hi all, > > > > > > > > > > > >I'm having problems with soft busying HiperDSP cards. It seems > that > > > > > >even when I perform the soft busy on every channel, calls are > still > > > > > >able to come in on that card. Is there something that I am > missing > > > > > >on this concept? Could it be in any way related to the switch > type? > > > > > >I'm using INS1500. > > > > > > > > > > > >HDM -> 1.2.5 > > > > > >HARC -> 4.1.59 > > > > > > > > > > > >Thanks > > > > > > > > > > > >das > > > > > > > > > > > > > > > > > >-- > > > > > >______________________________________________ > > > > > >Alex Substanley Exodus Communications K.K. > > > > > > Engineering Department > > > > > >Das Man TEL: 81-3-5334-1700 > > > > > >Systems Engineer FAX: 81-3-5334-1711 > > > > > >______________________________________________ > > > > > > > > > > > >- > > > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and old messages > send > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > Buzz Gould > > > > > Information Systems Engineer > > > > > Rural Connections - a OneMain.com Company > > > > > www.rconnect.com > > > > > 507 847-2700 Ext. 6119 > > > > > buzzg@rconnect.com > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages > send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > -- > > > > ______________________________________________ > > > > Alex Substanley Exodus Communications K.K. > > > > Engineering Department > > > > Das Man TEL: 81-3-5334-1700 > > > > Systems Engineer FAX: 81-3-5334-1711 > > > > ______________________________________________ > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages > send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > ______________________________________________ > Alex Substanley Exodus Communications K.K. > Engineering Department > Das Man TEL: 81-3-5334-1700 > Systems Engineer FAX: 81-3-5334-1711 > ______________________________________________ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) WTB: 3- USR NMC v90 NIC/NAC Sets
From: eric@dol.net
Date: 2000-01-17 23:57:18

Still have any? thanks eric At 04:17 PM 12/6/99 -0500, you wrote: >I got three of those! > >Brian >----- Original Message ----- >From: "Steve Rivera" <sales@wrca.net> >To: <usr-tc@lists.xmission.com> >Sent: Monday, December 06, 1999 3:34 PM >Subject: (usr-tc) WTB: 3- USR NMC v90 NIC/NAC Sets > > >> Looking to purchase 3 of the USR Total Control NMC cards w/ nic. >> They have to be v90 enabled. >> >> Please email if you have them. >> .................................................... >> Steve Rivera - ISP-NetworkHardware.com (WRCA) >> sales@wrca.net v-732-833-2111 pgr-732-325-1092 >> >> ---WAN ACCESS SPECIALIST--- >> http://www.ISP-NetworkHarware.com >> Cisco, Ascend, Livingston, USR, Microcom, >> Computone, Kentrox, Adtran...and more >> >> >> >> >> >> >> >> >> >> >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Soft busy on HDM
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-18 01:16:24

On Tue, 18 Jan 2000, D A Substanley wrote: > When you do a hard busy on the span, does that > immediately disconnect all of the users currently connected to that card, > or is it friendlier? Immediate disconnect. That's the difference between a soft busy and a hard busy. Hard Busy: Issues a local-out-of-service message to the switch, dropping the call in progress and preventing any more from coming in. Soft Busy: Queues a local-out-of-service message, to be executed when the current call finishes. I don't know if it's the HDSP that queues it or if it's sent to the switch and it queues it. If the soft busy isn't working, does a hard busy work? If not, the telco switch isn't listening to you. When you do a soft busy, check it (with TCM) by going selecting the Span and clicking Performance. Then check Timeslot and select the one(s) you did a soft busy on. Then hit Default (for the Parameters in the Function Group 'DS0 Statistics'). If there's a call in progress, the 'DS0 Service State' should be 'inService', and the 'Queued Action for DS0' should be 'localOutOfService'. When the call terminates, the 'DS0 Service State' should go to 'localOutOfService' and the 'Queued Action...' should go to 'none'. If it does that properly, and is still taking calls, we're back to the switch not listening to you. A hard busy probably won't work either. If it doesn't do that properly, whether it's the switch or the HDSP depends on who's supposed to be doing the queueing (switch or DSP). [I dunno. Maybe someone does and will respond to this]. This reminds me of one of my pet peeves. I wish there was a way to mark a MODEM out of service (instead of a span timeslot). I.E, tell the HDSP to never assign a call to a given modem (it'd mean the same thing as a busyout if call selection was fixed, but if you were using round-robin, you could still terminate a full PRI's worth of calls even if you had a stuck modem). I'm just annoyed that modem #24 never gets any calls because I gotta use fixed assignment because it's the only way to skip the occasional stuck modem. </rant>

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-18 09:19:38

Hi Christopher, Thanks for the response. When you do a hard busy on the span, does that immediately disconnect all of the users currently connected to that card, or is it friendlier? Thanks das Christopher Berry (berryc@rof.net) spake: > When I need to busy out a time span on a T1, I do a hard busy as I was told > that the CO can override a soft busy. Since I do not want any traffic to > come in while flashing, I'm told, I always do this. > > Hope this helps. > > Christopher Berry > rof.net Web Design and Technical Support > (970) 945-4920 x17 >

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-18 09:45:24

Yeah, that's what I thought. I was hoping for something that would keep my customers a little happier. Any ideas? Or any other responses to my original problem of not being able to do soft busy outs? Thanks das Greg Coffey (greg@coffey.com) spake: > It boots them all off very quickly. > > > At 09:19 AM 1/18/00 +0900, you wrote: > >Hi Christopher, > > > >Thanks for the response. When you do a hard busy on the span, does that > >immediately disconnect all of the users currently connected to that card, > >or is it friendlier? > >Thanks > > > >das > > > >Christopher Berry (berryc@rof.net) spake: > > > > > When I need to busy out a time span on a T1, I do a hard busy as I was told > > > that the CO can override a soft busy. Since I do not want any traffic to > > > come in while flashing, I'm told, I always do this. > > > > > > Hope this helps. > > > > > > Christopher Berry > > > rof.net Web Design and Technical Support > > > (970) 945-4920 x17 > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > Thanks, Greg Coffey <gcoffey@vcn.com> > Visionary Communications V 307-234-5443 F 307-234-5446 > 100 N. Center #100, Casper, WY 82601 www.vcn.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-18 10:34:18

Hi Mike, Thanks for the response. I'm using PRI. I have had two cards soft busied for about three days with no change. Customers are still logging in happily, so it must be something to do with the switch type. Unfortunately, I have no access to any kind of support over here as 3Com Japan won't give me the time of day. <sigh> Thanks for the help! das Mike Andrews (mandrews@bit0.com) spake: > Are you running PRI or Channelized T1? > > If PRI, this probably has a lot to do with the switch type. On the DMS100 > we're on, I've never seen calls come into a card that's had all the > channels soft-busied. Just set the card to soft-busy, flash the new code, > wait for everyone to log out, then reboot the card. Voila. It's supposed > to work the same on a 5ESS. On INS1500 things could be different, I > guess... > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > "Don't sweat the petty things, and don't pet the sweaty things." > > On Mon, 17 Jan 2000, Christopher Berry wrote: > > > When I need to busy out a time span on a T1, I do a hard busy as I was told > > that the CO can override a soft busy. Since I do not want any traffic to > > come in while flashing, I'm told, I always do this. > > > > Hope this helps. > > > > Christopher Berry > > rof.net Web Design and Technical Support > > (970) 945-4920 x17 > > > > ----- Original Message ----- > > From: "D A Substanley" <das@gol.com> > > To: <usr-tc@lists.xmission.com> > > Sent: Saturday, January 15, 2000 8:16 AM > > Subject: Re: (usr-tc) Soft busy on HDM > > > > > > > Hi, > > > > > > Thanks for the response. Yes, I do wait. I have tried the command > > > several times but to no avail. It's frustrating to have a command > > > that I know would be extremely useful, but no able to implement. > > > > > > das > > > > > > Buzz Gould (buzzg@rconnect.com) spake: > > > > > > > After you hit the execute button, do you wait until every channel on the > > > > card shows "Success" in the result column? If you hit the close button > > > > before you get a success back for each channel, the command will fail > > and > > > > you will get calls on some of the channels. > > > > > > > > At 11:21 AM 1/14/00 +0900, you wrote: > > > > >Hi all, > > > > > > > > > >I'm having problems with soft busying HiperDSP cards. It seems that > > > > >even when I perform the soft busy on every channel, calls are still > > > > >able to come in on that card. Is there something that I am missing > > > > >on this concept? Could it be in any way related to the switch type? > > > > >I'm using INS1500. > > > > > > > > > >HDM -> 1.2.5 > > > > >HARC -> 4.1.59 > > > > > > > > > >Thanks > > > > > > > > > >das > > > > > > > > > > > > > > >-- > > > > >______________________________________________ > > > > >Alex Substanley Exodus Communications K.K. > > > > > Engineering Department > > > > >Das Man TEL: 81-3-5334-1700 > > > > >Systems Engineer FAX: 81-3-5334-1711 > > > > >______________________________________________ > > > > > > > > > >- > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > Buzz Gould > > > > Information Systems Engineer > > > > Rural Connections - a OneMain.com Company > > > > www.rconnect.com > > > > 507 847-2700 Ext. 6119 > > > > buzzg@rconnect.com > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > -- > > > ______________________________________________ > > > Alex Substanley Exodus Communications K.K. > > > Engineering Department > > > Das Man TEL: 81-3-5334-1700 > > > Systems Engineer FAX: 81-3-5334-1711 > > > ______________________________________________ > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) Asound modems
From: Kalev Nurklik <kalev@mail.lbi.ee>
Date: 2000-01-18 12:40:24

Had some problems with v42 negotiation when I was on 2.0.60 Some client modems just couldn't connect. After handshake TC thought there were no v42 agreed upon vs. client modem thinking that there is v42 connection and the client was just dropped by the TC with user-input-error or something similar in radius logs. Had to revert back to 2.0.19 till 2.0.51 came out because turning off v42 negotiation on HDSPs wasn't very appealing to me and telling every problematic customer to turn off theirs wouldn't been an easy task either. 2.0.51 works fine for now. Hope You'll have the same problem. Regards, Date sent: Mon, 17 Jan 2000 17:14:48 -0500 Send reply to: usr-tc@lists.xmission.com > I have a customer that cannot connect to the TCH since upgrading to > the 2.0.60 DSP code. Modem type is Asound-Link:PCI Audio+modem 56k > v.90 (Leadman Electronics). Any suggestions? > > -Cheryl Johnson > SEI Data Network Services > > __________________________________ Kalev Nurklik Delfi Online Pa"rnu mnt. 158, 11317 Tallinn, Estonia Tel: +372 6501709 Fax: +372 6501708 E-mail: k.nurklik@online.ee http://online.delfi.ee

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-18 13:30:42

Ah, ok that's a good point. Here in Japan, NTT is less than responsive, but that might not be a geographical problem. ^_^ I've not had a lot of interaction with telco's before. I'll give that a try. Thanks for the response. das Stainforth, Matthew (MatthewS@staff.brunnet.net) spake: > > Get together with your telco rep and make sure your translation supports > service messages. I understand that NI-2 does not but most (if not all) > others do. It just sounds like the switch is not listening to your RMB > requests. > > > -----Original Message----- > > From: D A Substanley [SMTP:das@gol.com] > > Sent: Monday, January 17, 2000 9:34 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Soft busy on HDM > > > > Hi Mike, > > > > Thanks for the response. I'm using PRI. I have had two cards soft busied > > for > > about three days with no change. Customers are still logging in happily, > > so it > > must be something to do with the switch type. Unfortunately, I have no > > access > > to any kind of support over here as 3Com Japan won't give me the time of > > day. > > <sigh> > > > > Thanks for the help! > > > > das > > > > Mike Andrews (mandrews@bit0.com) spake: > > > > > Are you running PRI or Channelized T1? > > > > > > If PRI, this probably has a lot to do with the switch type. On the > > DMS100 > > > we're on, I've never seen calls come into a card that's had all the > > > channels soft-busied. Just set the card to soft-busy, flash the new > > code, > > > wait for everyone to log out, then reboot the card. Voila. It's > > supposed > > > to work the same on a 5ESS. On INS1500 things could be different, I > > > guess... > > > > > > > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > > > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > > > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > > > "Don't sweat the petty things, and don't pet the sweaty things." > > > > > > On Mon, 17 Jan 2000, Christopher Berry wrote: > > > > > > > When I need to busy out a time span on a T1, I do a hard busy as I was > > told > > > > that the CO can override a soft busy. Since I do not want any traffic > > to > > > > come in while flashing, I'm told, I always do this. > > > > > > > > Hope this helps. > > > > > > > > Christopher Berry > > > > rof.net Web Design and Technical Support > > > > (970) 945-4920 x17 > > > > > > > > ----- Original Message ----- > > > > From: "D A Substanley" <das@gol.com> > > > > To: <usr-tc@lists.xmission.com> > > > > Sent: Saturday, January 15, 2000 8:16 AM > > > > Subject: Re: (usr-tc) Soft busy on HDM > > > > > > > > > > > > > Hi, > > > > > > > > > > Thanks for the response. Yes, I do wait. I have tried the command > > > > > several times but to no avail. It's frustrating to have a command > > > > > that I know would be extremely useful, but no able to implement. > > > > > > > > > > das > > > > > > > > > > Buzz Gould (buzzg@rconnect.com) spake: > > > > > > > > > > > After you hit the execute button, do you wait until every channel > > on the > > > > > > card shows "Success" in the result column? If you hit the close > > button > > > > > > before you get a success back for each channel, the command will > > fail > > > > and > > > > > > you will get calls on some of the channels. > > > > > > > > > > > > At 11:21 AM 1/14/00 +0900, you wrote: > > > > > > >Hi all, > > > > > > > > > > > > > >I'm having problems with soft busying HiperDSP cards. It seems > > that > > > > > > >even when I perform the soft busy on every channel, calls are > > still > > > > > > >able to come in on that card. Is there something that I am > > missing > > > > > > >on this concept? Could it be in any way related to the switch > > type? > > > > > > >I'm using INS1500. > > > > > > > > > > > > > >HDM -> 1.2.5 > > > > > > >HARC -> 4.1.59 > > > > > > > > > > > > > >Thanks > > > > > > > > > > > > > >das > > > > > > > > > > > > > > > > > > > > >-- > > > > > > >______________________________________________ > > > > > > >Alex Substanley Exodus Communications K.K. > > > > > > > Engineering Department > > > > > > >Das Man TEL: 81-3-5334-1700 > > > > > > >Systems Engineer FAX: 81-3-5334-1711 > > > > > > >______________________________________________ > > > > > > > > > > > > > >- > > > > > > > To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > For information on digests or retrieving files and old messages > > send > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > Buzz Gould > > > > > > Information Systems Engineer > > > > > > Rural Connections - a OneMain.com Company > > > > > > www.rconnect.com > > > > > > 507 847-2700 Ext. 6119 > > > > > > buzzg@rconnect.com > > > > > > > > > > > > - > > > > > > To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and old messages > > send > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > -- > > > > > ______________________________________________ > > > > > Alex Substanley Exodus Communications K.K. > > > > > Engineering Department > > > > > Das Man TEL: 81-3-5334-1700 > > > > > Systems Engineer FAX: 81-3-5334-1711 > > > > > ______________________________________________ > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages > > send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > -- > > ______________________________________________ > > Alex Substanley Exodus Communications K.K. > > Engineering Department > > Das Man TEL: 81-3-5334-1700 > > Systems Engineer FAX: 81-3-5334-1711 > > ______________________________________________ > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) Soft busy on HDM
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-18 14:43:32

On Mon, 17 Jan 2000, Christopher Berry wrote: > When I need to busy out a time span on a T1, I do a hard busy as I was told > that the CO can override a soft busy. Since I do not want any traffic to > come in while flashing, I'm told, I always do this. The difference between a hard busy and a soft busy out is how soon the line is made busy. With soft busy, the card is "soft core" and waits till the user logs off before making the channel busy. With hard busy, the card is real "hard core" and knocks anyone off that's logged onto the channel in reference immediately, no questions asked, then makes the channel busy. I haven't come across anyone ever saying that the telco can command the CPE to drop busy state. It would be a real surprise to me if that were true. Kevin Benton E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) Soft busy on HDM
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-18 14:49:24

On Tue, 18 Jan 2000, D A Substanley wrote: > Thanks for the response. I'm using PRI. I have had two cards soft busied for > about three days with no change. Customers are still logging in happily, so it > must be something to do with the switch type. Unfortunately, I have no access > to any kind of support over here as 3Com Japan won't give me the time of day. > <sigh> What kind of switch are you running to? Is it configured for custom or national mode? We made the mistake of allowing our telco to talk us into allowing them to set the switch into national mode on our lines. BIG MISTAKE! The 5ESS configuration for National Mode didn't communicate CPE Busy Out statuses correctly. Our customers would get fast busy a lot until we figured it out and had them put it back into Custom mode. Sheesh! Good luck on your issue. BTW, 3Com NC's have been a great help when I couldn't get hold of a good tech. (even when I do have a support contract). If you need more information, contact your 3Com Sales Rep and ask them to have your NC give you a call. Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: (usr-tc) 2.0.60
From: Jason A. Nunnelley <interests@linkfast.net>
Date: 2000-01-18 14:54:36

I heard good reports the last time I made a stupid post like this. So, I am posting once again. How many of you are using HiperDSP and have had experiences with the 2.0.60 code for the DSPs? I would appreciate feedback. Thanks in advance Jason A. Nunnelley President of Linkfast Internet Services, Linkfast Inc. 256-739-2008 VOICE CONTACT Linkfast Labs, GPN, MFG, MentionMe Studios, and, the Stupid Project http://www.linkfast.net

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-18 15:27:03

Thanks! Great information! Thanks, Lon. das Lon R. Stockton, Jr. (lon@moonstar.com) spake: > > On Tue, 18 Jan 2000, D A Substanley wrote: > > > When you do a hard busy on the span, does that > > immediately disconnect all of the users currently connected to that card, > > or is it friendlier? > > Immediate disconnect. That's the difference between a soft busy and a > hard busy. > > Hard Busy: Issues a local-out-of-service message to the switch, dropping > the call in progress and preventing any more from coming in. > > Soft Busy: Queues a local-out-of-service message, to be executed when > the current call finishes. I don't know if it's the HDSP that > queues it or if it's sent to the switch and it queues it. > > > If the soft busy isn't working, does a hard busy work? If not, the telco > switch isn't listening to you. > > When you do a soft busy, check it (with TCM) by going selecting the Span > and clicking Performance. Then check Timeslot and select the one(s) you > did a soft busy on. Then hit Default (for the Parameters in the Function > Group 'DS0 Statistics'). > > If there's a call in progress, the 'DS0 Service State' should be > 'inService', and the 'Queued Action for DS0' should be > 'localOutOfService'. When the call terminates, the 'DS0 Service State' > should go to 'localOutOfService' and the 'Queued Action...' should go > to 'none'. > > If it does that properly, and is still taking calls, we're back to > the switch not listening to you. A hard busy probably won't work > either. > > If it doesn't do that properly, whether it's the switch or the HDSP > depends on who's supposed to be doing the queueing (switch or DSP). > [I dunno. Maybe someone does and will respond to this]. > > This reminds me of one of my pet peeves. I wish there was a way to > mark a MODEM out of service (instead of a span timeslot). I.E, tell > the HDSP to never assign a call to a given modem (it'd mean the same > thing as a busyout if call selection was fixed, but if you were using > round-robin, you could still terminate a full PRI's worth of calls > even if you had a stuck modem). I'm just annoyed that modem #24 never > gets any calls because I gotta use fixed assignment because it's the > only way to skip the occasional stuck modem. </rant> > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: RE: (usr-tc) Soft busy on HDM
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-18 16:14:01

It is true. Our telco can send a quick off-hook on-hook wink and get the switch to drop the busy and return the line to service. I found this out after waiting half a day for users to drop off a T1 I had soft-busied and I saw users piling back on it again after it got about 3/4 empty. This was even after I had phoned the DMS group and told them I'd be working on it and NOT TO TOUCH IT...sigh...but I digress. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Kevin Benton [mailto:s1kevin@tims.net] > Sent: Tuesday, January 18, 2000 3:44 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Soft busy on HDM > > > On Mon, 17 Jan 2000, Christopher Berry wrote: > > > When I need to busy out a time span on a T1, I do a hard > busy as I was told > > that the CO can override a soft busy. Since I do not want > any traffic to > > come in while flashing, I'm told, I always do this. > > The difference between a hard busy and a soft busy out is how soon the > line is made busy. With soft busy, the card is "soft core" > and waits till > the user logs off before making the channel busy. With hard busy, the > card is real "hard core" and knocks anyone off that's logged onto the > channel in reference immediately, no questions asked, then makes the > channel busy. I haven't come across anyone ever saying that > the telco can > command the CPE to drop busy state. It would be a real > surprise to me if > that were true. > > Kevin Benton > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to > change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) mac's connect at slow speeds
From: David Ernst <drernst@kirkwood.hoosier.net>
Date: 2000-01-18 16:14:18

Does anyone else seem to have relatively consistent problems getting new Macintosh users to be able to connect at v.90 speeds? David Ernst HoosierNet, Inc.

Subject: (usr-tc) Diva TA
From: Aran Grooms <agrooms@calltech.com>
Date: 2000-01-18 16:16:54

Has anyone noticed any compatibility issues with Diva TAs and Hyperarcs? I've got a client who is completely unable to make any sort of connection to us, although he is able to connect to other providers (likely not using USR equipment). If anyone has seen this before, was there a workaround, or an update provided by eicon (or usr)? thanks! Aran Grooms NetWalk System Administrator agrooms@netwalk.com

Subject: Re: (usr-tc) Diva TA
From: Kent Tambling <kent@acceleration.net>
Date: 2000-01-18 16:32:05

Yup, confirmed here, they don't connect(well). We looked around for a work-around and found nothing, including Eicon's tech support. If they connect, they do a spiral to death thing and stop moving data. Kent Tambling kent@acceleration.net System Administrator www.acceleration.net ----- Original Message ----- Sent: Tuesday, January 18, 2000 4:16 PM Has anyone noticed any compatibility issues with Diva TAs and Hyperarcs? I've got a client who is completely unable to make any sort of connection to us, although he is able to connect to other providers (likely not using USR equipment). If anyone has seen this before, was there a workaround, or an update provided by eicon (or usr)? thanks! Aran Grooms NetWalk System Administrator agrooms@netwalk.com - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) WTB: USR Total Control High Density Chassis w/ 70A Power
From: Steve Rivera <sales@wrca.net>
Date: 2000-01-18 17:11:08

Immediate need for High Density Chassis w/ single 70A pwr supply. Always buying USR Total Control...Hiper DSP 2- Hiper ARC's available now. .................................................... WR Communication Associates, Inc. Worlwide Provider of Network Hardware Since 1981. I'm always available for your call...732-433-5890 Steve Rivera - sales@wrca.net v-732-833-2111 Office http://www.ISP-NetworkHardware.com or http://www.wrca.net ---ACCESS/TRANSMISSION SPECIALIST--- Cisco, Ascend, Livingston, USR, Microcom, Computone, Kentrox, Adtran...and more

Subject: (usr-tc) Arc 4.2.32-1 vs 4.1.22
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-18 18:24:08

Hello, Anyone care to elaborate on the differences you've seen between these two? I'm currently way back at 4.1.72. Are some of the early Mac ppp problems fixed as of this version? I've decided to go ahead with DSP 2.0.51 in hopes that it fixes the most compatibility issues, but I'm torn between the ARC releases. I don't want something flakey, but 3Com does seem to be pushing it by sticking it in TCS 3.6 as the only arc code in that bundle. I would very much like to deal with OSPF rather than RIP. What other fun things can I expect here? Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) Arc 4.2.32-1 vs 4.1.22
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-18 19:04:23

Thus spake Charles Sprickman >Anyone care to elaborate on the differences you've seen between these >two? I'm currently way back at 4.1.72. >Are some of the early Mac ppp problems fixed as of this version? I've >decided to go ahead with DSP 2.0.51 in hopes that it fixes the most >compatibility issues, but I'm torn between the ARC releases. I don't want >something flakey, but 3Com does seem to be pushing it by sticking it in >TCS 3.6 as the only arc code in that bundle. Well, keep in mind that the TCS releases are somewhat amorphous. :) The same DSP code in 3.5 is also in 3.6. The only thing new in TCS 3.6 was the HiPer Arc code, so basically TCS 3.5 and TCS 3.6 are pretty much completely interoperable. I wouldn't worry about it too much. :) >I would very much like to deal with OSPF rather than RIP. What other fun >things can I expect here? I wouldn't use OSPF...its still pretty rough...if in doubt, head on over to usr-tc.1st.net (Thanks Ed! great to have the searchability again!) and look for Mike Andrews posts about his problems. Depending on how your network is layed out, it might not bite you, but I'm still staying away from OSPF until it and the routing code is cleaned up a bit. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Problems with new HiperARC Code
From: Jorge Lozano <jorge@andinet.com>
Date: 2000-01-18 22:05:11

Hi! I�m trying upgrade HiperARC firmware with TCM 6.0.86 to new version (4.2.32). But during the firmware transfer (65% aprox.), the TCM give me an error... Failed. TFTP error: Access violation Can you tell me why? Thanks for all your help! Jorge Lozano Este mensaje fue enviado usando Andinet WebMail. http://www.andinet.com/

Subject: Re: (usr-tc) Arc 4.2.32-1 vs 4.1.22
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-19 02:24:58

On Tue, 18 Jan 2000, Jeff Mcadams wrote: > Well, keep in mind that the TCS releases are somewhat amorphous. :) I see what you mean. I spent a few hours digging around totalservice... > The same DSP code in 3.5 is also in 3.6. The only thing new in TCS 3.6 > was the HiPer Arc code, so basically TCS 3.5 and TCS 3.6 are pretty much > completely interoperable. I wouldn't worry about it too much. :) The "unresolved issues" list is much shorter under 4.2.32-1, but then again 4.1.22 was just released and this 4.2.32 release is from way back in September. I'm just trying to get a handle on what I can load and run with for at least a good 6 months... 4.1.72 has treated me fairly well, with all the chassis running at about 340 days of uptime. > I wouldn't use OSPF...its still pretty rough...if in doubt, head on over > to usr-tc.1st.net (Thanks Ed! great to have the searchability again!) > and look for Mike Andrews posts about his problems. Depending on how > your network is layed out, it might not bite you, but I'm still staying > away from OSPF until it and the routing code is cleaned up a bit. I simply want to use it for announcing routes for static IP users. The Relnotes on 4.2.32 mention a setting that should force the ARC to never become a DR, and that may fix the problems Mike had (at least in my application). Any thoughts on which has the most interoperable PPP code? I remember some issues with Macs and WebTV units that weren't modem related (unless it was in the PPP offloading)... Thanks, Charles

Subject: RE: (usr-tc) Soft busy on HDM
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-19 08:37:12

That's what our telco calls the state of the B channel when we busy them out from our end. I believe it stands for Remote Made Busy. It's analogous to LocalOutOfService in TCM. When they're taken out of service or turned down by the telco (RemoteOutOfService) they tend to call it IMB, what the "I" stands for, I can't remember. I suspect every switch manufacturer has a different term for out of service states but those are the ones with which I'm familiar. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: D A Substanley [mailto:das@gol.com] > Sent: Wednesday, January 19, 2000 5:37 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Soft busy on HDM > > > Hi Matthew, > > What does RMB stand for? I'm trying to explain this to our > NTT contact here, but it's rough going as it's all in Japanese. > > Thanks > > das > > Stainforth, Matthew (MatthewS@staff.brunnet.net) spake: > > > > > Get together with your telco rep and make sure your > translation supports > > service messages. I understand that NI-2 does not but most > (if not all) > > others do. It just sounds like the switch is not listening > to your RMB > > requests. > > > > > -----Original Message----- > > > From: D A Substanley [SMTP:das@gol.com] > > > Sent: Monday, January 17, 2000 9:34 PM > > > To: usr-tc@lists.xmission.com > > > Subject: Re: (usr-tc) Soft busy on HDM > > > > > > Hi Mike, > > > > > > Thanks for the response. I'm using PRI. I have had two > cards soft busied > > > for > > > about three days with no change. Customers are still > logging in happily, > > > so it > > > must be something to do with the switch type. > Unfortunately, I have no > > > access > > > to any kind of support over here as 3Com Japan won't give > me the time of > > > day. > > > <sigh> > > > > > > Thanks for the help! > > > > > > das > > > > > > Mike Andrews (mandrews@bit0.com) spake: > > > > > > > Are you running PRI or Channelized T1? > > > > > > > > If PRI, this probably has a lot to do with the switch > type. On the > > > DMS100 > > > > we're on, I've never seen calls come into a card that's > had all the > > > > channels soft-busied. Just set the card to soft-busy, > flash the new > > > code, > > > > wait for everyone to log out, then reboot the card. > Voila. It's > > > supposed > > > > to work the same on a 5ESS. On INS1500 things could be > different, I > > > > guess... > > > > > > > > > > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > > > > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > > > > Internet services for Frankfort, Lawrenceburg, Owenton, > Shelbyville > > > > "Don't sweat the petty things, and don't pet the sweaty things." > > > > > > > > On Mon, 17 Jan 2000, Christopher Berry wrote: > > > > > > > > > When I need to busy out a time span on a T1, I do a > hard busy as I was > > > told > > > > > that the CO can override a soft busy. Since I do not > want any traffic > > > to > > > > > come in while flashing, I'm told, I always do this. > > > > > > > > > > Hope this helps. > > > > > > > > > > Christopher Berry > > > > > rof.net Web Design and Technical Support > > > > > (970) 945-4920 x17 > > > > > > > > > > ----- Original Message ----- > > > > > From: "D A Substanley" <das@gol.com> > > > > > To: <usr-tc@lists.xmission.com> > > > > > Sent: Saturday, January 15, 2000 8:16 AM > > > > > Subject: Re: (usr-tc) Soft busy on HDM > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Thanks for the response. Yes, I do wait. I have > tried the command > > > > > > several times but to no avail. It's frustrating to > have a command > > > > > > that I know would be extremely useful, but no able > to implement. > > > > > > > > > > > > das > > > > > > > > > > > > Buzz Gould (buzzg@rconnect.com) spake: > > > > > > > > > > > > > After you hit the execute button, do you wait > until every channel > > > on the > > > > > > > card shows "Success" in the result column? If > you hit the close > > > button > > > > > > > before you get a success back for each channel, > the command will > > > fail > > > > > and > > > > > > > you will get calls on some of the channels. > > > > > > > > > > > > > > At 11:21 AM 1/14/00 +0900, you wrote: > > > > > > > >Hi all, > > > > > > > > > > > > > > > >I'm having problems with soft busying HiperDSP > cards. It seems > > > that > > > > > > > >even when I perform the soft busy on every > channel, calls are > > > still > > > > > > > >able to come in on that card. Is there > something that I am > > > missing > > > > > > > >on this concept? Could it be in any way related > to the switch > > > type? > > > > > > > >I'm using INS1500. > > > > > > > > > > > > > > > >HDM -> 1.2.5 > > > > > > > >HARC -> 4.1.59 > > > > > > > > > > > > > > > >Thanks > > > > > > > > > > > > > > > >das > > > > > > > > > > > > > > > > > > > > > > > >-- > > > > > > > >______________________________________________ > > > > > > > >Alex Substanley Exodus Communications K.K. > > > > > > > > Engineering Department > > > > > > > >Das Man TEL: 81-3-5334-1700 > > > > > > > >Systems Engineer FAX: 81-3-5334-1711 > > > > > > > >______________________________________________ > > > > > > > > > > > > > > > >- > > > > > > > > To unsubscribe to usr-tc, send an email to > > > "majordomo@xmission.com" > > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > > For information on digests or retrieving files > and old messages > > > send > > > > > > > > "help" to the same address. Do not use quotes > in your message. > > > > > > > > > > > > > > Buzz Gould > > > > > > > Information Systems Engineer > > > > > > > Rural Connections - a OneMain.com Company > > > > > > > www.rconnect.com > > > > > > > 507 847-2700 Ext. 6119 > > > > > > > buzzg@rconnect.com > > > > > > > > > > > > > > - > > > > > > > To unsubscribe to usr-tc, send an email to > > > "majordomo@xmission.com" > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > For information on digests or retrieving files > and old messages > > > send > > > > > > > "help" to the same address. Do not use quotes > in your message. > > > > > > > > > > > > -- > > > > > > ______________________________________________ > > > > > > Alex Substanley Exodus Communications K.K. > > > > > > Engineering Department > > > > > > Das Man TEL: 81-3-5334-1700 > > > > > > Systems Engineer FAX: 81-3-5334-1711 > > > > > > ______________________________________________ > > > > > > > > > > > > - > > > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and > old messages > > > send > > > > > > "help" to the same address. Do not use quotes in > your message. > > > > > > > > > > > > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and > old messages send > > > > > "help" to the same address. Do not use quotes in > your message. > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old > messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > -- > > > ______________________________________________ > > > Alex Substanley Exodus Communications K.K. > > > Engineering Department > > > Das Man TEL: 81-3-5334-1700 > > > Systems Engineer FAX: 81-3-5334-1711 > > > ______________________________________________ > > > > > > - > > > To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old > messages send > > > "help" to the same address. Do not use quotes in your message. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > -- > ______________________________________________ > Alex Substanley Exodus Communications K.K. > Engineering Department > Das Man TEL: 81-3-5334-1700 > Systems Engineer FAX: 81-3-5334-1711 > ______________________________________________ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) mac's connect at slow speeds
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-19 09:21:04

My tech support has reported success with adding additional info to the initialization string to limit the top end connect speed. This has been very effective on the PC side, and one of my techs knows how to do it on Macs. I will try to get the info from him when he arrives and post it. We ran into this problem with some of the Compaq systems recently. We limit the top end to about 42000 to start and work up or down from there in a trial and error method to find a speed that works all the time. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Wednesday, January 19, 2000 9:23 AM > I have had lots of problems with the imac. I found the information below on > their website. Hope this helps. > > ------------------------------------------------------------------------- > > The iMac modem is the first modem Apple has shipped that supports the new > V.90 protocol. Although derived from the competing x2 and K56flex protocols, > the V.90 specification is in its infancy and will be undergoing changes over > the next several months. > > When a modem is attempting to establish a connection with another modem it > will attempt to connect at the highest speed possible. The speed of the > connection is determined by two factors: > > 1. The capabilities of the other modem: > The remote modem must support the same protocols. The iMac modem supports > both V.90 and K56flex protocols so it can connect to other modems that > support these protocols at speeds between 33.6 kbps and 53 kbps (although > the modem technology is capable of 56 kbps, FCC regulations limit the top > speed to 53 kbps). If the remote modem does not support either of these > protocols, the iMac modem will then try using the V.34 protocol which has a > top speed of 33.6 kbps. The modems will continue to try slower protocols > until they find one that both modems are capable of supporting. > > 2. Quality of the connection: > Modem connections are being made over regular voice telephone lines. The > quality of a connection between two points can be different each time the > connections is made. Once the modems have negotiated a protocol to use, they > test the ability of the connection to sustain the speed of the connection. > The higher the speed of the connection, the more susceptible it is to noise > on the phone lines. Therefore, even when making a V.90 connection between > the same two points, one connection could be 44000 bps while the other could > be 38000 bps. > > If the quality of the connection is such that it can not support the slowest > V.90 connection then the modems will step down to the next protocol. > > What we are observing with the iMac modem is this V.90 implementation is > overly aggressive. Instead of negotiating down to support a slower but more > stable connection, the modem keeps trying to connect at a higher speed. This > causes the remote modem to determine that a connection can't be established > and it hangs up. > > There are times when this aggressive behavior will manage to complete a > connection, only to be dropped minutes later since the quality of the phone > connection really can not support that connection speed. > > The V.34 only modem script is a work around for customers that are unable to > connect using the V.90 protocol. In many cases, even if the V.90 > implementation negotiated downward properly, the resulting connection might > end up being between 28.8 kbps and 33.6 kbps due to phone line quality. In > these cases there is no performance difference between using the V.34 and > V.90 protocols. > > Apple is working with others in the modem industry to improve the behavior > of the V.90 implementation. The iMac modem is capable of being upgraded via > software. > > Currently, modem firmware updates are available from the Apple Software > Updates updates page at: 'http://asu.info.apple.com'. > > For additional information on 56 kbps connectivity, see: > Tech Info Library Article 24482: "56Kbps Modems: Getting the Fastest > Connection" > > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Ernst > > Sent: Tuesday, January 18, 2000 3:14 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) mac's connect at slow speeds > > > > > > Does anyone else seem to have relatively consistent problems getting > > new Macintosh users to be able to connect at v.90 speeds? > > > > David Ernst > > HoosierNet, Inc. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) mac's connect at slow speeds
From: Howard Reeves <hreeves@altamontks.com>
Date: 2000-01-19 09:23:09

I have had lots of problems with the imac. I found the information below on their website. Hope this helps. The iMac modem is the first modem Apple has shipped that supports the new V.90 protocol. Although derived from the competing x2 and K56flex protocols, the V.90 specification is in its infancy and will be undergoing changes over the next several months. When a modem is attempting to establish a connection with another modem it will attempt to connect at the highest speed possible. The speed of the connection is determined by two factors: 1. The capabilities of the other modem: The remote modem must support the same protocols. The iMac modem supports both V.90 and K56flex protocols so it can connect to other modems that support these protocols at speeds between 33.6 kbps and 53 kbps (although the modem technology is capable of 56 kbps, FCC regulations limit the top speed to 53 kbps). If the remote modem does not support either of these protocols, the iMac modem will then try using the V.34 protocol which has a top speed of 33.6 kbps. The modems will continue to try slower protocols until they find one that both modems are capable of supporting. 2. Quality of the connection: Modem connections are being made over regular voice telephone lines. The quality of a connection between two points can be different each time the connections is made. Once the modems have negotiated a protocol to use, they test the ability of the connection to sustain the speed of the connection. The higher the speed of the connection, the more susceptible it is to noise on the phone lines. Therefore, even when making a V.90 connection between the same two points, one connection could be 44000 bps while the other could be 38000 bps. If the quality of the connection is such that it can not support the slowest V.90 connection then the modems will step down to the next protocol. What we are observing with the iMac modem is this V.90 implementation is overly aggressive. Instead of negotiating down to support a slower but more stable connection, the modem keeps trying to connect at a higher speed. This causes the remote modem to determine that a connection can't be established and it hangs up. There are times when this aggressive behavior will manage to complete a connection, only to be dropped minutes later since the quality of the phone connection really can not support that connection speed. The V.34 only modem script is a work around for customers that are unable to connect using the V.90 protocol. In many cases, even if the V.90 implementation negotiated downward properly, the resulting connection might end up being between 28.8 kbps and 33.6 kbps due to phone line quality. In these cases there is no performance difference between using the V.34 and V.90 protocols. Apple is working with others in the modem industry to improve the behavior of the V.90 implementation. The iMac modem is capable of being upgraded via software. Currently, modem firmware updates are available from the Apple Software Updates updates page at: 'http://asu.info.apple.com'. For additional information on 56 kbps connectivity, see: Tech Info Library Article 24482: "56Kbps Modems: Getting the Fastest Connection" > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Ernst > Sent: Tuesday, January 18, 2000 3:14 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) mac's connect at slow speeds > > > Does anyone else seem to have relatively consistent problems getting > new Macintosh users to be able to connect at v.90 speeds? > > David Ernst > HoosierNet, Inc. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Diva TA
From: Aran Grooms <agrooms@calltech.com>
Date: 2000-01-19 09:48:54

Has anyone seen the same problems with Netservers? I had our customer attempt a connection to one of our netservers, and they had the same issue. Aran Grooms NetWalk System Administrator agrooms@netwalk.com > -----Original Message----- > From: Kent Tambling [mailto:Kent@acceleration.net] > Sent: Tuesday, January 18, 2000 4:32 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Diva TA > > > Yup, confirmed here, they don't connect(well). We looked around for a > work-around > and found nothing, including Eicon's tech support. If they > connect, they do > a spiral > to death thing and stop moving data. > > Kent Tambling > kent@acceleration.net > System Administrator > www.acceleration.net > > > ----- Original Message ----- > From: "Aran Grooms" <agrooms@calltech.com> > To: "Usr-Tc (E-mail)" <usr-tc@lists.xmission.com> > Sent: Tuesday, January 18, 2000 4:16 PM > Subject: (usr-tc) Diva TA > > > Has anyone noticed any compatibility issues with Diva TAs and > Hyperarcs? > I've got a client who is completely unable to make any sort > of connection to > us, although he is able to connect to other providers (likely > not using USR > equipment). If anyone has seen this before, was there a > workaround, or an > update provided by eicon (or usr)? > > thanks! > > Aran Grooms > NetWalk System Administrator > agrooms@netwalk.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) D Channel Problem
From: Jason P. <jjperc@petronet.net>
Date: 2000-01-19 10:10:34

I just installed our seventh Hiper DSP card into our chassis and the Loopback/D-Alarm LED on this card keeps alternating between green and red about every 30 seconds. I have this card set up exactly like the other cards in this chassis and the telco (supposedly) has this span setup the same way as all of our others. Does anyone have any insight into what could be going on? Here are my specs: T1 PRI Hiper DSP 2.0.81 Hiper ARC 4.1.59-6 Hiper NMC 6.1.17 Thanks in advance.

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-19 10:12:10

Hi Kevin, Thanks for your response. I'm running to a switch type of INS1500 (Japan standard) which always makes things touch and go as that is not what everyone else is using on this list. The other problem is, of course, that I don't have a 3Com sales rep. The one we had they transferred, and since we were told by 3Com that we weren't important to them, they never gave us a new one. <sigh> If it weren't for the hardware... das Kevin Benton (s1kevin@tims.net) spake: > On Tue, 18 Jan 2000, D A Substanley wrote: > > > Thanks for the response. I'm using PRI. I have had two cards soft busied for > > about three days with no change. Customers are still logging in happily, so it > > must be something to do with the switch type. Unfortunately, I have no access > > to any kind of support over here as 3Com Japan won't give me the time of day. > > <sigh> > > What kind of switch are you running to? Is it configured for custom or > national mode? We made the mistake of allowing our telco to talk us into > allowing them to set the switch into national mode on our lines. BIG > MISTAKE! The 5ESS configuration for National Mode didn't communicate CPE > Busy Out statuses correctly. Our customers would get fast busy a lot > until we figured it out and had them put it back into Custom mode. > Sheesh! > > Good luck on your issue. BTW, 3Com NC's have been a great help when I > couldn't get hold of a good tech. (even when I do have a support > contract). If you need more information, contact your 3Com Sales Rep and > ask them to have your NC give you a call. > > Kevin > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: (usr-tc) Restricting MPPP
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 2000-01-19 10:26:53

Hi, Same problem as I figured out last time--- multiple users, one of them is setup (client) for MPPP, any connections afterwards will get dropped as they definately won't be able to bond to the other connection. IS there a way to limit MPPP with a RADIUS attribute? (using livingston 2.01). Seems like I ought to be able to <not allow> MPPP, but not as a check event as in IF you want MPPP, but we say no, drop the connection (pain in the butt), but more like So you want MPPP, fine, we're not going to allow it but you think what you want to think. Make sense? Port-Limit attibute wouldn't do it. Not seeing any other attributes that really do it either. I did look through the usr-tc archive. Anyone know? I would really think this'd be something I ought to be able to control. I can't even filter for it either, now can I? It's grabbing the username at the HiperARC upon login. SMT

Subject: (usr-tc) Domain Name
From: S. O. Okeyo <okeyoso@skyweb.co.ke>
Date: 2000-01-19 10:28:49

Hello People! Can someone direct me to where I may register a NAME SERVER and have domain names hosted in the USA? Okeyo

Subject: Re: (usr-tc) Arc 4.2.32-1 vs 4.1.22
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-19 10:33:34

On Wed, 19 Jan 2000, Charles Sprickman wrote: > > I wouldn't use OSPF...its still pretty rough...if in doubt, head on over > > to usr-tc.1st.net (Thanks Ed! great to have the searchability again!) > > and look for Mike Andrews posts about his problems. Depending on how > > your network is layed out, it might not bite you, but I'm still staying > > away from OSPF until it and the routing code is cleaned up a bit. > > I simply want to use it for announcing routes for static IP users. The > Relnotes on 4.2.32 mention a setting that should force the ARC to never > become a DR, and that may fix the problems Mike had (at least in my > application). It doesn't. I'm using OSPF for more or less what you want to use it for. The problem I had was that there was a static route in my network that overlapped the subnet that the ARC was on, and it messed up the ARC's idea of what its netmask was. It's kinda serious, but at the same time, not something tons of people will run into. DR selection doesn't really enter into it... though the ARCs should never become one in my network now. Despite the problems I'm actually still running 4.2.32 anyway... I have workarounds for the serious problems in place, and I *really* don't want to go back and reconfigure RIPv2 on everything. (It's kinda a lesser of two evils thing.) > Any thoughts on which has the most interoperable PPP code? I remember > some issues with Macs and WebTV units that weren't modem related (unless > it was in the PPP offloading)... WebTV problems were limited to the original 4.1.x release, and the ER that came out about a week later fixed that, if I remember right. FreePPP on the Mac I'm not sure of the current status... it might still be glitchy. Most of our Mac people are on Open Transport PPP now anyway. OT comes with every Y2K compliant version of MacOS except for 7.5.5 anyway... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things."

Subject: (usr-tc) Domain Name
From: S. O. Okeyo <okeyoso@skyweb.co.ke>
Date: 2000-01-19 10:46:56

Hello People! I am unable to send or receive mails fro equipment list. Can someone advise me if the list is closed or what I can do to get and receive mails. I was informed that I am already registered. Okeyo

Subject: RE: (usr-tc) Restricting MPPP
From: Scott Trautman <scottt@corp.gdinet.com>
Date: 2000-01-19 11:22:52

-----Original Message----- Sent: Wednesday, January 19, 2000 10:53 AM Thus spake Scott Trautman >Same problem as I figured out last time--- multiple users, one of them >is setup (client) for MPPP, any connections afterwards will get dropped >as they definately won't be able to bond to the other connection. >IS there a way to limit MPPP with a RADIUS attribute? (using livingston >2.01). Seems like I ought to be able to <not allow> MPPP, but not as a >check event as in IF you want MPPP, but we say no, drop the connection >(pain in the butt), but more like So you want MPPP, fine, we're not >going to allow it but you think what you want to think. >Make sense? Not really. >Port-Limit attibute wouldn't do it. >Not seeing any other attributes that really do it either. I did look through >the usr-tc archive. >Anyone know? I would really think this'd be something I ought to be >able to control. I can't even filter for it either, now can I? It's >grabbing the username at the HiperARC upon login. So...what exactly is your problem here...I didn't follow. You have multiple people logging in with the same userid? You limit that with YES. Simultaneous-Use (non-reliably as far as I'm concerned), or with a script that goes in and checks for duplicate logins (I recommend SNMP for this). Port-Limit will limit the number of channels allowed in a multi-link bundle. These really shouldn't interact. There is no way really to enable or disable multi-link on a per-user basis...you can disable it on the whole Arc with "disable ppp multilink_ppp", but then you won't let *anyone* use MP...not what you want I suspect. Port-Limit can be set to 1, which would allow them to run MP, but only allow one link in the bundle...essentially, they get no benefit from MP at that point, but technically they can still run the MP protocol. Okay, I'll try Port-Limit, but doubt that's going to work. If you're running into multiple users running multi-link logging in seperately, but your Arcs are trying to bundle the links together, then you need to get a log of the LCP negotiation of the connections...it sounds like they're not sending a Multi-Link endpoint discriminator, or the Arc is handing it incorrectly. If they're logging in from seperate Separate locations not a problem. It's only within 1 unit for multiple people using the SAME userid. If the client is broken, okay so it is, I don't have much control over that; just seems to me that the Arc ought be able to limit this, or time-out the endpoint thing. Dunno. locations, they should have seperate EDO's, and the Arc should (and I haven't seen any problems with this) handle the connections as totally seperate sessions, Port-Limit wouldn't apply, Multi-Link is a moot point. Anyway...maybe you can give a better description of what you're seeing...and the behavior you'd like to see...there should be a way of doing what you want without actually disabling MP for the user. There's really very little reason to need to actually disable MP for a user. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Serial Connection and HiperArc 4.1.22
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-19 11:50:59

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Bosire |Sent: Wednesday, January 19, 2000 8:55 AM |To: usr-tc |Subject: (usr-tc) Serial Connection and HiperArc 4.1.22 | |Hi's | |I upgraded one my Netservers to HiperArc 4.1.22 and I can no longer |configure services per modem basis. |I used to offer rlogin services on a group of modems [ for uucp, |rather archaic but still in use] on the former and now that cant work on |the latter. |All there is on the HiperArc is global config for either Radius or |Tacas Auth. | |Anyone knows how i can configure per modem basis differnt services, eg |configure a group of modem to handle my uucp clients who are |authenticated on a different host from the Radius Server.. | Richard, You can configure individual modems by using the "set interface slot:x/mod:y ... " syntax.. With that you can set specific modems to do CLEARTCP, telnet, or rlogin to a predefined host.. You will have to make sure that your span is routing calls in a predictable manner and that your lead numbers point to the correct channel. -M

Subject: Re: (usr-tc) Restricting MPPP
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-19 11:52:33

Thus spake Scott Trautman >Same problem as I figured out last time--- multiple users, one of them >is setup (client) for MPPP, any connections afterwards will get dropped >as they definately won't be able to bond to the other connection. >IS there a way to limit MPPP with a RADIUS attribute? (using livingston >2.01). Seems like I ought to be able to <not allow> MPPP, but not as a >check event as in IF you want MPPP, but we say no, drop the connection >(pain in the butt), but more like So you want MPPP, fine, we're not >going to allow it but you think what you want to think. >Make sense? Not really. >Port-Limit attibute wouldn't do it. >Not seeing any other attributes that really do it either. I did look through >the usr-tc archive. >Anyone know? I would really think this'd be something I ought to be >able to control. I can't even filter for it either, now can I? It's >grabbing the username at the HiperARC upon login. So...what exactly is your problem here...I didn't follow. You have multiple people logging in with the same userid? You limit that with Simultaneous-Use (non-reliably as far as I'm concerned), or with a script that goes in and checks for duplicate logins (I recommend SNMP for this). Port-Limit will limit the number of channels allowed in a multi-link bundle. These really shouldn't interact. There is no way really to enable or disable multi-link on a per-user basis...you can disable it on the whole Arc with "disable ppp multilink_ppp", but then you won't let *anyone* use MP...not what you want I suspect. Port-Limit can be set to 1, which would allow them to run MP, but only allow one link in the bundle...essentially, they get no benefit from MP at that point, but technically they can still run the MP protocol. If you're running into multiple users running multi-link logging in seperately, but your Arcs are trying to bundle the links together, then you need to get a log of the LCP negotiation of the connections...it sounds like they're not sending a Multi-Link endpoint discriminator, or the Arc is handing it incorrectly. If they're logging in from seperate locations, they should have seperate EDO's, and the Arc should (and I haven't seen any problems with this) handle the connections as totally seperate sessions, Port-Limit wouldn't apply, Multi-Link is a moot point. Anyway...maybe you can give a better description of what you're seeing...and the behavior you'd like to see...there should be a way of doing what you want without actually disabling MP for the user. There's really very little reason to need to actually disable MP for a user. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Serial Connection and HiperArc 4.1.22
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-19 11:54:10

Why are messages from Mike wanting to download the pan-european text display feature? Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Wednesday, January 19, 2000 11:50 AM > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Bosire > |Sent: Wednesday, January 19, 2000 8:55 AM > |To: usr-tc > |Subject: (usr-tc) Serial Connection and HiperArc 4.1.22 > | > |Hi's > | > |I upgraded one my Netservers to HiperArc 4.1.22 and I can no longer > |configure services per modem basis. > |I used to offer rlogin services on a group of modems [ for uucp, > |rather archaic but still in use] on the former and now that cant work on > |the latter. > |All there is on the HiperArc is global config for either Radius or > |Tacas Auth. > | > |Anyone knows how i can configure per modem basis differnt services, eg > |configure a group of modem to handle my uucp clients who are > |authenticated on a different host from the Radius Server.. > | > > Richard, > You can configure individual modems by using the "set interface > slot:x/mod:y ... " syntax.. With that you can set specific modems to do > CLEARTCP, telnet, or rlogin to a predefined host.. You will have to make > sure that your span is routing calls in a predictable manner and that your > lead numbers point to the correct channel. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) mac's connect at slow speeds
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-19 12:40:30

Listed below is the info from my local Mac Guru. Hope it helps... Yup, but it's not trivial. You need to edit the modem script, which lives in the modem scripts folder inside the extensions folder which is inside the system folder. The modem scripts are just text documents, but they have special type and creator codes which you must restore using ResEdit or some other such utility. The easiest way to do this, though is to use Apple's Modem Script Generator Utility available at <http://asu.info.apple.com/swupdates.nsf/artnum/n10664>. Personally, I just edit the scripts manually because I'm a dweeb and like to have absolute control over what I'm doing, but the fact is that the script generator generates the exact same CCL code that I do except the Script Generator's code is commented and mine isn't. You select the Modem Script in the Modem Control Panel. If all of this is too confusing, tell me exactly what you want, and I'll edit some scripts for you that you can just pass on to customers. Apple has some prewritten scripts on their website that limit the connection to v.34, but I think that's probably overkill. In addition, Ross Barkman has written a series of scripts for the G3 powerbooks, which allow the user to use a trial and error method to get the best performance vs stability compromise. Ross's scripts can be located by doing a search at <http://www.versiontracker.com> for Modem Script. This search will also point you at a bunch of other script options that may be of use. At all costs, avoid Modem Puppet scripts as they don't work in the real world. HTH Old Bill Fuller Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: Re: (usr-tc) Restricting MPPP
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-19 12:51:45

Thus spake Scott Trautman >Separate locations not a problem. It's only within 1 unit for multiple >people using the SAME userid. If the client is broken, okay so it is, I >don't have much control over that; just seems to me that the Arc ought >be able to limit this, or time-out the endpoint thing. Dunno. OK...I'm still confused...you're dealing with one Arc...I got that. You have multiple people logging in with the same userid...got that. Are the people logging in from different locations? If so, they should have different EDO's, and the Arc shouldn't be trying to bundle them together. Its possible that the clients aren't sending EDO's, and then, if they're using the same userid, then the Arc is trying to bundle them together, as it should according to the spec (RFC1990). Can you get a log of the LCP negotiations here so we can see what's really going on? If they're using the same EDO, or no EDO, then the Arc is trying to bundle them together, as it should...if they're using different EDO's, and the Arc is trying to bundle them together, then there's a bug in the Arc. What you need to set to prevent this situation is dependant upon what's happening...if they're trying to get bundled together, then you need to set Port-Limit...if they're not getting bundled together then you need to use Simultaneous-Use, or an SNMP script to boot off duplicates (or whatever). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) ARC tftp upload
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-19 12:57:38

TFTP direct or z-modem via console port.. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman |Sent: Wednesday, January 19, 2000 12:53 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) ARC tftp upload | | |Hi, | |Is there any way (not involving snmp) to upload new code to the arc? Or |to download from the arc cli? | |On site, and would like to give this a whirl as my laptop (w/TCM) is being |unpredictable... | |Thanks, | |Charles | |-- |=-----------------= = || Charles Sprickman Internet Channel | || INCH System Administration Team (212)243-5200 | || spork@inch.com access@inch.com | |= =----------------= | | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the message. | For information on digests or retrieving files and old messages send | "help" to the same address. Do not use quotes in your message. |

Subject: RE: (usr-tc) D Channel Problem
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-19 13:27:08

Was the telco able to successfully turn up the T1 carrier and the D channel? If not, you have a provisioning or configuration problem. Have a look in the manual...it should tell you what the blinking LED state means. And that should give you a clue as to what exactly is the problem. Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Jason P. [mailto:jjperc@petronet.net] > Sent: Wednesday, January 19, 2000 12:11 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) D Channel Problem > > > I just installed our seventh Hiper DSP card into our chassis and the > Loopback/D-Alarm LED on this card keeps alternating between green and > red about every 30 seconds. I have this card set up exactly like the > other cards in this chassis and the telco (supposedly) has this span > setup the same way as all of our others. Does anyone have any insight > into what could be going on? > > Here are my specs: > > T1 PRI > Hiper DSP 2.0.81 > Hiper ARC 4.1.59-6 > Hiper NMC 6.1.17 > > Thanks in advance. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) ARC tftp upload
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-19 13:52:45

Hi, Is there any way (not involving snmp) to upload new code to the arc? Or to download from the arc cli? On site, and would like to give this a whirl as my laptop (w/TCM) is being unpredictable... Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) ARC tftp upload
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-19 14:06:54

Thus spake Charles Sprickman >Is there any way (not involving snmp) to upload new code to the arc? Or >to download from the arc cli? >On site, and would like to give this a whirl as my laptop (w/TCM) is being >unpredictable... If the Arc has software code up and running, it has tftp client and server capabilities. You can use either to get the code to the Arc. As long as you can get the code to the Arc and stored in the flash filesystem as "netserve.dmf", it will see it on the next boot up and install the new code for use. If the Arc *doesn't* have operational code running, the boot prom has tftp client capabilities...in the initial bootup, if you're plugged into the console of the Arc, you'll see a boot menu come up...from there you can pick a tftp server IP, filename, etc. select boot from network, boot from network once, and indicate the Arc's ip address, netmask and gateway during the process...it is safe to use the same ip address during this process that the Arc usually uses since the two stacks are never active at the same time. This would allow it to pull the dmf image off a tftp server during the boot process even if there is no runnable image on the Arc currently. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) ARC & NMC IP Addresses
From: Jeremy Gault <jgault@wingnet.net>
Date: 2000-01-19 14:10:46

Hi, We are needing to change the IP addresses of our HiPer ARC and NMC cards. Does anyone know/have the command used to change these? (I'm sure it's something simple.) Any help would be appreciate.d Thanks. Jeremy Jeremy Gault Systems Administrator - WingNET Internet Services http://www.wingnet.net

Subject: (usr-tc) Strange syslog entries
From: Randy McMillan <randy@pacinfo.com>
Date: 2000-01-19 14:18:39

Is there anyone who can tell me what these entries in my syslog mean and/or how to prevent the hyper arc from sending them. Am running 4.1.59-6. Usually there aren't all that many, but today it seemed to be going wild and started affecting the mail server. I don't think I have any "Taps" going. Jan 19 11:56:14 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog capture:stop Jan 19 11:56:22 tc2 last message repeated 345 times Jan 19 11:56:22 tc2 --syslog capture: ed1d0103 slot:4/mod:2 --syslog capture:stop Jan 19 11:56:22 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog capture:stop Jan 19 11:56:53 tc2 last message repeated 1282 times Jan 19 11:57:53 tc2 last message repeated 2676 times Jan 19 11:58:40 tc2 last message repeated 1539 times Jan 19 11:59:43 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog capture:stop Jan 19 12:00:45 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog capture:stop Thanks for any information. Randy McMillan PacInfo

Subject: (usr-tc) Mac Modems
From: James Cook <james@net-resource.com>
Date: 2000-01-19 14:46:14

Has anyone had problems with the PowerBook G3 Apple Internal modems connecting to Total Control HiperDSPs? These modems are Rockwell based and seem to go into the "spiral of death" when connecting using V.90. They appear to connect fine using V.34. We are running 2.0.60 for the DSPs, 4.1.59 on the HiperArcs, & 5.5.5 on the NMCs. TIA, ======================= James M. Cook Net Resource 603.629.9008x302 Fax: 603.629.9749 james@net-resource.com

Subject: (usr-tc) Vendors of 3Com equipment?
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-19 15:00:15

I am looking for vendors of 3Com TCH equipment, primarily DSP's, selling new or used equipment. If you know of reputable vendors please respond off-list to mark@corridor.net. Thanks, Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: Re: (usr-tc) Vendors of 3Com equipment?
From: Mark E. Levy <mark@fsi.net>
Date: 2000-01-19 15:25:28

John DeDonato, Source Technology 888-765-5758 x2267 www.source-technology.com Mark Thornton wrote: > > I am looking for vendors of 3Com TCH equipment, primarily DSP's, selling new > or used equipment. If you know of reputable vendors please respond off-list > to mark@corridor.net. > > Thanks, > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 -- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.net

Subject: Re: (usr-tc) Vendors of 3Com equipment?
From: Richard Lorbieski <richard@alpha1.net>
Date: 2000-01-19 15:44:00

I deal with a different rep. , but it's a good company to do business with. "Mark E. Levy" wrote: > > John DeDonato, Source Technology 888-765-5758 x2267 > www.source-technology.com > > Mark Thornton wrote: > > > > I am looking for vendors of 3Com TCH equipment, primarily DSP's, selling new > > or used equipment. If you know of reputable vendors please respond off-list > > to mark@corridor.net. > > > > Thanks, > > > > Mark Thornton > > San Marcos Internet, Inc. > > 512-393-5300 > > -- > --------------------------------------------------------------------- > Mark E. Levy, President > FSINet, Inc. > 800-827-6085 x202 > 847-753-6832 fax > www.fsi.net > mark@fsi.net > --------------------------------------------------------------------- > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Richard Lorbieski - richard@alpha1.net Chief Technical Officer - Senior System Administrator Alpha1 Internet http://www.alpha1.net 409.731.8236 - 877.4.alpha1 (877.425.7421)

Subject: (usr-tc) Serial Connection and HiperArc 4.1.22
From: Richard Bosire <rbosire@africaonline.co.ke>
Date: 2000-01-19 17:55:08

Hi's I upgraded one my Netservers to HiperArc 4.1.22 and I can no longer configure services per modem basis. I used to offer rlogin services on a group of modems [ for uucp, rather archaic but still in use] on the former and now that cant work on the latter. All there is on the HiperArc is global config for either Radius or Tacas Auth. Anyone knows how i can configure per modem basis differnt services, eg configure a group of modem to handle my uucp clients who are authenticated on a different host from the Radius Server.. TIA bosire richard bosire AfricaOnline (k) Ltd. p.o box 63017 Nairobi, Kenya tel 254.2.243775, fax 254.2.243762 http://www.africaonline.co.ke

Subject: Re: (usr-tc) Backing up NMC and ARC configs
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-19 17:59:55

On Thu, 20 Jan 2000, Campbell Simpson wrote: > Hi all > > Just following on from the ARC tftp upload thread, does anyone have an cunning way to backup and restore the full config of an NMC or ARC card. Not to be an ass, but since I never found a way, I initially ran a script of my first config and saved it out as a file. Whenever I make any changes, I also make it to this file. So far, it's made configuring new ARCs extremely easy... Now of course a single config file like a Cisco has would be wonderful, as it makes it super easy to back things up. Long ago I tftp'd down all the files I could grab off the thing and really couldn't find a single file with all settings... Charles > Its a real pain if you have to swap out cards and re-configure the cards manually. > > Cheers > > Campbell > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-19 18:37:25

Hi Matthew, What does RMB stand for? I'm trying to explain this to our NTT contact here, but it's rough going as it's all in Japanese. Thanks das Stainforth, Matthew (MatthewS@staff.brunnet.net) spake: > > Get together with your telco rep and make sure your translation supports > service messages. I understand that NI-2 does not but most (if not all) > others do. It just sounds like the switch is not listening to your RMB > requests. > > > -----Original Message----- > > From: D A Substanley [SMTP:das@gol.com] > > Sent: Monday, January 17, 2000 9:34 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Soft busy on HDM > > > > Hi Mike, > > > > Thanks for the response. I'm using PRI. I have had two cards soft busied > > for > > about three days with no change. Customers are still logging in happily, > > so it > > must be something to do with the switch type. Unfortunately, I have no > > access > > to any kind of support over here as 3Com Japan won't give me the time of > > day. > > <sigh> > > > > Thanks for the help! > > > > das > > > > Mike Andrews (mandrews@bit0.com) spake: > > > > > Are you running PRI or Channelized T1? > > > > > > If PRI, this probably has a lot to do with the switch type. On the > > DMS100 > > > we're on, I've never seen calls come into a card that's had all the > > > channels soft-busied. Just set the card to soft-busy, flash the new > > code, > > > wait for everyone to log out, then reboot the card. Voila. It's > > supposed > > > to work the same on a 5ESS. On INS1500 things could be different, I > > > guess... > > > > > > > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > > > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > > > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > > > "Don't sweat the petty things, and don't pet the sweaty things." > > > > > > On Mon, 17 Jan 2000, Christopher Berry wrote: > > > > > > > When I need to busy out a time span on a T1, I do a hard busy as I was > > told > > > > that the CO can override a soft busy. Since I do not want any traffic > > to > > > > come in while flashing, I'm told, I always do this. > > > > > > > > Hope this helps. > > > > > > > > Christopher Berry > > > > rof.net Web Design and Technical Support > > > > (970) 945-4920 x17 > > > > > > > > ----- Original Message ----- > > > > From: "D A Substanley" <das@gol.com> > > > > To: <usr-tc@lists.xmission.com> > > > > Sent: Saturday, January 15, 2000 8:16 AM > > > > Subject: Re: (usr-tc) Soft busy on HDM > > > > > > > > > > > > > Hi, > > > > > > > > > > Thanks for the response. Yes, I do wait. I have tried the command > > > > > several times but to no avail. It's frustrating to have a command > > > > > that I know would be extremely useful, but no able to implement. > > > > > > > > > > das > > > > > > > > > > Buzz Gould (buzzg@rconnect.com) spake: > > > > > > > > > > > After you hit the execute button, do you wait until every channel > > on the > > > > > > card shows "Success" in the result column? If you hit the close > > button > > > > > > before you get a success back for each channel, the command will > > fail > > > > and > > > > > > you will get calls on some of the channels. > > > > > > > > > > > > At 11:21 AM 1/14/00 +0900, you wrote: > > > > > > >Hi all, > > > > > > > > > > > > > >I'm having problems with soft busying HiperDSP cards. It seems > > that > > > > > > >even when I perform the soft busy on every channel, calls are > > still > > > > > > >able to come in on that card. Is there something that I am > > missing > > > > > > >on this concept? Could it be in any way related to the switch > > type? > > > > > > >I'm using INS1500. > > > > > > > > > > > > > >HDM -> 1.2.5 > > > > > > >HARC -> 4.1.59 > > > > > > > > > > > > > >Thanks > > > > > > > > > > > > > >das > > > > > > > > > > > > > > > > > > > > >-- > > > > > > >______________________________________________ > > > > > > >Alex Substanley Exodus Communications K.K. > > > > > > > Engineering Department > > > > > > >Das Man TEL: 81-3-5334-1700 > > > > > > >Systems Engineer FAX: 81-3-5334-1711 > > > > > > >______________________________________________ > > > > > > > > > > > > > >- > > > > > > > To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > > For information on digests or retrieving files and old messages > > send > > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > Buzz Gould > > > > > > Information Systems Engineer > > > > > > Rural Connections - a OneMain.com Company > > > > > > www.rconnect.com > > > > > > 507 847-2700 Ext. 6119 > > > > > > buzzg@rconnect.com > > > > > > > > > > > > - > > > > > > To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > > For information on digests or retrieving files and old messages > > send > > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > -- > > > > > ______________________________________________ > > > > > Alex Substanley Exodus Communications K.K. > > > > > Engineering Department > > > > > Das Man TEL: 81-3-5334-1700 > > > > > Systems Engineer FAX: 81-3-5334-1711 > > > > > ______________________________________________ > > > > > > > > > > - > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages > > send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > -- > > ______________________________________________ > > Alex Substanley Exodus Communications K.K. > > Engineering Department > > Das Man TEL: 81-3-5334-1700 > > Systems Engineer FAX: 81-3-5334-1711 > > ______________________________________________ > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) Strange syslog entries
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-19 19:51:39

Packet filters. "set packet_logging logging all packet_size 80" will show you more of the packet that it's dropping, but it'sa raw packet, and you'd have to decode the headers to figuree out what the source/destination IP addresses are. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Wed, 19 Jan 2000, Randy McMillan wrote: > Is there anyone who can tell me what these entries in my syslog mean and/or > how to prevent the hyper arc from sending them. Am running 4.1.59-6. > Usually there aren't all that many, but today it seemed to be going wild and > started affecting the mail server. I don't think I have any "Taps" going. > > Jan 19 11:56:14 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog > capture:stop > Jan 19 11:56:22 tc2 last message repeated 345 times > Jan 19 11:56:22 tc2 --syslog capture: ed1d0103 slot:4/mod:2 --syslog > capture:stop > Jan 19 11:56:22 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog > capture:stop > Jan 19 11:56:53 tc2 last message repeated 1282 times > Jan 19 11:57:53 tc2 last message repeated 2676 times > Jan 19 11:58:40 tc2 last message repeated 1539 times > Jan 19 11:59:43 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog > capture:stop > Jan 19 12:00:45 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog > capture:stop > > Thanks for any information. > > Randy McMillan > PacInfo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Backing up NMC and ARC configs
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-19 19:56:32

On Wed, 19 Jan 2000, Charles Sprickman wrote: > On Thu, 20 Jan 2000, Campbell Simpson wrote: > > > Hi all > > > > Just following on from the ARC tftp upload thread, does anyone have an cunning way to backup and restore the full config of an NMC or ARC card. > > Not to be an ass, but since I never found a way, I initially ran a script > of my first config and saved it out as a file. Whenever I make any > changes, I also make it to this file. So far, it's made configuring new > ARCs extremely easy... I do this too, but, it gets way out of sync with reality very quickly as soon as you log into the ARC and start tweaking things to work around problems. > Now of course a single config file like a Cisco has would be wonderful, as > it makes it super easy to back things up. Long ago I tftp'd down all the > files I could grab off the thing and really couldn't find a single file > with all settings... There is one, but it's binary. Look up "bulk configuration" in the docs, or use HARM to do it. There's no way that I know of to dump the config out in text like a Cisco does. Someone hinted a while ago that 3Com had such a tool internally... but I never got anyone to confirm the existence of something like that. Since I can't find one, I'm going to write one if nobody else fesses up and saves me the work. I've already started, but it's slow going, because I'm still trying to come up with an elegant data structure for mapping the command names to the SNMP OIDs that store the values without hardcoding every stupid verb into the program... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things."

Subject: Re: (usr-tc) Vendors of 3Com equipment?
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-19 19:57:15

Ditto, that's where we get ours... John Groh is our rep. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Wed, 19 Jan 2000, Richard Lorbieski wrote: > I deal with a different rep. , but it's a good company to do business > with. > > "Mark E. Levy" wrote: > > > > John DeDonato, Source Technology 888-765-5758 x2267 > > www.source-technology.com > > > > Mark Thornton wrote: > > > > > > I am looking for vendors of 3Com TCH equipment, primarily DSP's, selling new > > > or used equipment. If you know of reputable vendors please respond off-list > > > to mark@corridor.net. > > > > > > Thanks, > > > > > > Mark Thornton > > > San Marcos Internet, Inc. > > > 512-393-5300 > > > > -- > > --------------------------------------------------------------------- > > Mark E. Levy, President > > FSINet, Inc. > > 800-827-6085 x202 > > 847-753-6832 fax > > www.fsi.net > > mark@fsi.net > > --------------------------------------------------------------------- > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > > Richard Lorbieski - richard@alpha1.net > Chief Technical Officer - Senior System Administrator > Alpha1 Internet http://www.alpha1.net > 409.731.8236 - 877.4.alpha1 (877.425.7421) > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Vendors of 3Com equipment?
From: Kent Tambling <kent@acceleration.net>
Date: 2000-01-19 20:27:41

Wynde McMinn "The INTELLIGENT Choice for your Network" 1-877-TIC-INC1 2833 Villager Circle Pensacola, Fl 32504 850-476-8417 ext 100 voice 850-478-7886 fax wmcminn@ticinc.com ----- Original Message ----- Sent: Wednesday, January 19, 2000 4:00 PM I am looking for vendors of 3Com TCH equipment, primarily DSP's, selling new or used equipment. If you know of reputable vendors please respond off-list to mark@corridor.net. Thanks, Mark Thornton San Marcos Internet, Inc. 512-393-5300 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Backing up NMC and ARC configs
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-19 21:12:21

Thus spake Mike Andrews >Since I can't find one, I'm going to write one if nobody else fesses up >and saves me the work. I've already started, but it's slow going, because >I'm still trying to come up with an elegant data structure for mapping the >command names to the SNMP OIDs that store the values without hardcoding >every stupid verb into the program... Do you really need to convert it back to CLI format? Can you store it in a way that your tool could restore the config back automatically, or copy it over to another automatically? Personally, I think that would be even better than a CLI config tool...an SNMP config tool. Say...here's a template that I want all of my ports configured like...and let it go in and do all of them that way. Something like that would be even better IMHO. Still have to come up with a data structure to store that, but that should be rather more easy to do than a conversion to CLI commands. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) 1200 baud modems
From: eric@dol.net
Date: 2000-01-20 09:07:19

I have a bunch of quad modems that came in a chasis that I bought that I can only get 1200 baud connections on. I have reflashed the modems. Since all 4 modems on the card have the same results is the card bad? thanks eric

Subject: (usr-tc) Backing up NMC and ARC configs
From: Campbell Simpson <campbell.simpson@telecom.co.nz>
Date: 2000-01-20 10:44:13

Hi all Just following on from the ARC tftp upload thread, does anyone have an = cunning way to backup and restore the full config of an NMC or ARC = card.=20 Its a real pain if you have to swap out cards and re-configure the cards = manually. Cheers Campbell

Subject: Re: (usr-tc) Strange syslog entries
From: Randy McMillan <randy@pacinfo.com>
Date: 2000-01-20 10:50:55

Thanks. If packet logging was set to none and size 0, why would it be logging anything at all? (I am curious and not asking that so I can make it ignore this) Randy McMillan PacInfo ----- Original Message ----- Sent: Wednesday, January 19, 2000 4:51 PM > Packet filters. "set packet_logging logging all packet_size 80" will show > you more of the packet that it's dropping, but it'sa raw packet, and you'd > have to decode the headers to figuree out what the source/destination IP > addresses are. > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > "Don't sweat the petty things, and don't pet the sweaty things." > > On Wed, 19 Jan 2000, Randy McMillan wrote: > > > Is there anyone who can tell me what these entries in my syslog mean and/or > > how to prevent the hyper arc from sending them. Am running 4.1.59-6. > > Usually there aren't all that many, but today it seemed to be going wild and > > started affecting the mail server. I don't think I have any "Taps" going. > > > > Jan 19 11:56:14 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog > > capture:stop > > Jan 19 11:56:22 tc2 last message repeated 345 times > > Jan 19 11:56:22 tc2 --syslog capture: ed1d0103 slot:4/mod:2 --syslog > > capture:stop > > Jan 19 11:56:22 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog > > capture:stop > > Jan 19 11:56:53 tc2 last message repeated 1282 times > > Jan 19 11:57:53 tc2 last message repeated 2676 times > > Jan 19 11:58:40 tc2 last message repeated 1539 times > > Jan 19 11:59:43 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog > > capture:stop > > Jan 19 12:00:45 tc2 --syslog capture: a71a010a slot:11/mod:2 --syslog > > capture:stop > > > > Thanks for any information. > > > > Randy McMillan > > PacInfo > > > > >

Subject: RE: (usr-tc) Strange syslog entries
From: Kelly Peterson <netadmin@compusmart.ab.ca>
Date: 2000-01-20 11:50:26

We're seeing exactly the same thing and would be interested in knowing how to stop this. -----Original Message----- Sent: Thursday, January 20, 2000 11:42 AM Thanks. If packet logging was set to none and size 0, why would it be logging anything at all? (I am curious and not asking that so I can make it ignore this) Randy McMillan PacInfo ......

Subject: RE: (usr-tc) Backing up NMC and ARC configs
From: Ian Quinn <ianq@interconnect.co.nz>
Date: 2000-01-20 12:46:35

You could try HiPer ARC Manager (HARM) or the bulk configuration file facility. Some commands for the bulk config file approach: save configuration saves the configuration to a file (eg ConfigBulkFile) set bulk_file changes the bulk config file name reset configuration restores the config from the bulk file (eg after uploading) I recall that you need to do a reboot after restoring the config as reset config only loads it onto flash, and doesn't replace the working config (at least on 4.1.x). Doing a save all will overwrite the flash config with the config in memory (eg if you want to undo a reset, do a save all). TFTP can be used to shift the file on and off the HARC flash. It's a binary file, so use the binary mode. It would be best to try it all out before you need it :-) Regards Ian Quinn InterConnect Ltd Phone: (64 4) 494 1144 Fax: (64 4) 494 1140 Mobile: (64 25) 2477 608 Street: Level 2, 5-7 Willeston Street, Wellington Postal: PO Box 5527, Lambton Quay, Wellington E.Mail: ianq@interconnect.co.nz http://www.interconnect.co.nz > -----Original Message----- > From: Charles Sprickman [SMTP:spork@inch.com] > Sent: Thursday, January 20, 2000 12:00 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Backing up NMC and ARC configs > > On Thu, 20 Jan 2000, Campbell Simpson wrote: > > > Hi all > > > > Just following on from the ARC tftp upload thread, does anyone have an > cunning way to backup and restore the full config of an NMC or ARC card. > > Not to be an ass, but since I never found a way, I initially ran a script > of my first config and saved it out as a file. Whenever I make any > changes, I also make it to this file. So far, it's made configuring new > ARCs extremely easy... > > Now of course a single config file like a Cisco has would be wonderful, as > it makes it super easy to back things up. Long ago I tftp'd down all the > files I could grab off the thing and really couldn't find a single file > with all settings... > > Charles > > > Its a real pain if you have to swap out cards and re-configure the cards > manually. > > > > Cheers > > > > Campbell > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Other server options?
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-20 14:04:23

Is anyone using another access server such as Ascend/Lucent to gain a wider range of modem compatibility, or is that just marketing hype? I can't tell if the local providers with the other equipment are having the same connection problems the 3Com's typically experience, or if they are different types of client modems. Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: RE: (usr-tc) Modems still hang!
From: Gorkem Yuksel <gorkem@gncom.com>
Date: 2000-01-20 14:39:58

Hi! I 've been running ARC 4.1.59.6 NMC 6.1.17 DSP 2.0.81 since last August and had same problems(pair modems hang) 6 or 7 times. But This year, it happened 4 times for 10 days....I had to do reseat it everytime. I e-mailed and contacted my original supplier and 3 Com but...no answer....except for sales lady's call asking an expensive support contract which I cannot afford. I have only 2 modem cards and my customer calls right away when it start hang by pair. Can anyone send me ARC 4.2.32 code by e-mail? I can receive up tp 4 meg. Please send it to gorkem@gncom.com and ken@gncom.com... one is in NT and the other is in Win 95 machine. Thanks... Gorkem,,,Ken. gorkem@gncom.com Globenet

Subject: RE: (usr-tc) Modems still hang!
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-20 15:05:24

On Thu, 20 Jan 2000, Gorkem Yuksel wrote: [...] > since last August and had same problems(pair modems hang) 6 or 7 times. > But This year, it happened 4 times for 10 days....I had to do reseat it > everytime. That's what I'm experiencing. I'm running the SAME software on our HDSPs and HARC that I've run for OVER A YEAR now. I *never* had the stuck modem problem until recently (shown by my periodic gloating on this very list). I just find it terribly strange that I ran this code with the same config for over a year with no problems. Within a month of my service contract expiring, I start getting stuck modems, the frequency of which continues to increase...nowadays one of my cards won't even go for a single day after a reboot before getting a stuck modem pair. I just don't get it. Thing runs fine for a year of continous service, then starts getting stuck modems once every month and the frequency continues to rise until now when we get stuck modems once a day. Also interesting is that once a given card has a pair of stuck modems, it never seems to get another pair of stuck modems...it'll run for weeks with just one pair of stuck modems. In my case tho, it doesn't need to be reseated...just a hardware reboot (although I blanch at refering to a hardware reboot as 'just a'). At this point, I guess I'll have to go to the new code, although I'm still scared it won't play well with my (still old) code for the NMC and the TCMw. This rant sponsored by events of today. Card in slot15 had a pair of stuck modems...busied out for a couple of days. Got up this morning and it was returning fast busy for all calls. Poked around, the card was reporting (through TCM) *no problems*...nothing even looked odd on every display on TCM. Rebooted and everything was fine. Then, two hours later, a pair of modems got stuck again. ARRRGHHHHHH Lon Stockton

Subject: RE: (usr-tc) Modems still hang!
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-20 18:44:15

New ARC code won't help you with the stuck-modem-pair problem... you need new DSP code for that. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Thu, 20 Jan 2000, Gorkem Yuksel wrote: > Hi! > > I 've been running ARC 4.1.59.6 > NMC 6.1.17 > DSP 2.0.81 > since last August and had same problems(pair modems hang) 6 or 7 times. > But This year, it happened 4 times for 10 days....I had to do reseat it > everytime. I e-mailed and contacted my original supplier and 3 Com > but...no answer....except for sales lady's call asking an expensive support > contract which I cannot afford. > I have only 2 modem cards and my customer calls right away when it start > hang by pair. > > Can anyone send me ARC 4.2.32 code by e-mail? > I can receive up tp 4 meg. Please send it to gorkem@gncom.com and > ken@gncom.com... one is in NT and the other is in Win 95 machine.

Subject: (usr-tc) DSL
From: Laszlo Vecsey <master@internexus.net>
Date: 2000-01-21 02:57:34

What happened to the total control dsl card?

Subject: Re: (usr-tc) DSL
From: Brian Gordon <administrator@westelcom.com>
Date: 2000-01-21 07:03:35

It got discontinued which is like the worst choice 3com ever made. I have two ports of the dsl card running to customer premise and they run really sweet. I am looking for more , and need them so bad. Anyone got the ethernet versions viper/affinity card and modem sets for sale out there!!!!!!!!!!!!! Brian Gordon administrator@westelcom.com ----- Original Message ----- Sent: Friday, January 21, 2000 2:57 AM > What happened to the total control dsl card? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 2.0.60
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-21 09:22:06

Jason, We are running it on some of our machines. It's good code but we have problems sometimes with winmodems connecting to it. Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Tuesday, January 18, 2000 4:54 PM > I heard good reports the last time I made a stupid post like this. > So, I am posting once again. How many of you are using HiperDSP and > have had experiences with the 2.0.60 code for the DSPs? > > I would appreciate feedback. Thanks in advance > > > Jason A. Nunnelley > President of Linkfast Internet Services, > Linkfast Inc. 256-739-2008 VOICE CONTACT > > Linkfast Labs, GPN, MFG, MentionMe Studios, > and, the Stupid Project > http://www.linkfast.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) D Channel Problem
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-21 09:24:42

Jason, I have read somewhere that after so many cards (7 or 8), you need to add another gateway card. After so many DSP cards, the load gets overwhelming for only one gateway card so you have to add another. This might be the situation in your case. Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Wednesday, January 19, 2000 10:10 AM > I just installed our seventh Hiper DSP card into our chassis and the > Loopback/D-Alarm LED on this card keeps alternating between green and > red about every 30 seconds. I have this card set up exactly like the > other cards in this chassis and the telco (supposedly) has this span > setup the same way as all of our others. Does anyone have any insight > into what could be going on? > > Here are my specs: > > T1 PRI > Hiper DSP 2.0.81 > Hiper ARC 4.1.59-6 > Hiper NMC 6.1.17 > > Thanks in advance. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) To many drops after connect
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-21 10:40:41

hello all still fighting with TC to try and get decent connection performance out of the thing. flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some frighting stats: Total Calls (from radius): 66212 Calls of < 1 minute in length: 9266 Thats a 14% drop rate! It seems to hit some people in bulk... it they dial in 5-10 times and then they just give up. I tried to narrow it down to a specific slot/channel but thier dosen't seem to be a pattern. Anyone else seeing similiar results??? All circuits are PRI. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545

Subject: Re: (usr-tc) To many drops after connect
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-21 11:04:53

Paul, How did you find out this information on Total calls lost? Is it possible to find this out on the old Total Control equipment also? Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Friday, January 21, 2000 9:40 AM > hello all > > still fighting with TC to try and get decent connection performance out of > the thing. > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > frighting stats: > > Total Calls (from radius): 66212 > Calls of < 1 minute in length: 9266 > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > in 5-10 times and then they just give up. > > I tried to narrow it down to a specific slot/channel but thier dosen't > seem to be a pattern. > > Anyone else seeing similiar results??? All circuits are PRI. > > > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Quad v.34 Code 6.1.6
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-21 11:25:36

We've been running it for over a month now. We upgraded just about everything we could to the latest code over the past couple of months. We have not had a mass exodus of customers or a flood of calls thanking us for fixing any problems. It supposedly monitors the modems for problems better. I have not noticed much of an impact at all. We also changed the transmit level to 13 based upon some discussion here. I don't know that we've had much feedback since making that change. I guess it won't hurt to upgrade but don't expect anything dramatic. At 11:53 AM 1/21/00 -0600, you wrote: >What is the word on modem code 6.1.6 for Quad v.34 Single sided modems? Is >it worth installing? Does it fix some of the v.90 compatibility problems? >Is it better than the 5.10.9 code? Are there any problems I should know >about on the 6.1.6 code that people have been experiencing? > >Thanks in advance, >Bryan >NOC Technician >COX Internet > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) To many drops after connect
From: Brian <signal@shreve.net>
Date: 2000-01-21 11:27:28

I wrote a program that will grok syslog output for this info..........i posted it here many times On Fri, 21 Jan 2000, Clint R. Sparks wrote: > Paul, > > How are you checking this statistic? I would like to check mine as a > comparison. > > Thank you, > > Clint R. Sparks > ComQuest Internet Services > csparks@cqc.com > > > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 21, 2000 10:40 AM > Subject: (usr-tc) To many drops after connect > > > > hello all > > > > still fighting with TC to try and get decent connection performance out of > > the thing. > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > frighting stats: > > > > Total Calls (from radius): 66212 > > Calls of < 1 minute in length: 9266 > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > > in 5-10 times and then they just give up. > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > seem to be a pattern. > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) D Channel Problem
From: Jason P. <jjperc@petronet.net>
Date: 2000-01-21 11:37:56

I remember hearing about the number of DSP's to ARC limit, but I didn't think that would be causing the D channel on my 7th DSP to be going up and down continuously. I have another ARC card on hand, so I'll try to add that one and see what happens. Thanks for the tip. "The NOC (COX Internet)" wrote: > Jason, > > I have read somewhere that after so many cards (7 or 8), you need to add > another gateway card. After so many DSP cards, the load gets overwhelming > for only one gateway card so you have to add another. This might be the > situation in your case. > > Bryan > NOC Technician > COX Internet > > ----- Original Message ----- > From: "Jason P." <jjperc@petronet.net> > To: <usr-tc@lists.xmission.com> > Sent: Wednesday, January 19, 2000 10:10 AM > Subject: (usr-tc) D Channel Problem > > > I just installed our seventh Hiper DSP card into our chassis and the > > Loopback/D-Alarm LED on this card keeps alternating between green and > > red about every 30 seconds. I have this card set up exactly like the > > other cards in this chassis and the telco (supposedly) has this span > > setup the same way as all of our others. Does anyone have any insight > > into what could be going on? > > > > Here are my specs: > > > > T1 PRI > > Hiper DSP 2.0.81 > > Hiper ARC 4.1.59-6 > > Hiper NMC 6.1.17 > > > > Thanks in advance. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) To many drops after connect
From: Brian <signal@shreve.net>
Date: 2000-01-21 11:39:10

ftp ftp.shreve.net/pub/3Com/Scripts brian On Fri, 21 Jan 2000, The NOC (COX Internet) wrote: > Paul, > > I am a new subscriber to this mailing list. If you would, please repost it. > > Thank you, > Bryan > NOC Technician > COX Internet > > > ----- Original Message ----- > From: "Brian" <signal@shreve.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 21, 2000 11:27 AM > Subject: Re: (usr-tc) To many drops after connect > > > > > > I wrote a program that will grok syslog output for this info..........i > > posted it here many times > > > > On Fri, 21 Jan 2000, Clint R. Sparks wrote: > > > > > Paul, > > > > > > How are you checking this statistic? I would like to check mine as a > > > comparison. > > > > > > Thank you, > > > > > > Clint R. Sparks > > > ComQuest Internet Services > > > csparks@cqc.com > > > > > > > > > ----- Original Message ----- > > > From: "Paul Farber" <farber@admin.f-tech.net> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Friday, January 21, 2000 10:40 AM > > > Subject: (usr-tc) To many drops after connect > > > > > > > > > > hello all > > > > > > > > still fighting with TC to try and get decent connection performance > out of > > > > the thing. > > > > > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > > > frighting stats: > > > > > > > > Total Calls (from radius): 66212 > > > > Calls of < 1 minute in length: 9266 > > > > > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they > dial > > > > in 5-10 times and then they just give up. > > > > > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > > > seem to be a pattern. > > > > > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > > > > > > > > > Paul Farber > > > > Farber Technology > > > > farber@admin.f-tech.net > > > > Ph 570-628-5303 > > > > Fax 570-628-5545 > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) D Channel Problem
From: Brian <signal@shreve.net>
Date: 2000-01-21 11:39:56

didn't they fix a problem like that in the new dsp code? might want to upgrade your dsp code. Brian On Fri, 21 Jan 2000, Jason P. wrote: > I remember hearing about the number of DSP's to ARC limit, but I didn't think > that would be causing the D channel on my 7th DSP to be going up and down > continuously. I have another ARC card on hand, so I'll try to add that one > and see what happens. Thanks for the tip. > > > "The NOC (COX Internet)" wrote: > > > Jason, > > > > I have read somewhere that after so many cards (7 or 8), you need to add > > another gateway card. After so many DSP cards, the load gets overwhelming > > for only one gateway card so you have to add another. This might be the > > situation in your case. > > > > Bryan > > NOC Technician > > COX Internet > > > > ----- Original Message ----- > > From: "Jason P." <jjperc@petronet.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Wednesday, January 19, 2000 10:10 AM > > Subject: (usr-tc) D Channel Problem > > > > > I just installed our seventh Hiper DSP card into our chassis and the > > > Loopback/D-Alarm LED on this card keeps alternating between green and > > > red about every 30 seconds. I have this card set up exactly like the > > > other cards in this chassis and the telco (supposedly) has this span > > > setup the same way as all of our others. Does anyone have any insight > > > into what could be going on? > > > > > > Here are my specs: > > > > > > T1 PRI > > > Hiper DSP 2.0.81 > > > Hiper ARC 4.1.59-6 > > > Hiper NMC 6.1.17 > > > > > > Thanks in advance. > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) State of the Hub followup
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-21 11:43:12

The real question for 3Com is why they don't want our money? They are losing support $ because there support plan is unworkable and too damned expensive. If they had a workable plan that was affordable then I suspect they would have a very large take rate among their customers. It begs the question of whether they really want to support the product at all, as they are INTENTIONALLY limiting the number support customers. Seems to me like we need to reach the right person at 3Com who would like to rack up some easy sales $ to change the plan. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Friday, January 21, 2000 11:40 AM > Well, I've gotten answers concerning the state of support contract rules > for Total Control equipment. > > Support is still purchased on a per-chassis basis, with surcharges for > having more than a certain number of ports in the chassis, and its still > required to have the same support coverage on all chassis within a > single site. These are the exact same support contract rules that have > driven many of us to stop carrying coverage of our TC chassis, and rely > on our own wits, and resellers. I think this speaks very poorly of > 3Com that, after two to three years, these issues still have not been > addressed at all! > > I still fail to understand why support is required to be done on a > per-chassis basis when it would actually be *easier* to do it on a > per-card basis. Serial numbers for individual cards are easily > retrieved via SNMP/TCM from the chassis, serial numbers for the chassis > requires copying the number off a barcode label physically applied to > the chassis. Serial numbers are already tracked on a per-card number by > 3Com (witnessed by the ability to sign up for warranty coverage of > equipment on a per-card level on the totalservice web site by entering > the serial number of the individual card). I still fail to understand > why 3Com requires equal coverage on all equipment in a location (this > was stated as being on a single site...our past experience indicates > that 3Com will not live up to this statement), I also fail to understand > why 3Com requires equal levels of coverage on all the different *types* > of equipment in a location. I don't think it takes a genius to realize > that a quad card failing and taking 4 ports out of service is > considerably less critical than a HiPer Arc failing and taking up to 300 > (or more) ports out of service. > > I invite 3Com to share thier reasoning for these support contract rules, > and especially invite 3Com to rectify the problems as they currently > exist. I hope solutions presented will be substantive solutions, not > someone calling me to once again explain what the support coverage > options that currently exist are. I've been through that many times, > explaining it again isn't going to solve the problems. > > I would be interested in hearing what the "unbundled service" offerings > shown on 3Com's web site are about > (http://support.3com.com/infodeli/services/index.htm). The individual I > spoke with (who was very personable) indicated that unbundled services > indicated on that web page are *not* available for the Total Control > equipment. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) To many drops after connect
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-21 11:43:48

Paul, I am a new subscriber to this mailing list. If you would, please repost it. Thank you, Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Friday, January 21, 2000 11:27 AM > > I wrote a program that will grok syslog output for this info..........i > posted it here many times > > On Fri, 21 Jan 2000, Clint R. Sparks wrote: > > > Paul, > > > > How are you checking this statistic? I would like to check mine as a > > comparison. > > > > Thank you, > > > > Clint R. Sparks > > ComQuest Internet Services > > csparks@cqc.com > > > > > > ----- Original Message ----- > > From: "Paul Farber" <farber@admin.f-tech.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Friday, January 21, 2000 10:40 AM > > Subject: (usr-tc) To many drops after connect > > > > > > > hello all > > > > > > still fighting with TC to try and get decent connection performance out of > > > the thing. > > > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > > frighting stats: > > > > > > Total Calls (from radius): 66212 > > > Calls of < 1 minute in length: 9266 > > > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > > > in 5-10 times and then they just give up. > > > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > > seem to be a pattern. > > > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > > > > > Paul Farber > > > Farber Technology > > > farber@admin.f-tech.net > > > Ph 570-628-5303 > > > Fax 570-628-5545 > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Quad v.34 Code 6.1.6
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-21 11:53:56

What is the word on modem code 6.1.6 for Quad v.34 Single sided modems? Is it worth installing? Does it fix some of the v.90 compatibility problems? Is it better than the 5.10.9 code? Are there any problems I should know about on the 6.1.6 code that people have been experiencing? Thanks in advance, Bryan NOC Technician COX Internet

Subject: Re: (usr-tc) To many drops after connect
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-21 11:58:57

This might not be the case in your situation since you say the same user dials many times in a row, but just because a call has less than a minute of connect time doesn't necessarily mean that it is a failed call. If your customers are set to automatically connect/check Email/drop as with AOL FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A misconfigured dial-on-demand connection might account for it as well, as might a user not satisfied with 44K and trying for that 53K connection. If there was a large jump in the percentage of short calls after changing codes that might be another story though. You might want to also look at some of your other accounting data, such as Do these session stops have normal disconnect reasons? Did the user get assigned a valid IP? Was any data passed on the sessions? Steve "The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM Please respond to usr-tc@lists.xmission.com Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> cc: (Steve Valiunas/MW/US/3Com) Paul, How did you find out this information on Total calls lost? Is it possible to find this out on the old Total Control equipment also? Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Friday, January 21, 2000 9:40 AM > hello all > > still fighting with TC to try and get decent connection performance out of > the thing. > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > frighting stats: > > Total Calls (from radius): 66212 > Calls of < 1 minute in length: 9266 > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > in 5-10 times and then they just give up. > > I tried to narrow it down to a specific slot/channel but thier dosen't > seem to be a pattern. > > Anyone else seeing similiar results??? All circuits are PRI. > > > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) To many drops after connect
From: Clint R. Sparks <csparks@cqc.com>
Date: 2000-01-21 12:03:18

Paul, How are you checking this statistic? I would like to check mine as a comparison. Thank you, Clint R. Sparks ComQuest Internet Services csparks@cqc.com ----- Original Message ----- Sent: Friday, January 21, 2000 10:40 AM > hello all > > still fighting with TC to try and get decent connection performance out of > the thing. > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > frighting stats: > > Total Calls (from radius): 66212 > Calls of < 1 minute in length: 9266 > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > in 5-10 times and then they just give up. > > I tried to narrow it down to a specific slot/channel but thier dosen't > seem to be a pattern. > > Anyone else seeing similiar results??? All circuits are PRI. > > > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) State of the Hub followup
From: Brian <signal@shreve.net>
Date: 2000-01-21 12:24:26

nod, and those of us who have not had support contracts for years, would probably be using less support than those who are paying them now........ Brian On Fri, 21 Jan 2000, Mark Thornton wrote: > The real question for 3Com is why they don't want our money? They are losing > support $ because there support plan is unworkable and too damned expensive. > If they had a workable plan that was affordable then I suspect they would > have a very large take rate among their customers. It begs the question of > whether they really want to support the product at all, as they are > INTENTIONALLY limiting the number support customers. Seems to me like we > need to reach the right person at 3Com who would like to rack up some easy > sales $ to change the plan. > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 > > > ----- Original Message ----- > From: Jeff Mcadams <jeffm@iglou.com> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 21, 2000 11:40 AM > Subject: (usr-tc) State of the Hub followup > > > > Well, I've gotten answers concerning the state of support contract rules > > for Total Control equipment. > > > > Support is still purchased on a per-chassis basis, with surcharges for > > having more than a certain number of ports in the chassis, and its still > > required to have the same support coverage on all chassis within a > > single site. These are the exact same support contract rules that have > > driven many of us to stop carrying coverage of our TC chassis, and rely > > on our own wits, and resellers. I think this speaks very poorly of > > 3Com that, after two to three years, these issues still have not been > > addressed at all! > > > > I still fail to understand why support is required to be done on a > > per-chassis basis when it would actually be *easier* to do it on a > > per-card basis. Serial numbers for individual cards are easily > > retrieved via SNMP/TCM from the chassis, serial numbers for the chassis > > requires copying the number off a barcode label physically applied to > > the chassis. Serial numbers are already tracked on a per-card number by > > 3Com (witnessed by the ability to sign up for warranty coverage of > > equipment on a per-card level on the totalservice web site by entering > > the serial number of the individual card). I still fail to understand > > why 3Com requires equal coverage on all equipment in a location (this > > was stated as being on a single site...our past experience indicates > > that 3Com will not live up to this statement), I also fail to understand > > why 3Com requires equal levels of coverage on all the different *types* > > of equipment in a location. I don't think it takes a genius to realize > > that a quad card failing and taking 4 ports out of service is > > considerably less critical than a HiPer Arc failing and taking up to 300 > > (or more) ports out of service. > > > > I invite 3Com to share thier reasoning for these support contract rules, > > and especially invite 3Com to rectify the problems as they currently > > exist. I hope solutions presented will be substantive solutions, not > > someone calling me to once again explain what the support coverage > > options that currently exist are. I've been through that many times, > > explaining it again isn't going to solve the problems. > > > > I would be interested in hearing what the "unbundled service" offerings > > shown on 3Com's web site are about > > (http://support.3com.com/infodeli/services/index.htm). The individual I > > spoke with (who was very personable) indicated that unbundled services > > indicated on that web page are *not* available for the Total Control > > equipment. > > -- > > Jeff McAdams Email: jeffm@iglou.com > > Head Network Administrator Voice: (502) 966-3848 > > IgLou Internet Services (800) 436-4456 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) To many drops after connect
From: Brian <signal@shreve.net>
Date: 2000-01-21 12:25:52

You all using 3Com Total Control NAS's over there at Nortel Networks? :) Brian On Fri, 21 Jan 2000, Alan Martin wrote: > Every once in awhile sanity reigns. > > > At 11:58 AM 1/21/2000 -0600, Steve Valiunas wrote: > > > > > > This might not be the case in your situation since you say the same user > >dials many times in a row, but just because a call has less than a minute of > >connect time doesn't necessarily mean that it is a failed call. If your > >customers are set to automatically connect/check Email/drop as with AOL > >FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A > misconfigured > >dial-on-demand connection might account for it as well, as might a user not > >satisfied with 44K and trying for that 53K connection. If there was a large > >jump in the percentage of short calls after changing codes that might be > another > >story though. You might want to also look at some of your other accounting > >data, such as Do these session stops have normal disconnect reasons? Did > the > >user get assigned a valid IP? Was any data passed on the sessions? > > > > > >Steve > > > > > > > > > > > > > >"The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM > > > >Please respond to usr-tc@lists.xmission.com > > > >Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> > > > > > >To: usr-tc@lists.xmission.com > >cc: (Steve Valiunas/MW/US/3Com) > >Subject: Re: (usr-tc) To many drops after connect > > > > > > > >Paul, > > > >How did you find out this information on Total calls lost? Is it possible > >to find this out on the old Total Control equipment also? > > > >Bryan > >NOC Technician > >COX Internet > > > > > >----- Original Message ----- > >From: "Paul Farber" <farber@admin.f-tech.net> > >To: <usr-tc@lists.xmission.com> > >Sent: Friday, January 21, 2000 9:40 AM > >Subject: (usr-tc) To many drops after connect > > > > > >> hello all > >> > >> still fighting with TC to try and get decent connection performance out of > >> the thing. > >> > >> flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > >> frighting stats: > >> > >> Total Calls (from radius): 66212 > >> Calls of < 1 minute in length: 9266 > >> > >> Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > >> in 5-10 times and then they just give up. > >> > >> I tried to narrow it down to a specific slot/channel but thier dosen't > >> seem to be a pattern. > >> > >> Anyone else seeing similiar results??? All circuits are PRI. > >> > >> > >> > >> Paul Farber > >> Farber Technology > >> farber@admin.f-tech.net > >> Ph 570-628-5303 > >> Fax 570-628-5545 > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: (usr-tc) State of the Hub followup
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-21 12:40:04

Well, I've gotten answers concerning the state of support contract rules for Total Control equipment. Support is still purchased on a per-chassis basis, with surcharges for having more than a certain number of ports in the chassis, and its still required to have the same support coverage on all chassis within a single site. These are the exact same support contract rules that have driven many of us to stop carrying coverage of our TC chassis, and rely on our own wits, and resellers. I think this speaks very poorly of 3Com that, after two to three years, these issues still have not been addressed at all! I still fail to understand why support is required to be done on a per-chassis basis when it would actually be *easier* to do it on a per-card basis. Serial numbers for individual cards are easily retrieved via SNMP/TCM from the chassis, serial numbers for the chassis requires copying the number off a barcode label physically applied to the chassis. Serial numbers are already tracked on a per-card number by 3Com (witnessed by the ability to sign up for warranty coverage of equipment on a per-card level on the totalservice web site by entering the serial number of the individual card). I still fail to understand why 3Com requires equal coverage on all equipment in a location (this was stated as being on a single site...our past experience indicates that 3Com will not live up to this statement), I also fail to understand why 3Com requires equal levels of coverage on all the different *types* of equipment in a location. I don't think it takes a genius to realize that a quad card failing and taking 4 ports out of service is considerably less critical than a HiPer Arc failing and taking up to 300 (or more) ports out of service. I invite 3Com to share thier reasoning for these support contract rules, and especially invite 3Com to rectify the problems as they currently exist. I hope solutions presented will be substantive solutions, not someone calling me to once again explain what the support coverage options that currently exist are. I've been through that many times, explaining it again isn't going to solve the problems. I would be interested in hearing what the "unbundled service" offerings shown on 3Com's web site are about (http://support.3com.com/infodeli/services/index.htm). The individual I spoke with (who was very personable) indicated that unbundled services indicated on that web page are *not* available for the Total Control equipment. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) To many drops after connect
From: Brian <signal@shreve.net>
Date: 2000-01-21 13:03:38

On Fri, 21 Jan 2000, Alan Martin wrote: > I have TC, Ascend maxen, cisco, portmaster3, 5399/8000(oldbay) CVX, > Looking for new LU! > I got a BIG LAB! thats good, hopefully 3com has a big lab too, testing a bunch of client modems against their code :). And of course the equipment you have found work best in your lab is the nortel stuff right? :) Brian > Alan > > > At 12:25 PM 1/21/2000 -0600, Brian wrote: > > > >You all using 3Com Total Control NAS's over there at Nortel Networks? :) > > > >Brian > > > > > >On Fri, 21 Jan 2000, Alan Martin wrote: > > > >> Every once in awhile sanity reigns. > >> > >> > >> At 11:58 AM 1/21/2000 -0600, Steve Valiunas wrote: > >> > > >> > > >> > This might not be the case in your situation since you say the > same user > >> >dials many times in a row, but just because a call has less than a > minute of > >> >connect time doesn't necessarily mean that it is a failed call. If your > >> >customers are set to automatically connect/check Email/drop as with AOL > >> >FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A > >> misconfigured > >> >dial-on-demand connection might account for it as well, as might a > user not > >> >satisfied with 44K and trying for that 53K connection. If there was a > large > >> >jump in the percentage of short calls after changing codes that might be > >> another > >> >story though. You might want to also look at some of your other > accounting > >> >data, such as Do these session stops have normal disconnect reasons? Did > >> the > >> >user get assigned a valid IP? Was any data passed on the sessions? > >> > > >> > > >> >Steve > >> > > >> > > >> > > >> > > >> > > >> > > >> >"The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM > >> > > >> >Please respond to usr-tc@lists.xmission.com > >> > > >> >Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> > >> > > >> > > >> >To: usr-tc@lists.xmission.com > >> >cc: (Steve Valiunas/MW/US/3Com) > >> >Subject: Re: (usr-tc) To many drops after connect > >> > > >> > > >> > > >> >Paul, > >> > > >> >How did you find out this information on Total calls lost? Is it possible > >> >to find this out on the old Total Control equipment also? > >> > > >> >Bryan > >> >NOC Technician > >> >COX Internet > >> > > >> > > >> >----- Original Message ----- > >> >From: "Paul Farber" <farber@admin.f-tech.net> > >> >To: <usr-tc@lists.xmission.com> > >> >Sent: Friday, January 21, 2000 9:40 AM > >> >Subject: (usr-tc) To many drops after connect > >> > > >> > > >> >> hello all > >> >> > >> >> still fighting with TC to try and get decent connection performance > out of > >> >> the thing. > >> >> > >> >> flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > >> >> frighting stats: > >> >> > >> >> Total Calls (from radius): 66212 > >> >> Calls of < 1 minute in length: 9266 > >> >> > >> >> Thats a 14% drop rate! It seems to hit some people in bulk... it they > dial > >> >> in 5-10 times and then they just give up. > >> >> > >> >> I tried to narrow it down to a specific slot/channel but thier dosen't > >> >> seem to be a pattern. > >> >> > >> >> Anyone else seeing similiar results??? All circuits are PRI. > >> >> > >> >> > >> >> > >> >> Paul Farber > >> >> Farber Technology > >> >> farber@admin.f-tech.net > >> >> Ph 570-628-5303 > >> >> Fax 570-628-5545 > >> >> > >> >> > >> >> - > >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> >> with "unsubscribe usr-tc" in the body of the message. > >> >> For information on digests or retrieving files and old messages send > >> >> "help" to the same address. Do not use quotes in your message. > >> >> > >> > > >> > > >> >- > >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> > with "unsubscribe usr-tc" in the body of the message. > >> > For information on digests or retrieving files and old messages send > >> > "help" to the same address. Do not use quotes in your message. > >> > > >> > > >> > > >> > > >> > > >> >- > >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> > with "unsubscribe usr-tc" in the body of the message. > >> > For information on digests or retrieving files and old messages send > >> > "help" to the same address. Do not use quotes in your message. > >> > > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > >----------------------------------------------------- > >Brian Feeny (BF304) signal@shreve.net > >318-222-2638 x 109 http://www.shreve.net/~signal > >Network Administrator ShreveNet Inc. (ASN 11881) > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) To many drops after connect
From: Alan Martin <alamarti@nortelnetworks.com>
Date: 2000-01-21 13:16:13

Every once in awhile sanity reigns. At 11:58 AM 1/21/2000 -0600, Steve Valiunas wrote: > > > This might not be the case in your situation since you say the same user >dials many times in a row, but just because a call has less than a minute of >connect time doesn't necessarily mean that it is a failed call. If your >customers are set to automatically connect/check Email/drop as with AOL >FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A misconfigured >dial-on-demand connection might account for it as well, as might a user not >satisfied with 44K and trying for that 53K connection. If there was a large >jump in the percentage of short calls after changing codes that might be another >story though. You might want to also look at some of your other accounting >data, such as Do these session stops have normal disconnect reasons? Did the >user get assigned a valid IP? Was any data passed on the sessions? > > >Steve > > > > > > >"The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM > >Please respond to usr-tc@lists.xmission.com > >Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> > > >To: usr-tc@lists.xmission.com >cc: (Steve Valiunas/MW/US/3Com) >Subject: Re: (usr-tc) To many drops after connect > > > >Paul, > >How did you find out this information on Total calls lost? Is it possible >to find this out on the old Total Control equipment also? > >Bryan >NOC Technician >COX Internet > > >----- Original Message ----- >From: "Paul Farber" <farber@admin.f-tech.net> >To: <usr-tc@lists.xmission.com> >Sent: Friday, January 21, 2000 9:40 AM >Subject: (usr-tc) To many drops after connect > > >> hello all >> >> still fighting with TC to try and get decent connection performance out of >> the thing. >> >> flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some >> frighting stats: >> >> Total Calls (from radius): 66212 >> Calls of < 1 minute in length: 9266 >> >> Thats a 14% drop rate! It seems to hit some people in bulk... it they dial >> in 5-10 times and then they just give up. >> >> I tried to narrow it down to a specific slot/channel but thier dosen't >> seem to be a pattern. >> >> Anyone else seeing similiar results??? All circuits are PRI. >> >> >> >> Paul Farber >> Farber Technology >> farber@admin.f-tech.net >> Ph 570-628-5303 >> Fax 570-628-5545 >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) T1 PRI code
From: Brian <signal@shreve.net>
Date: 2000-01-21 13:35:36

On Fri, 21 Jan 2000, The NOC (COX Internet) wrote: > Howdy Brian, > > Do you know where I might be able to download the T1-PRI code version 3.1.5? > Any help would be greatly appreciated. www.totalservice.com? (not trying to be sarcastic)...........if I ran dual pri card, I might be able to offer you a, ahem, alternate location, but I do not, so sorry :) Brian > > Thanks, > Bryan > NOC Technician > COX Internet > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) To many drops after connect
From: Brian <signal@shreve.net>
Date: 2000-01-21 13:36:06

On Fri, 21 Jan 2000, Alan Martin wrote: > Absolutely! thats what I figured :) Brian > > > At 01:03 PM 1/21/2000 -0600, Brian wrote: > >On Fri, 21 Jan 2000, Alan Martin wrote: > > > >> I have TC, Ascend maxen, cisco, portmaster3, 5399/8000(oldbay) CVX, > >> Looking for new LU! > >> I got a BIG LAB! > > > >thats good, hopefully 3com has a big lab too, testing a bunch of client > >modems against their code :). And of course the equipment you have found > >work best in your lab is the nortel stuff right? :) > > > >Brian > > > > > >> Alan > >> > >> > >> At 12:25 PM 1/21/2000 -0600, Brian wrote: > >> > > >> >You all using 3Com Total Control NAS's over there at Nortel Networks? :) > >> > > >> >Brian > >> > > >> > > >> >On Fri, 21 Jan 2000, Alan Martin wrote: > >> > > >> >> Every once in awhile sanity reigns. > >> >> > >> >> > >> >> At 11:58 AM 1/21/2000 -0600, Steve Valiunas wrote: > >> >> > > >> >> > > >> >> > This might not be the case in your situation since you say the > >> same user > >> >> >dials many times in a row, but just because a call has less than a > >> minute of > >> >> >connect time doesn't necessarily mean that it is a failed call. If > your > >> >> >customers are set to automatically connect/check Email/drop as with AOL > >> >> >FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A > >> >> misconfigured > >> >> >dial-on-demand connection might account for it as well, as might a > >> user not > >> >> >satisfied with 44K and trying for that 53K connection. If there was a > >> large > >> >> >jump in the percentage of short calls after changing codes that > might be > >> >> another > >> >> >story though. You might want to also look at some of your other > >> accounting > >> >> >data, such as Do these session stops have normal disconnect > reasons? Did > >> >> the > >> >> >user get assigned a valid IP? Was any data passed on the sessions? > >> >> > > >> >> > > >> >> >Steve > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >"The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM > >> >> > > >> >> >Please respond to usr-tc@lists.xmission.com > >> >> > > >> >> >Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> > >> >> > > >> >> > > >> >> >To: usr-tc@lists.xmission.com > >> >> >cc: (Steve Valiunas/MW/US/3Com) > >> >> >Subject: Re: (usr-tc) To many drops after connect > >> >> > > >> >> > > >> >> > > >> >> >Paul, > >> >> > > >> >> >How did you find out this information on Total calls lost? Is it > possible > >> >> >to find this out on the old Total Control equipment also? > >> >> > > >> >> >Bryan > >> >> >NOC Technician > >> >> >COX Internet > >> >> > > >> >> > > >> >> >----- Original Message ----- > >> >> >From: "Paul Farber" <farber@admin.f-tech.net> > >> >> >To: <usr-tc@lists.xmission.com> > >> >> >Sent: Friday, January 21, 2000 9:40 AM > >> >> >Subject: (usr-tc) To many drops after connect > >> >> > > >> >> > > >> >> >> hello all > >> >> >> > >> >> >> still fighting with TC to try and get decent connection performance > >> out of > >> >> >> the thing. > >> >> >> > >> >> >> flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > >> >> >> frighting stats: > >> >> >> > >> >> >> Total Calls (from radius): 66212 > >> >> >> Calls of < 1 minute in length: 9266 > >> >> >> > >> >> >> Thats a 14% drop rate! It seems to hit some people in bulk... it they > >> dial > >> >> >> in 5-10 times and then they just give up. > >> >> >> > >> >> >> I tried to narrow it down to a specific slot/channel but thier > dosen't > >> >> >> seem to be a pattern. > >> >> >> > >> >> >> Anyone else seeing similiar results??? All circuits are PRI. > >> >> >> > >> >> >> > >> >> >> > >> >> >> Paul Farber > >> >> >> Farber Technology > >> >> >> farber@admin.f-tech.net > >> >> >> Ph 570-628-5303 > >> >> >> Fax 570-628-5545 > >> >> >> > >> >> >> > >> >> >> - > >> >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> >> >> with "unsubscribe usr-tc" in the body of the message. > >> >> >> For information on digests or retrieving files and old messages send > >> >> >> "help" to the same address. Do not use quotes in your message. > >> >> >> > >> >> > > >> >> > > >> >> >- > >> >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> >> > with "unsubscribe usr-tc" in the body of the message. > >> >> > For information on digests or retrieving files and old messages send > >> >> > "help" to the same address. Do not use quotes in your message. > >> >> > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> >- > >> >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> >> > with "unsubscribe usr-tc" in the body of the message. > >> >> > For information on digests or retrieving files and old messages send > >> >> > "help" to the same address. Do not use quotes in your message. > >> >> > > >> >> > >> >> - > >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> >> with "unsubscribe usr-tc" in the body of the message. > >> >> For information on digests or retrieving files and old messages send > >> >> "help" to the same address. Do not use quotes in your message. > >> >> > >> > > >> >----------------------------------------------------- > >> >Brian Feeny (BF304) signal@shreve.net > >> >318-222-2638 x 109 http://www.shreve.net/~signal > >> >Network Administrator ShreveNet Inc. (ASN 11881) > >> > > >> > > >> >- > >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> > with "unsubscribe usr-tc" in the body of the message. > >> > For information on digests or retrieving files and old messages send > >> > "help" to the same address. Do not use quotes in your message. > >> > > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > >----------------------------------------------------- > >Brian Feeny (BF304) signal@shreve.net > >318-222-2638 x 109 http://www.shreve.net/~signal > >Network Administrator ShreveNet Inc. (ASN 11881) > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: (usr-tc) T1 PRI code
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-21 13:36:48

Howdy Brian, Do you know where I might be able to download the T1-PRI code version 3.1.5? Any help would be greatly appreciated. Thanks, Bryan NOC Technician COX Internet

Subject: Re: (usr-tc) To many drops after connect
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-21 13:38:18

What are the disconnect reasons, though? Some people really do have a lot of < 1 minute calls -- those trying to just pick mail up and log off, for example... we see that a lot. We can tell them apart from people having problems by looking for the disconnect reason. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Fri, 21 Jan 2000, Paul Farber wrote: > hello all > > still fighting with TC to try and get decent connection performance out of > the thing. > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > frighting stats: > > Total Calls (from radius): 66212 > Calls of < 1 minute in length: 9266 > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > in 5-10 times and then they just give up. > > I tried to narrow it down to a specific slot/channel but thier dosen't > seem to be a pattern. > > Anyone else seeing similiar results??? All circuits are PRI. > > > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Backing up NMC and ARC configs
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-21 13:41:10

On Wed, 19 Jan 2000, Jeff Mcadams wrote: > Thus spake Mike Andrews > >Since I can't find one, I'm going to write one if nobody else fesses up > >and saves me the work. I've already started, but it's slow going, because > >I'm still trying to come up with an elegant data structure for mapping the > >command names to the SNMP OIDs that store the values without hardcoding > >every stupid verb into the program... > > Do you really need to convert it back to CLI format? Can you store it > in a way that your tool could restore the config back automatically, or > copy it over to another automatically? Personally, I think that would > be even better than a CLI config tool...an SNMP config tool. > Say...here's a template that I want all of my ports configured > like...and let it go in and do all of them that way. Something like > that would be even better IMHO. Still have to come up with a data > structure to store that, but that should be rather more easy to do than > a conversion to CLI commands. Well, it doesn't HAVE to be in CLI format, it'd just be nice. :) Just dumping a config in *any* kind of text format so you could at least diff it against another config would be handy. And that much I could do with just a bunch of snmpwalk commands. Sounds like you're talking about making it work like my 'checkusrcfg.pl' script does, which configures everything in the box except for the ARC. I could probably just throw ARC config data into that, using the SNMP proxying thing, though of course that'd be a lot slower than just doing it directly. That doesn't deal with tables all that well, and the code's already pretty ugly. :) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things."

Subject: (usr-tc) Limiting Connect Rate
From: Erri-Wibowo <erri@idola.net.id>
Date: 2000-01-21 13:53:26

Hai, We have USR Netserver 3.5 with Livingston RADIUS 2.1. We want to limiting connection rate for certain group of user through RADIUS. Unfortunately, we fail because RADIUS need to get connect-info attribute from USR. How to enable USR so it can send Connect-Info attribute to RADIUS server ? Any comments would be great. tx Erri Wibowo

Subject: RE: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG
From: Greg Long <greg@coastlink.com>
Date: 2000-01-21 14:05:58

There are some scripts located in the TCH subdirectory under the CONTRIB directory, inder the MRTG root directory. Email me off list and I will help you out if you have questions. -Greg greg@coastlink.com -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Network Administrator Sent: Friday, January 21, 2000 1:20 PM I read about setting up the TCH on MRTG. I would like to set this up but not sure where to look for the what was mentioned below. Where to do I go for these? cheryl ----- Original Message ----- Sent: Wednesday, January 12, 2000 12:41 PM > you should be able to use Eric Billeters scripts that come with MRTG in the > contrib directory under TCH ( I am still using MRTG2.7.2- so these may have > changed) > > works like a dream. > > steve > > --On Wednesday, January 12, 2000 10:37 AM -0700 Greg Long > <greg@coastlink.com> wrote: > > > I want to setup MRTG to monitor modem usage on my TC hub, I have the MIB's > > that come with the USR Suite Management Software. Can I use these MIB's > > or do I need to get other MIB's? > > > > Thanks, > > Greg Long > > Tech Support > > Coastlink > > 801-532-6212 ext 32 > > techsupp@coastlink.com > > http://www.coastlink.com > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > Steve McConnell > EMJI > 919-303-3217x126 > 888-258-8959 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) To many drops after connect
From: Alan Martin <alamarti@nortelnetworks.com>
Date: 2000-01-21 14:06:14

I have TC, Ascend maxen, cisco, portmaster3, 5399/8000(oldbay) CVX, Looking for new LU! I got a BIG LAB! Alan At 12:25 PM 1/21/2000 -0600, Brian wrote: > >You all using 3Com Total Control NAS's over there at Nortel Networks? :) > >Brian > > >On Fri, 21 Jan 2000, Alan Martin wrote: > >> Every once in awhile sanity reigns. >> >> >> At 11:58 AM 1/21/2000 -0600, Steve Valiunas wrote: >> > >> > >> > This might not be the case in your situation since you say the same user >> >dials many times in a row, but just because a call has less than a minute of >> >connect time doesn't necessarily mean that it is a failed call. If your >> >customers are set to automatically connect/check Email/drop as with AOL >> >FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A >> misconfigured >> >dial-on-demand connection might account for it as well, as might a user not >> >satisfied with 44K and trying for that 53K connection. If there was a large >> >jump in the percentage of short calls after changing codes that might be >> another >> >story though. You might want to also look at some of your other accounting >> >data, such as Do these session stops have normal disconnect reasons? Did >> the >> >user get assigned a valid IP? Was any data passed on the sessions? >> > >> > >> >Steve >> > >> > >> > >> > >> > >> > >> >"The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM >> > >> >Please respond to usr-tc@lists.xmission.com >> > >> >Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> >> > >> > >> >To: usr-tc@lists.xmission.com >> >cc: (Steve Valiunas/MW/US/3Com) >> >Subject: Re: (usr-tc) To many drops after connect >> > >> > >> > >> >Paul, >> > >> >How did you find out this information on Total calls lost? Is it possible >> >to find this out on the old Total Control equipment also? >> > >> >Bryan >> >NOC Technician >> >COX Internet >> > >> > >> >----- Original Message ----- >> >From: "Paul Farber" <farber@admin.f-tech.net> >> >To: <usr-tc@lists.xmission.com> >> >Sent: Friday, January 21, 2000 9:40 AM >> >Subject: (usr-tc) To many drops after connect >> > >> > >> >> hello all >> >> >> >> still fighting with TC to try and get decent connection performance out of >> >> the thing. >> >> >> >> flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some >> >> frighting stats: >> >> >> >> Total Calls (from radius): 66212 >> >> Calls of < 1 minute in length: 9266 >> >> >> >> Thats a 14% drop rate! It seems to hit some people in bulk... it they dial >> >> in 5-10 times and then they just give up. >> >> >> >> I tried to narrow it down to a specific slot/channel but thier dosen't >> >> seem to be a pattern. >> >> >> >> Anyone else seeing similiar results??? All circuits are PRI. >> >> >> >> >> >> >> >> Paul Farber >> >> Farber Technology >> >> farber@admin.f-tech.net >> >> Ph 570-628-5303 >> >> Fax 570-628-5545 >> >> >> >> >> >> - >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> >> with "unsubscribe usr-tc" in the body of the message. >> >> For information on digests or retrieving files and old messages send >> >> "help" to the same address. Do not use quotes in your message. >> >> >> > >> > >> >- >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> > >> > >> > >> > >> >- >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >----------------------------------------------------- >Brian Feeny (BF304) signal@shreve.net >318-222-2638 x 109 http://www.shreve.net/~signal >Network Administrator ShreveNet Inc. (ASN 11881) > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) To many drops after connect
From: Alan Martin <alamarti@nortelnetworks.com>
Date: 2000-01-21 14:36:24

Absolutely! At 01:03 PM 1/21/2000 -0600, Brian wrote: >On Fri, 21 Jan 2000, Alan Martin wrote: > >> I have TC, Ascend maxen, cisco, portmaster3, 5399/8000(oldbay) CVX, >> Looking for new LU! >> I got a BIG LAB! > >thats good, hopefully 3com has a big lab too, testing a bunch of client >modems against their code :). And of course the equipment you have found >work best in your lab is the nortel stuff right? :) > >Brian > > >> Alan >> >> >> At 12:25 PM 1/21/2000 -0600, Brian wrote: >> > >> >You all using 3Com Total Control NAS's over there at Nortel Networks? :) >> > >> >Brian >> > >> > >> >On Fri, 21 Jan 2000, Alan Martin wrote: >> > >> >> Every once in awhile sanity reigns. >> >> >> >> >> >> At 11:58 AM 1/21/2000 -0600, Steve Valiunas wrote: >> >> > >> >> > >> >> > This might not be the case in your situation since you say the >> same user >> >> >dials many times in a row, but just because a call has less than a >> minute of >> >> >connect time doesn't necessarily mean that it is a failed call. If your >> >> >customers are set to automatically connect/check Email/drop as with AOL >> >> >FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A >> >> misconfigured >> >> >dial-on-demand connection might account for it as well, as might a >> user not >> >> >satisfied with 44K and trying for that 53K connection. If there was a >> large >> >> >jump in the percentage of short calls after changing codes that might be >> >> another >> >> >story though. You might want to also look at some of your other >> accounting >> >> >data, such as Do these session stops have normal disconnect reasons? Did >> >> the >> >> >user get assigned a valid IP? Was any data passed on the sessions? >> >> > >> >> > >> >> >Steve >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >"The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM >> >> > >> >> >Please respond to usr-tc@lists.xmission.com >> >> > >> >> >Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> >> >> > >> >> > >> >> >To: usr-tc@lists.xmission.com >> >> >cc: (Steve Valiunas/MW/US/3Com) >> >> >Subject: Re: (usr-tc) To many drops after connect >> >> > >> >> > >> >> > >> >> >Paul, >> >> > >> >> >How did you find out this information on Total calls lost? Is it possible >> >> >to find this out on the old Total Control equipment also? >> >> > >> >> >Bryan >> >> >NOC Technician >> >> >COX Internet >> >> > >> >> > >> >> >----- Original Message ----- >> >> >From: "Paul Farber" <farber@admin.f-tech.net> >> >> >To: <usr-tc@lists.xmission.com> >> >> >Sent: Friday, January 21, 2000 9:40 AM >> >> >Subject: (usr-tc) To many drops after connect >> >> > >> >> > >> >> >> hello all >> >> >> >> >> >> still fighting with TC to try and get decent connection performance >> out of >> >> >> the thing. >> >> >> >> >> >> flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some >> >> >> frighting stats: >> >> >> >> >> >> Total Calls (from radius): 66212 >> >> >> Calls of < 1 minute in length: 9266 >> >> >> >> >> >> Thats a 14% drop rate! It seems to hit some people in bulk... it they >> dial >> >> >> in 5-10 times and then they just give up. >> >> >> >> >> >> I tried to narrow it down to a specific slot/channel but thier dosen't >> >> >> seem to be a pattern. >> >> >> >> >> >> Anyone else seeing similiar results??? All circuits are PRI. >> >> >> >> >> >> >> >> >> >> >> >> Paul Farber >> >> >> Farber Technology >> >> >> farber@admin.f-tech.net >> >> >> Ph 570-628-5303 >> >> >> Fax 570-628-5545 >> >> >> >> >> >> >> >> >> - >> >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> >> >> with "unsubscribe usr-tc" in the body of the message. >> >> >> For information on digests or retrieving files and old messages send >> >> >> "help" to the same address. Do not use quotes in your message. >> >> >> >> >> > >> >> > >> >> >- >> >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> >> > with "unsubscribe usr-tc" in the body of the message. >> >> > For information on digests or retrieving files and old messages send >> >> > "help" to the same address. Do not use quotes in your message. >> >> > >> >> > >> >> > >> >> > >> >> > >> >> >- >> >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> >> > with "unsubscribe usr-tc" in the body of the message. >> >> > For information on digests or retrieving files and old messages send >> >> > "help" to the same address. Do not use quotes in your message. >> >> > >> >> >> >> - >> >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> >> with "unsubscribe usr-tc" in the body of the message. >> >> For information on digests or retrieving files and old messages send >> >> "help" to the same address. Do not use quotes in your message. >> >> >> > >> >----------------------------------------------------- >> >Brian Feeny (BF304) signal@shreve.net >> >318-222-2638 x 109 http://www.shreve.net/~signal >> >Network Administrator ShreveNet Inc. (ASN 11881) >> > >> > >> >- >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >----------------------------------------------------- >Brian Feeny (BF304) signal@shreve.net >318-222-2638 x 109 http://www.shreve.net/~signal >Network Administrator ShreveNet Inc. (ASN 11881) > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG
From: Network Administrator <netadmin@seidata.com>
Date: 2000-01-21 15:20:22

I read about setting up the TCH on MRTG. I would like to set this up but not sure where to look for the what was mentioned below. Where to do I go for these? cheryl ----- Original Message ----- Sent: Wednesday, January 12, 2000 12:41 PM > you should be able to use Eric Billeters scripts that come with MRTG in the > contrib directory under TCH ( I am still using MRTG2.7.2- so these may have > changed) > > works like a dream. > > steve > > --On Wednesday, January 12, 2000 10:37 AM -0700 Greg Long > <greg@coastlink.com> wrote: > > > I want to setup MRTG to monitor modem usage on my TC hub, I have the MIB's > > that come with the USR Suite Management Software. Can I use these MIB's > > or do I need to get other MIB's? > > > > Thanks, > > Greg Long > > Tech Support > > Coastlink > > 801-532-6212 ext 32 > > techsupp@coastlink.com > > http://www.coastlink.com > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > Steve McConnell > EMJI > 919-303-3217x126 > 888-258-8959 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) To many drops after connect
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-21 15:21:24

Radius files. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Fri, 21 Jan 2000, The NOC (COX Internet) wrote: > Paul, > > How did you find out this information on Total calls lost? Is it possible > to find this out on the old Total Control equipment also? > > Bryan > NOC Technician > COX Internet > > > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 21, 2000 9:40 AM > Subject: (usr-tc) To many drops after connect > > > > hello all > > > > still fighting with TC to try and get decent connection performance out of > > the thing. > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > frighting stats: > > > > Total Calls (from radius): 66212 > > Calls of < 1 minute in length: 9266 > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > > in 5-10 times and then they just give up. > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > seem to be a pattern. > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) To many drops after connect
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-21 15:24:57

Radius stats. I use CISTRON radius 1.5.4.3 on RH 5.1. It writes a wtmp entry after a user logs off showing total time (in (HH:MM) format). I: last | grep Jan -c = count of all calls to date for January then last | grep (00:00) -c = count of all calls of 1 minute or less. You could also grep the detail file (or an awk script to check for acct-session-time < 60) for a month. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Fri, 21 Jan 2000, Clint R. Sparks wrote: > Paul, > > How are you checking this statistic? I would like to check mine as a > comparison. > > Thank you, > > Clint R. Sparks > ComQuest Internet Services > csparks@cqc.com > > > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 21, 2000 10:40 AM > Subject: (usr-tc) To many drops after connect > > > > hello all > > > > still fighting with TC to try and get decent connection performance out of > > the thing. > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > frighting stats: > > > > Total Calls (from radius): 66212 > > Calls of < 1 minute in length: 9266 > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > > in 5-10 times and then they just give up. > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > seem to be a pattern. > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) To many drops after connect
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-21 15:28:03

Because the call up and complain. I know what you are saying.. it might be the software... but it's been happening far to often to to many people. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Fri, 21 Jan 2000, Steve Valiunas wrote: > > > This might not be the case in your situation since you say the same user > dials many times in a row, but just because a call has less than a minute of > connect time doesn't necessarily mean that it is a failed call. If your > customers are set to automatically connect/check Email/drop as with AOL > FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A misconfigured > dial-on-demand connection might account for it as well, as might a user not > satisfied with 44K and trying for that 53K connection. If there was a large > jump in the percentage of short calls after changing codes that might be another > story though. You might want to also look at some of your other accounting > data, such as Do these session stops have normal disconnect reasons? Did the > user get assigned a valid IP? Was any data passed on the sessions? > > > Steve > > > > > > > "The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM > > Please respond to usr-tc@lists.xmission.com > > Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> > > > To: usr-tc@lists.xmission.com > cc: (Steve Valiunas/MW/US/3Com) > Subject: Re: (usr-tc) To many drops after connect > > > > Paul, > > How did you find out this information on Total calls lost? Is it possible > to find this out on the old Total Control equipment also? > > Bryan > NOC Technician > COX Internet > > > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 21, 2000 9:40 AM > Subject: (usr-tc) To many drops after connect > > > > hello all > > > > still fighting with TC to try and get decent connection performance out of > > the thing. > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > frighting stats: > > > > Total Calls (from radius): 66212 > > Calls of < 1 minute in length: 9266 > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > > in 5-10 times and then they just give up. > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > seem to be a pattern. > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) To many drops after connect
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-21 15:34:05

Usually there is a phone call and a complaint about being dropped. It's happened to people I know to be somewhat knowledgable on windows. The disonnect reasons are User-Request and Lost-Carrier. I have looked at the full radius accounting record and everything seems fine (data passed, IP address assigned). I don't put any faith in the Terminate-reason bacause User-Request and Lost-Carrier are way to general to be of specific value. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Fri, 21 Jan 2000, Mike Andrews wrote: > What are the disconnect reasons, though? Some people really do have a lot > of < 1 minute calls -- those trying to just pick mail up and log off, for > example... we see that a lot. We can tell them apart from people having > problems by looking for the disconnect reason. > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > "Don't sweat the petty things, and don't pet the sweaty things." > > On Fri, 21 Jan 2000, Paul Farber wrote: > > > hello all > > > > still fighting with TC to try and get decent connection performance out of > > the thing. > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > frighting stats: > > > > Total Calls (from radius): 66212 > > Calls of < 1 minute in length: 9266 > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > > in 5-10 times and then they just give up. > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > seem to be a pattern. > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) HiPer ARC 4.2.32-1
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-21 17:04:36

What is the general consensus on HiPer ARC 4.2.32-1 code? Bryan NOC Technician COX Internet

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Brian <signal@shreve.net>
Date: 2000-01-21 18:51:40

I think what I hear is that 4.2 you really only need to goto if you want OSPF. And that the OSPF in 4.2 is flaky anyways. So 4.2 doesn't sound to production ready yet. Brian On Fri, 21 Jan 2000, The NOC (COX Internet) wrote: > What is the general consensus on HiPer ARC 4.2.32-1 code? > > Bryan > NOC Technician > COX Internet > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Brian <signal@shreve.net>
Date: 2000-01-21 18:52:03

did you gain anything between 4.2 vs 4.1? Brian On Fri, 21 Jan 2000, Jeff Mcadams wrote: > Thus spake The NOC COX Internet" > >What is the general consensus on HiPer ARC 4.2.32-1 code? > > Working fine here...though I am still stearing clear of enabling OSPF. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-21 19:05:19

Thus spake The NOC COX Internet" >What is the general consensus on HiPer ARC 4.2.32-1 code? Working fine here...though I am still stearing clear of enabling OSPF. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) To many drops after connect
From: Brian <signal@shreve.net>
Date: 2000-01-21 19:54:51

is 2.0.51 really only for .54/.55? I mean reading the pdf, I see a fix for .54/.55 cards, but the rest of the issues looked like they applied to any DSP. Brian On Fri, 21 Jan 2000, Scot Desort wrote: > Paul, > > Have you tried 2.0.51 on the DSP's? I know it was really only intended for > .54/.55 rev cards, but there are some fixes for Rockwell in there. Might be > worth a shot to load it on some cards and see if it makes any difference. > > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber > >Sent: Friday, January 21, 2000 3:28 PM > >To: usr-tc@lists.xmission.com > >Subject: Re: (usr-tc) To many drops after connect > > > > > >Because the call up and complain. I know what you are saying.. it might > >be the software... but it's been happening far to often to to many people. > > > >Paul Farber > >Farber Technology > >farber@admin.f-tech.net > >Ph 570-628-5303 > >Fax 570-628-5545 > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-21 20:17:55

Thus spake Brian >did you gain anything between 4.2 vs 4.1? I went to 4.2 initially to pick up the security fixes that are now available in 4.1.22. So at this point, had I not already gone to 4.2 I probably wouldn't, but at the time, I felt it was necessary. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) To many drops after connect
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-21 20:46:30

Paul, Have you tried 2.0.51 on the DSP's? I know it was really only intended for .54/.55 rev cards, but there are some fixes for Rockwell in there. Might be worth a shot to load it on some cards and see if it makes any difference. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber >Sent: Friday, January 21, 2000 3:28 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) To many drops after connect > > >Because the call up and complain. I know what you are saying.. it might >be the software... but it's been happening far to often to to many people. > >Paul Farber >Farber Technology >farber@admin.f-tech.net >Ph 570-628-5303 >Fax 570-628-5545 > >

Subject: RE: (usr-tc) To many drops after connect
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-21 21:14:16

Well, it was released in _response_ to the .54/.55 problem, but it obviously corrects other issues that apply to any DSP rev, as I stated. I just flashed my last 2.0.81 card to 2.0.51. We'll see what happens. The last card was a .54 card that I got on a trade-up from 3COM. It definitely experienced some weird stuff on 2.0.81. >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian >Sent: Friday, January 21, 2000 8:55 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) To many drops after connect > > > >is 2.0.51 really only for .54/.55? I mean reading the pdf, I see a fix >for .54/.55 cards, but the rest of the issues looked like they applied to >any DSP. > >Brian > > >On Fri, 21 Jan 2000, Scot Desort wrote: > >> Paul, >> >> Have you tried 2.0.51 on the DSP's? I know it was really only >intended for >> .54/.55 rev cards, but there are some fixes for Rockwell in >there. Might be >> worth a shot to load it on some cards and see if it makes any difference. >> >> >-----Original Message----- >> >From: owner-usr-tc@lists.xmission.com >> >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber >> >Sent: Friday, January 21, 2000 3:28 PM >> >To: usr-tc@lists.xmission.com >> >Subject: Re: (usr-tc) To many drops after connect >> > >> > >> >Because the call up and complain. I know what you are saying.. it might >> >be the software... but it's been happening far to often to to >many people. >> > >> >Paul Farber >> >Farber Technology >> >farber@admin.f-tech.net >> >Ph 570-628-5303 >> >Fax 570-628-5545 >> > >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > >----------------------------------------------------- >Brian Feeny (BF304) signal@shreve.net >318-222-2638 x 109 http://www.shreve.net/~signal >Network Administrator ShreveNet Inc. (ASN 11881) > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) To many drops after connect
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-21 21:34:43

2.0.51 runs on cards other than .54/.55; it's what we run here... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Fri, 21 Jan 2000, Brian wrote: > > is 2.0.51 really only for .54/.55? I mean reading the pdf, I see a fix > for .54/.55 cards, but the rest of the issues looked like they applied to > any DSP. > > Brian > > > On Fri, 21 Jan 2000, Scot Desort wrote: > > > Paul, > > > > Have you tried 2.0.51 on the DSP's? I know it was really only intended for > > .54/.55 rev cards, but there are some fixes for Rockwell in there. Might be > > worth a shot to load it on some cards and see if it makes any difference. > > > > >-----Original Message----- > > >From: owner-usr-tc@lists.xmission.com > > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber > > >Sent: Friday, January 21, 2000 3:28 PM > > >To: usr-tc@lists.xmission.com > > >Subject: Re: (usr-tc) To many drops after connect > > > > > > > > >Because the call up and complain. I know what you are saying.. it might > > >be the software... but it's been happening far to often to to many people. > > > > > >Paul Farber > > >Farber Technology > > >farber@admin.f-tech.net > > >Ph 570-628-5303 > > >Fax 570-628-5545 > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) MRTG cfg
From: stevec <stevec@mail.computer-geeks.com>
Date: 2000-01-22 06:06:06

I was wondering what I can use as SNMPOID for my TC rack. The main thing I want to look at is modem utilization. I was sent a cfg file from a friend and the SNMPOID didn't work with my unit. First off, how can I tell what all I am running. Our telco provider set all our stuff up so I don't know what it is. I can telnet to it and I get a "HIPER>>" prompt. I used the cfgmaker with mrtg but it gave me a bunch of useless ports. I would also like to monitor bandwidth utilization through this if possible. Thanks for your help! Thanks for your help, -- Steve Cobb stevec@computer-geeks.com Computer Geeks www.computer-geeks.com --

Subject: (usr-tc) AMI/D4 provisioning on CT1
From: Bryan Wann <bwann@cwis.net>
Date: 2000-01-22 12:15:17

I don't like surprises. Especially when I order a CT1 provisioned with B8ZS/ESF, and on the day of the turnup the switch tech tells me "oh, your stuff is configured wrong, it needs to be set up for AMI and D4, the DTC you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up like everyone else's." AFAIK, it is a trunk-side circuit (don't hold me to this). We have no problem hitting 45333-50333 both local and long-distance dialing into the TC at this POP, with an assortment of modems. Will AMI/D4 cause things to break, or should I contact the telco and beg to have it reprovisioned for B8ZS/ESF? --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-22 13:55:26

Thus spake Bryan Wann > I don't like surprises. > Especially when I order a CT1 provisioned with B8ZS/ESF, and on >the day of the turnup the switch tech tells me "oh, your stuff is >configured wrong, it needs to be set up for AMI and D4, the DTC you're >on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up like >everyone else's." > AFAIK, it is a trunk-side circuit (don't hold me to this). We >have no problem hitting 45333-50333 both local and long-distance >dialing into the TC at this POP, with an assortment of modems. > Will AMI/D4 cause things to break, or should I contact the telco >and beg to have it reprovisioned for B8ZS/ESF? How about a 6 week lead time and the day the circuits are supposed to be turned up, "Oh, we don't have the right cards and cables at the switch, so sorry." We're at a week and counting past FOC with a 6 week lead time...what do these telco's do during that 6 weeks?! Anyway...you shouldn't see any problems with AMI/D4, if you're getting 45333-50333, you might be getting 46000-51000 with B8ZS/ESF or so, but I'm not even sure about that. I'd go ahead and not worry about fighting with the telco on this one and be happy. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Reset stats
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-22 13:57:57

How do you reset the stats on the old style TCH? I have tried every thing I know to reset the stats. I can't find anything in documentation to tell me how to do this. The stats that I am trying to reset are the ones you can get through the performance monitor in the Total Control Management software. Specifically, I am trying to reset the Incoming Connections Established, Incoming Connections Terminated, Connect Attempt Failure, and the Incoming Connections Failed fields under the Modem Events in the Functional Group. Any suggestions would be greatly appreciated. Bryan NOC Technician COX Internet

Subject: RE: (usr-tc) To many drops after connect
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-22 14:01:15

I'l chime in here. Just recently we put together the stats to confirm the same drop rates, at the same time we implemented a survey to our customers. Guess what? they get dropped all the time. Different ones at different times in differing amounts. This by and large the single greatest complaint against this ISP. A lot of these same people have more than one one accont and are glad to point out the it doesn't happen with their "other" ISP. These are people who connect, auth and pass data. I haven't had the chance yet to together stats on the disconnect reason tied directly to calls, I can tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling it. 4.2.32-1 2.0.51 6.2.17 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber Sent: Friday, January 21, 2000 12:28 PM Because the call up and complain. I know what you are saying.. it might be the software... but it's been happening far to often to to many people. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Fri, 21 Jan 2000, Steve Valiunas wrote: > > > This might not be the case in your situation since you say the same user > dials many times in a row, but just because a call has less than a minute of > connect time doesn't necessarily mean that it is a failed call. If your > customers are set to automatically connect/check Email/drop as with AOL > FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A misconfigured > dial-on-demand connection might account for it as well, as might a user not > satisfied with 44K and trying for that 53K connection. If there was a large > jump in the percentage of short calls after changing codes that might be another > story though. You might want to also look at some of your other accounting > data, such as Do these session stops have normal disconnect reasons? Did the > user get assigned a valid IP? Was any data passed on the sessions? > > > Steve > > > > > > > "The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM > > Please respond to usr-tc@lists.xmission.com > > Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> > > > To: usr-tc@lists.xmission.com > cc: (Steve Valiunas/MW/US/3Com) > Subject: Re: (usr-tc) To many drops after connect > > > > Paul, > > How did you find out this information on Total calls lost? Is it possible > to find this out on the old Total Control equipment also? > > Bryan > NOC Technician > COX Internet > > > ----- Original Message ----- > From: "Paul Farber" <farber@admin.f-tech.net> > To: <usr-tc@lists.xmission.com> > Sent: Friday, January 21, 2000 9:40 AM > Subject: (usr-tc) To many drops after connect > > > > hello all > > > > still fighting with TC to try and get decent connection performance out of > > the thing. > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > frighting stats: > > > > Total Calls (from radius): 66212 > > Calls of < 1 minute in length: 9266 > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they dial > > in 5-10 times and then they just give up. > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > seem to be a pattern. > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) V.42 discconnecton
From: Terry Kennedy <terry@olypen.com>
Date: 2000-01-22 14:06:04

Is this a normal disconnecton? I am seeing huge number of these with tcm. -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Long Sent: Friday, January 21, 2000 1:06 PM There are some scripts located in the TCH subdirectory under the CONTRIB directory, inder the MRTG root directory. Email me off list and I will help you out if you have questions. -Greg greg@coastlink.com -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Network Administrator Sent: Friday, January 21, 2000 1:20 PM I read about setting up the TCH on MRTG. I would like to set this up but not sure where to look for the what was mentioned below. Where to do I go for these? cheryl ----- Original Message ----- Sent: Wednesday, January 12, 2000 12:41 PM > you should be able to use Eric Billeters scripts that come with MRTG in the > contrib directory under TCH ( I am still using MRTG2.7.2- so these may have > changed) > > works like a dream. > > steve > > --On Wednesday, January 12, 2000 10:37 AM -0700 Greg Long > <greg@coastlink.com> wrote: > > > I want to setup MRTG to monitor modem usage on my TC hub, I have the MIB's > > that come with the USR Suite Management Software. Can I use these MIB's > > or do I need to get other MIB's? > > > > Thanks, > > Greg Long > > Tech Support > > Coastlink > > 801-532-6212 ext 32 > > techsupp@coastlink.com > > http://www.coastlink.com > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > Steve McConnell > EMJI > 919-303-3217x126 > 888-258-8959 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Clayton Zekelman <clayton@mnsi.net>
Date: 2000-01-22 14:38:13

We use only B8ZS/ESF on CT1's with Nortel DMS-100 switches. Only the oldest of DTC's on the DMS can't do B8ZS/ESF. All the new ones (past 5 years or more) CAN do it. At 12:15 PM 1/22/00 -0600, you wrote: > I don't like surprises. > > Especially when I order a CT1 provisioned with B8ZS/ESF, and on >the day of the turnup the switch tech tells me "oh, your stuff is >configured wrong, it needs to be set up for AMI and D4, the DTC >you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up >like everyone else's." > > AFAIK, it is a trunk-side circuit (don't hold me to this). We >have no problem hitting 45333-50333 both local and long-distance dialing >into the TC at this POP, with an assortment of modems. > > Will AMI/D4 cause things to break, or should I contact the telco >and beg to have it reprovisioned for B8ZS/ESF? > > > >--- >Bryan Wann bwann@cwis.net >CWIS Internet Services http://www.cwis.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

Subject: Re: (usr-tc) Reset stats
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-22 15:17:22

Jeff, Thanks for the info. I know of one sure way to reset the stats is to upgrade the cards in the box. Do you know which card keeps these stats or where they are located? They have to be stored somewhere right? Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Saturday, January 22, 2000 2:59 PM > Thus spake The NOC COX Internet" > >How do you reset the stats on the old style TCH? I have tried every > >thing I know to reset the stats. I can't find anything in > >documentation to tell me how to do this. The stats that I am trying to > >reset are the ones you can get through the performance monitor in the > >Total Control Management software. Specifically, I am trying to reset > >the Incoming Connections Established, Incoming Connections Terminated, > >Connect Attempt Failure, and the Incoming Connections Failed fields > >under the Modem Events in the Functional Group. Any suggestions would > >be greatly appreciated. > > Reboot. And even then, in theory, they shouldn't reset. > > Basically, this is because of the spec of SNMP...SNMP counters can't be > reset while the system is running...to get a delta you have to note what > it is currently and check it later and subtract...not terribly difficult > in the overall scheme of things unless the utility that you're using > (ie, TCM) isn't open source (*cough*) and doesn't have support for it. > > In theory, according to my understanding of the SNMP spec, even a reboot > shouldn't clear the stats, they should be persistant. Not that much of > anyone pays attention to that in their SNMP agent implementations. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) To many drops after connect
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-22 15:26:09

We're running the same software except that I have 6.1.17 on our NMC. I've had numerous recent complaints about disconnects and having to dial 5-6 times to connect. Actually, the complaints have existed since we upgraded to the Hiperarc and DSP's. There have been more just over the last week or so it seems. We're running channelized T1's from USWorst. I did change the db level to 13 but that was several weeks ago. I'm not sure if it helped or not. At 02:01 PM 1/22/00 -0800, you wrote: >I'l chime in here. Just recently we put together the stats to confirm the >same drop rates, at the same time we implemented a survey to our customers. >Guess what? they get dropped all the time. Different ones at different times >in differing amounts. This by and large the single greatest complaint >against this ISP. A lot of these same people have more than one one accont >and are glad to point out the it doesn't happen with their "other" ISP. >These are people who connect, auth and pass data. I haven't had the chance >yet to together stats on the disconnect reason tied directly to calls, I can >tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling >it. > >4.2.32-1 >2.0.51 >6.2.17 > > > > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber >Sent: Friday, January 21, 2000 12:28 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) To many drops after connect > > >Because the call up and complain. I know what you are saying.. it might >be the software... but it's been happening far to often to to many people. > >Paul Farber >Farber Technology >farber@admin.f-tech.net >Ph 570-628-5303 >Fax 570-628-5545 > >On Fri, 21 Jan 2000, Steve Valiunas wrote: > > > > > > > This might not be the case in your situation since you say the same >user > > dials many times in a row, but just because a call has less than a minute >of > > connect time doesn't necessarily mean that it is a failed call. If your > > customers are set to automatically connect/check Email/drop as with AOL > > FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A >misconfigured > > dial-on-demand connection might account for it as well, as might a user >not > > satisfied with 44K and trying for that 53K connection. If there was a >large > > jump in the percentage of short calls after changing codes that might be >another > > story though. You might want to also look at some of your other >accounting > > data, such as Do these session stops have normal disconnect reasons? Did >the > > user get assigned a valid IP? Was any data passed on the sessions? > > > > > > Steve > > > > > > > > > > > > > > "The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM > > > > Please respond to usr-tc@lists.xmission.com > > > > Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> > > > > > > To: usr-tc@lists.xmission.com > > cc: (Steve Valiunas/MW/US/3Com) > > Subject: Re: (usr-tc) To many drops after connect > > > > > > > > Paul, > > > > How did you find out this information on Total calls lost? Is it possible > > to find this out on the old Total Control equipment also? > > > > Bryan > > NOC Technician > > COX Internet > > > > > > ----- Original Message ----- > > From: "Paul Farber" <farber@admin.f-tech.net> > > To: <usr-tc@lists.xmission.com> > > Sent: Friday, January 21, 2000 9:40 AM > > Subject: (usr-tc) To many drops after connect > > > > > > > hello all > > > > > > still fighting with TC to try and get decent connection performance out >of > > > the thing. > > > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > > frighting stats: > > > > > > Total Calls (from radius): 66212 > > > Calls of < 1 minute in length: 9266 > > > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they >dial > > > in 5-10 times and then they just give up. > > > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > > seem to be a pattern. > > > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > > > > > Paul Farber > > > Farber Technology > > > farber@admin.f-tech.net > > > Ph 570-628-5303 > > > Fax 570-628-5545 > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) V.42 discconnecton
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-22 15:32:16

I had 69/192 listed as the disconnect reason - v42DisconnectCmd(26) At 02:06 PM 1/22/00 -0800, you wrote: >Is this a normal disconnecton? I am seeing huge number of these with tcm. > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Long >Sent: Friday, January 21, 2000 1:06 PM >To: usr-tc@lists.xmission.com >Subject: RE: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG > > >There are some scripts located in the TCH subdirectory under the CONTRIB >directory, inder the MRTG root directory. Email me off list and I will help >you out if you have questions. > >-Greg >greg@coastlink.com > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Network >Administrator >Sent: Friday, January 21, 2000 1:20 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG > > >I read about setting up the TCH on MRTG. I would like to set this up but not >sure where to look for the what was mentioned below. Where to do I go for >these? > >cheryl > >----- Original Message ----- >From: Steve McConnell <stevem@emji.net> >To: <usr-tc@lists.xmission.com> >Sent: Wednesday, January 12, 2000 12:41 PM >Subject: Re: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG > > > > you should be able to use Eric Billeters scripts that come with MRTG in >the > > contrib directory under TCH ( I am still using MRTG2.7.2- so these may >have > > changed) > > > > works like a dream. > > > > steve > > > > --On Wednesday, January 12, 2000 10:37 AM -0700 Greg Long > > <greg@coastlink.com> wrote: > > > > > I want to setup MRTG to monitor modem usage on my TC hub, I have the >MIB's > > > that come with the USR Suite Management Software. Can I use these MIB's > > > or do I need to get other MIB's? > > > > > > Thanks, > > > Greg Long > > > Tech Support > > > Coastlink > > > 801-532-6212 ext 32 > > > techsupp@coastlink.com > > > http://www.coastlink.com > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > Steve McConnell > > EMJI > > 919-303-3217x126 > > 888-258-8959 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center #100, Casper, WY 82601 www.vcn.com

Subject: Re: (usr-tc) Reset stats
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-22 15:59:33

Thus spake The NOC COX Internet" >How do you reset the stats on the old style TCH? I have tried every >thing I know to reset the stats. I can't find anything in >documentation to tell me how to do this. The stats that I am trying to >reset are the ones you can get through the performance monitor in the >Total Control Management software. Specifically, I am trying to reset >the Incoming Connections Established, Incoming Connections Terminated, >Connect Attempt Failure, and the Incoming Connections Failed fields >under the Modem Events in the Functional Group. Any suggestions would >be greatly appreciated. Reboot. And even then, in theory, they shouldn't reset. Basically, this is because of the spec of SNMP...SNMP counters can't be reset while the system is running...to get a delta you have to note what it is currently and check it later and subtract...not terribly difficult in the overall scheme of things unless the utility that you're using (ie, TCM) isn't open source (*cough*) and doesn't have support for it. In theory, according to my understanding of the SNMP spec, even a reboot shouldn't clear the stats, they should be persistant. Not that much of anyone pays attention to that in their SNMP agent implementations. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Reset stats
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-22 16:21:39

Thus spake The NOC COX Internet" >Thanks for the info. I know of one sure way to reset the stats is to >upgrade the cards in the box. Do you know which card keeps these stats or >where they are located? They have to be stored somewhere right? You know...I'm not sure off the top of my head which card actually holds them...based on performance, I suspect the individual card holds them for its entities. You can take a shot at rebooting the NMC (which is non-disruptive to calls) and see if that resets it...it might just do it, but I don't think its going to. I *think* you're going to have to reset the actual modem cards for those stats (all modem related stats that were mentioned). I say "based on performance" because of the performance of an SNMP get of those values. If you want to see this, do an snmpwalk of something that is held fully in the NMC (like an xxxxxIndex OID), then compare how quickly those values return compared to values like the ones you mentioned...the ones you mentioned will take significantly longer...my hypothesis is because the NMC has to obtain the information from the card via the management bus of the chassis...with the resultant latency in the request. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) To many drops after connect
From: Brian Elfert <brian@citilink.com>
Date: 2000-01-22 17:16:33

On Sat, 22 Jan 2000, Terry Kennedy wrote: > against this ISP. A lot of these same people have more than one one accont I always question why some many people claim to have multiple accounts. > and are glad to point out the it doesn't happen with their "other" ISP. Have you checked what type of modems these other ISPs use? > These are people who connect, auth and pass data. I haven't had the chance > yet to together stats on the disconnect reason tied directly to calls, I can > tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling This disconnect reason is not generally a problem. This is the way most modems request a normal disconnect. Brian

Subject: RE: (usr-tc) AMI/D4 provisioning on CT1
From: Marshall Morgan <marshall@netdoor.com>
Date: 2000-01-22 17:30:25

If you are paying for it then get what you ordered. Period. Ask them to change it and in the mean time you will use the T1's provided. They are a public utility so make them work for you. Marshall Morgan Internet Doorway, Inc (aka NETDOOR) http://www.netdoor.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bryan Wann > Sent: Saturday, January 22, 2000 12:15 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) AMI/D4 provisioning on CT1 > > > I don't like surprises. > > Especially when I order a CT1 provisioned with B8ZS/ESF, and on > the day of the turnup the switch tech tells me "oh, your stuff is > configured wrong, it needs to be set up for AMI and D4, the DTC > you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up > like everyone else's." > > AFAIK, it is a trunk-side circuit (don't hold me to this). We > have no problem hitting 45333-50333 both local and long-distance dialing > into the TC at this POP, with an assortment of modems. > > Will AMI/D4 cause things to break, or should I contact the telco > and beg to have it reprovisioned for B8ZS/ESF?

Subject: RE: (usr-tc) To many drops after connect
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-22 18:28:09

I just went DOWN to 2.0.19 from 2.0.80 (or back or however the hell 3Com came up with the ass backward numbering scheme) to try and keep users connected. CONNECTING is not a problem.... saying CONNECTED is. I'm trying to duplicate the drops with my laptops and support dial ups. After the downgrade to the previous 2.0.19 code it seems to be a bit better. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sat, 22 Jan 2000, Greg Coffey wrote: > We're running the same software except that I have 6.1.17 on our NMC. I've > had numerous recent complaints about disconnects and having to dial 5-6 > times to connect. Actually, the complaints have existed since we upgraded > to the Hiperarc and DSP's. There have been more just over the last week or > so it seems. We're running channelized T1's from USWorst. I did change > the db level to 13 but that was several weeks ago. I'm not sure if it > helped or not. > > At 02:01 PM 1/22/00 -0800, you wrote: > >I'l chime in here. Just recently we put together the stats to confirm the > >same drop rates, at the same time we implemented a survey to our customers. > >Guess what? they get dropped all the time. Different ones at different times > >in differing amounts. This by and large the single greatest complaint > >against this ISP. A lot of these same people have more than one one accont > >and are glad to point out the it doesn't happen with their "other" ISP. > >These are people who connect, auth and pass data. I haven't had the chance > >yet to together stats on the disconnect reason tied directly to calls, I can > >tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling > >it. > > > >4.2.32-1 > >2.0.51 > >6.2.17 > > > > > > > > > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Farber > >Sent: Friday, January 21, 2000 12:28 PM > >To: usr-tc@lists.xmission.com > >Subject: Re: (usr-tc) To many drops after connect > > > > > >Because the call up and complain. I know what you are saying.. it might > >be the software... but it's been happening far to often to to many people. > > > >Paul Farber > >Farber Technology > >farber@admin.f-tech.net > >Ph 570-628-5303 > >Fax 570-628-5545 > > > >On Fri, 21 Jan 2000, Steve Valiunas wrote: > > > > > > > > > > > This might not be the case in your situation since you say the same > >user > > > dials many times in a row, but just because a call has less than a minute > >of > > > connect time doesn't necessarily mean that it is a failed call. If your > > > customers are set to automatically connect/check Email/drop as with AOL > > > FlashSessions, CC-Mail, LotusNotes etc., then this is normal. A > >misconfigured > > > dial-on-demand connection might account for it as well, as might a user > >not > > > satisfied with 44K and trying for that 53K connection. If there was a > >large > > > jump in the percentage of short calls after changing codes that might be > >another > > > story though. You might want to also look at some of your other > >accounting > > > data, such as Do these session stops have normal disconnect reasons? Did > >the > > > user get assigned a valid IP? Was any data passed on the sessions? > > > > > > > > > Steve > > > > > > > > > > > > > > > > > > > > > "The NOC $COX Internet$" <usrtc@tyler.net> on 01/21/2000 11:04:53 AM > > > > > > Please respond to usr-tc@lists.xmission.com > > > > > > Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> > > > > > > > > > To: usr-tc@lists.xmission.com > > > cc: (Steve Valiunas/MW/US/3Com) > > > Subject: Re: (usr-tc) To many drops after connect > > > > > > > > > > > > Paul, > > > > > > How did you find out this information on Total calls lost? Is it possible > > > to find this out on the old Total Control equipment also? > > > > > > Bryan > > > NOC Technician > > > COX Internet > > > > > > > > > ----- Original Message ----- > > > From: "Paul Farber" <farber@admin.f-tech.net> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Friday, January 21, 2000 9:40 AM > > > Subject: (usr-tc) To many drops after connect > > > > > > > > > > hello all > > > > > > > > still fighting with TC to try and get decent connection performance out > >of > > > > the thing. > > > > > > > > flashed the ARC/NMC/DSP to 4.1.22/6.2.17/2.0.60 and here are some > > > > frighting stats: > > > > > > > > Total Calls (from radius): 66212 > > > > Calls of < 1 minute in length: 9266 > > > > > > > > Thats a 14% drop rate! It seems to hit some people in bulk... it they > >dial > > > > in 5-10 times and then they just give up. > > > > > > > > I tried to narrow it down to a specific slot/channel but thier dosen't > > > > seem to be a pattern. > > > > > > > > Anyone else seeing similiar results??? All circuits are PRI. > > > > > > > > > > > > > > > > Paul Farber > > > > Farber Technology > > > > farber@admin.f-tech.net > > > > Ph 570-628-5303 > > > > Fax 570-628-5545 > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > Thanks, Greg Coffey <gcoffey@vcn.com> > Visionary Communications V 307-234-5443 F 307-234-5446 > 100 N. Center #100, Casper, WY 82601 www.vcn.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) V.42 discconnecton
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-22 19:27:03

Those are normal disconnects. You should receive a v.42 disconnect command from the client when they (or at least their operating system) specifically requests a disconnect by dropping DTR. You *should* have a huge number of those. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Sat, 22 Jan 2000, Greg Coffey wrote: > I had 69/192 listed as the disconnect reason - v42DisconnectCmd(26) > > At 02:06 PM 1/22/00 -0800, you wrote: > >Is this a normal disconnecton? I am seeing huge number of these with tcm. > > > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Long > >Sent: Friday, January 21, 2000 1:06 PM > >To: usr-tc@lists.xmission.com > >Subject: RE: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG > > > > > >There are some scripts located in the TCH subdirectory under the CONTRIB > >directory, inder the MRTG root directory. Email me off list and I will help > >you out if you have questions. > > > >-Greg > >greg@coastlink.com > > > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Network > >Administrator > >Sent: Friday, January 21, 2000 1:20 PM > >To: usr-tc@lists.xmission.com > >Subject: Re: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG > > > > > >I read about setting up the TCH on MRTG. I would like to set this up but not > >sure where to look for the what was mentioned below. Where to do I go for > >these? > > > >cheryl > > > >----- Original Message ----- > >From: Steve McConnell <stevem@emji.net> > >To: <usr-tc@lists.xmission.com> > >Sent: Wednesday, January 12, 2000 12:41 PM > >Subject: Re: (usr-tc) TC Enterprise Network Hub, MIB's, and MRTG > > > > > > > you should be able to use Eric Billeters scripts that come with MRTG in > >the > > > contrib directory under TCH ( I am still using MRTG2.7.2- so these may > >have > > > changed) > > > > > > works like a dream. > > > > > > steve > > > > > > --On Wednesday, January 12, 2000 10:37 AM -0700 Greg Long > > > <greg@coastlink.com> wrote: > > > > > > > I want to setup MRTG to monitor modem usage on my TC hub, I have the > >MIB's > > > > that come with the USR Suite Management Software. Can I use these MIB's > > > > or do I need to get other MIB's? > > > > > > > > Thanks, > > > > Greg Long > > > > Tech Support > > > > Coastlink > > > > 801-532-6212 ext 32 > > > > techsupp@coastlink.com > > > > http://www.coastlink.com > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > Steve McConnell > > > EMJI > > > 919-303-3217x126 > > > 888-258-8959 > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > Thanks, Greg Coffey <gcoffey@vcn.com> > Visionary Communications V 307-234-5443 F 307-234-5446 > 100 N. Center #100, Casper, WY 82601 www.vcn.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Reset stats
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-22 19:39:51

You can reset the stats for Quads by doing a software reset on the NMC. The HiperDSPs store the counters themselves though, so you'll have to reboot the HiperDSP to clear it's stats. Steve Valiunas "The NOC $COX Internet$" <usrtc@tyler.net> on 01/22/2000 01:57:57 PM Please respond to usr-tc@lists.xmission.com Sent by: "The NOC $COX Internet$" <usrtc@tyler.net> cc: (Steve Valiunas/MW/US/3Com) How do you reset the stats on the old style TCH? I have tried every thing I know to reset the stats. I can't find anything in documentation to tell me how to do this. The stats that I am trying to reset are the ones you can get through the performance monitor in the Total Control Management software. Specifically, I am trying to reset the Incoming Connections Established, Incoming Connections Terminated, Connect Attempt Failure, and the Incoming Connections Failed fields under the Modem Events in the Functional Group. Any suggestions would be greatly appreciated. Bryan NOC Technician COX Internet - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) To many drops after connect
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-22 20:11:06

On Sat, 22 Jan 2000, Terry Kennedy wrote: > I'l chime in here. Just recently we put together the stats to confirm the > same drop rates, at the same time we implemented a survey to our customers. > Guess what? they get dropped all the time. Different ones at different times > in differing amounts. This by and large the single greatest complaint > against this ISP. A lot of these same people have more than one one accont > and are glad to point out the it doesn't happen with their "other" ISP. > These are people who connect, auth and pass data. I haven't had the chance > yet to together stats on the disconnect reason tied directly to calls, I can > tell you that I see a lot of v42DisconnectCmd. I am thinking of disabling > it. Disable v.42? Uh... not a good idea. v.42bis maybe, if your DSP cards have a dead CPU (like one of mine appears to), but not v.42. To really get to the bottom of the disconnect stuff, you have to look at BOTH disconnect reasons -- one logged by the ARC, one logged by the modems. You have to look at the two together to see why the connection dropped... otherwise you'll NEVER be able to figure out what to blame on the customer, or the customer's modem, or 3Com's code, or your own setup. Here's an abridged version of something I wrote for our support people that might help. If anyone's got any corrections I'd like to hear 'em...

Subject: Re: (usr-tc) MRTG cfg
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-22 20:13:07

Check http://www.dcr.net/~mandrews/usrtoys -- there's some MRTG tips there. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Sat, 22 Jan 2000, stevec wrote: > I was wondering what I can use as SNMPOID for my TC rack. The main thing I want to look at is modem utilization. I was sent a cfg file from a friend and the SNMPOID didn't work with my unit. First off, how can I tell what all I am running. Our telco provider set all our stuff up so I don't know what it is. I can telnet to it and I get a "HIPER>>" prompt. I used the cfgmaker with mrtg but it gave me a bunch of useless ports. I would also like to monitor bandwidth utilization through this if possible. Thanks for your help! > > Thanks for your help, > > > -- > Steve Cobb > stevec@computer-geeks.com > Computer Geeks > www.computer-geeks.com > -- > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) To many drops after connect
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-22 20:43:28

On Sat, 22 Jan 2000, Mike Andrews wrote: > To really get to the bottom of the disconnect stuff, you have to look at > BOTH disconnect reasons -- one logged by the ARC, one logged by the > modems. Is there a way to get the hub to send both reasons to the radius accounting server as part of the acct-stop message? If not, I'm going to have to reveal my lack of clue by asking how to get ahold of these reasons (aside from using prescience to determine when the call is going to drop and then doing rapid-fire snmp queries. *grin*) This would be nice...the current choices of 'lost-carrier' and 'user-disconnect' that I get in my radius are about worthless.

Subject: Re: (usr-tc) To many drops after connect
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-22 21:32:44

Thus spake Lon R. Stockton, Jr. >On Sat, 22 Jan 2000, Mike Andrews wrote: >> To really get to the bottom of the disconnect stuff, you have to look at >> BOTH disconnect reasons -- one logged by the ARC, one logged by the >> modems. Good list Mike...thanks! >Is there a way to get the hub to send both reasons to the radius >accounting server as part of the acct-stop message? No...basically because the Arc is sending the acct-stop message, and it only has the Arc disconnect reason...the modem disconnect reason is only accesible via a modem event. The modem will send the event to the NMC, and the NMC can generate either one or both of an SNMP trap, or a RADIUS accounting request. Note, this is a *seperate* RADIUS accounting request from the Arc's. It is configured on the NMC, and is configured as "enablelog" rather than "enabletrap". You'll also need to set up the log server on the NMC. You can send these RADIUS accounting logs to your main RADIUS server, but I tend to send them to a seperate one to keep the information seperate, and easier to handle (if you enable logs on your modems for even a small number of events you're going to have some rather large log files) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Garlic <garlic@garlic.com>
Date: 2000-01-23 09:19:47

Before you go demand they do something, make sure you are not going to waste your time. B8ZS is of no help on a CT1. The purpose of B8ZS is to ensure timing by preventing lots of consecutive zeros on the line. This can't happen with a CT1. The control bits in each channel will ensure enough ones density to maintain timing. ESF is better than D4 is you are doing monitoring of the line or are going to run advanced diagnostics using test equipment. Not having ESF doesn't hurt untill you have problems then its a benefit. The bad news is that ESF requires that both ends of the line be ESF capable. Many switches aren't ESF capable on CT1s. Marshall Morgan wrote: > If you are paying for it then get what you ordered. Period. Ask them to change > it and in the mean time you will use the T1's provided. They are a public > utility so make them work for you. > > Marshall Morgan > > Internet Doorway, Inc (aka NETDOOR) > http://www.netdoor.com > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bryan Wann > > Sent: Saturday, January 22, 2000 12:15 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) AMI/D4 provisioning on CT1 > > > > > > I don't like surprises. > > > > Especially when I order a CT1 provisioned with B8ZS/ESF, and on > > the day of the turnup the switch tech tells me "oh, your stuff is > > configured wrong, it needs to be set up for AMI and D4, the DTC > > you're on can't do B8ZS/ESF on this T. Don't worry, I set your stuff up > > like everyone else's." > > > > AFAIK, it is a trunk-side circuit (don't hold me to this). We > > have no problem hitting 45333-50333 both local and long-distance dialing > > into the TC at this POP, with an assortment of modems. > > > > Will AMI/D4 cause things to break, or should I contact the telco > > and beg to have it reprovisioned for B8ZS/ESF? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) D Channel Problem
From: D A Substanley <das@gol.com>
Date: 2000-01-23 10:29:43

I'm currently running at least 10 DSP cards per HiperARC without problems. That problem, I believe was addressed awhile ago. das Brian (signal@shreve.net) spake: > > > didn't they fix a problem like that in the new dsp code? might want to > upgrade your dsp code. > > Brian > > On Fri, 21 Jan 2000, Jason P. wrote: > > > I remember hearing about the number of DSP's to ARC limit, but I didn't think > > that would be causing the D channel on my 7th DSP to be going up and down > > continuously. I have another ARC card on hand, so I'll try to add that one > > and see what happens. Thanks for the tip. > > > > > > "The NOC (COX Internet)" wrote: > > > > > Jason, > > > > > > I have read somewhere that after so many cards (7 or 8), you need to add > > > another gateway card. After so many DSP cards, the load gets overwhelming > > > for only one gateway card so you have to add another. This might be the > > > situation in your case. > > > > > > Bryan > > > NOC Technician > > > COX Internet > > > > > > ----- Original Message ----- > > > From: "Jason P." <jjperc@petronet.net> > > > To: <usr-tc@lists.xmission.com> > > > Sent: Wednesday, January 19, 2000 10:10 AM > > > Subject: (usr-tc) D Channel Problem > > > > > > > I just installed our seventh Hiper DSP card into our chassis and the > > > > Loopback/D-Alarm LED on this card keeps alternating between green and > > > > red about every 30 seconds. I have this card set up exactly like the > > > > other cards in this chassis and the telco (supposedly) has this span > > > > setup the same way as all of our others. Does anyone have any insight > > > > into what could be going on? > > > > > > > > Here are my specs: > > > > > > > > T1 PRI > > > > Hiper DSP 2.0.81 > > > > Hiper ARC 4.1.59-6 > > > > Hiper NMC 6.1.17 > > > > > > > > Thanks in advance. > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: (usr-tc) SNMP response times...
From: Steve Creel <screel@nothinbut.net>
Date: 2000-01-23 13:51:29

When I pull SNMP info off of the NMC, the response is relatively quick, and definately livable. However, when I try to pull stuff from the hiperarc or netserver cards, it takes -forever-. Is there anything I can do to speed up the arc/ns responses? Is there a misconfiguration that could be causing the lagged response? Thx. ___________________________________________________________ Steve Creel Nothin But Net, LLC. screel@nothinbut.net

Subject: Re: (usr-tc) SNMP response times...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-23 22:11:49

Thus spake Steve Creel >When I pull SNMP info off of the NMC, the response is relatively quick, >and definately livable. However, when I try to pull stuff from the >hiperarc or netserver cards, it takes -forever-. *boggle* How are you getting this to happen? The SNMP agent on the Arc is *definitely* faster than that on (at least the 486 based) NMC cards. Moving to the HiPer NMC (pentium based) helps tremendously from what everyone has told me, but I still can't imagine it being faster than the Arc. The NETServer has little enough information in it that its of little consequence how fast it is. :) >Is there anything I can do to speed up the arc/ns responses? Is there >a misconfiguration that could be causing the lagged response? The only way I can think that you would get worse response to the Arc than to the NMC would be if you were using the relay functionality of the NMC to get to the Arc...then the request would be going through both the NMC and the Arc with the resultant slowdown. If this is the situation, then that makes sense, and the solution is to send the SNMP request to the Arc directly (use the Arc's IP address, not the NMC's in your SNMP util)... Only other possibility I can think of is that you have a very heavily loaded Arc...the fullest Arc I have is one with 5 DSP's on it (115 ports? did I calculate that right?), so if you have 14 DSP's running against one Arc...perhaps the Arc (correctly) prioritizes handling user connections higher than SNMP requests, with the result of the SNMP having poor performance on such a heavily loaded Arc...I've not seen any evidence of any slowdown on my most heavily loaded Arc, but I suppose its possible. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Equipment List Confirmation
From: albert <emmanuel@mwt.net>
Date: 2000-01-24 09:29:16

Christopher Knight [chris@isp-lists.com] the address above is to the owner to the list you ask about,you may want to write him? and on another note please set your email to put your email address in your post. albert. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of S O Okeyo > Sent: Monday, January 24, 2000 12:10 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Equipment List Confirmation > > > I am unable to mail confirmation message to the equipment list > administrator. I have typed OK ####### (identification number) on Subject > line without success. Can someone help please! > > Okeyo > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Bryan Wann <bwann@cwis.net>
Date: 2000-01-24 09:38:21

On Sun, 23 Jan 2000, Garlic wrote: > Before you go demand they do something, make sure you are not going to waste your > time. > > B8ZS is of no help on a CT1. The purpose of B8ZS is to ensure timing by preventing > lots of consecutive zeros on the line. This can't happen with a CT1. The control > bits in each channel will ensure enough ones density to maintain timing. > > ESF is better than D4 is you are doing monitoring of the line or are going to run > advanced diagnostics using test equipment. Not having ESF doesn't hurt untill you > have problems then its a benefit. The bad news is that ESF requires that both ends > of the line be ESF capable. Many switches aren't ESF capable on CT1s. Garlic, Thanks, this is exactly what I was needing to know; if I would be wasting my time for something that would have little noticable affect other than making me look [more] like an demanding, irate asshole telco customer. :-) --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-24 10:43:55

Thus spake Bryan Wann > Thanks, this is exactly what I was needing to know; if I would be >wasting my time for something that would have little noticable affect >other than making me look [more] like an demanding, irate asshole telco >customer. :-) I tend to be all for anything that causes ILECs problems, but this is one that I'd probably bypass. I might make a few calls and see if you can confirm that the switch really can't do B8ZS/ESF...then maybe make a few calls to various folks disparaging the telco for using outdated technology, then probably drop it. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Attributes needed
From: Brian <signal@shreve.net>
Date: 2000-01-24 15:48:55

Does anyone have these definitions they can send me from a dictionary? Mon Jan 24 15:44:06 2000: ERR: Attribute number 39000 (vendor 429) is not defined in your dictionary Mon Jan 24 15:44:07 2000: ERR: Attribute number 39049 (vendor 429) is not defined in your dictionary Mon Jan 24 15:44:08 2000: ERR: Attribute number 38998 (vendor 429) is not defined in your dictionary Mon Jan 24 15:44:18 2000: ERR: Attribute number 39001 (vendor 429) is not defined in your dictionary Mon Jan 24 15:44:18 2000: ERR: Attribute number 39051 (vendor 429) is not defined in your dictionary These are new attributes that weren't reporting in 4.1.59-6, now we switched to .22, and just trying to track these down. Thanks. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: (usr-tc) Trunk Side vs. Line Side
From: Jason W. <jaslist@iland.net>
Date: 2000-01-24 16:47:16

Does anyone know if there are other problems/issues with Line Side CT1's besides the additional digital to analog conversion. I know that this will disallow 33.6+ connections, will it cause other problems as well? Thanks! ***************************************** Jason Watkins jaslist@iland.net I-Land NOC Tech http://www.iland.net ***************************************** Fast, Dependable Access! *****************************************

Subject: Re: (usr-tc) Trunk Side vs. Line Side
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-24 16:57:26

When we first started over three years ago we had line side T1's for a few months. We experienced no ill effects other than the speed issues when the X2 release was made. It took a good bit of yelling at the telco to get them to admit that trunk side existed. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Monday, January 24, 2000 4:47 PM > Does anyone know if there are other problems/issues > with Line Side CT1's besides the additional digital to > analog conversion. I know that this will disallow 33.6+ > connections, will it cause other problems as well? > > Thanks! > > ***************************************** > Jason Watkins jaslist@iland.net > I-Land NOC Tech > http://www.iland.net > ***************************************** > Fast, Dependable Access! > ***************************************** > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Equipment List Confirmation
From: S O Okeyo <okeyoso@skyweb.co.ke>
Date: 2000-01-24 17:10:14

I am unable to mail confirmation message to the equipment list administrator. I have typed OK ####### (identification number) on Subject line without success. Can someone help please! Okeyo

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Aaron Nabil <nabil@spiritone.com>
Date: 2000-01-24 18:04:16

This isn't for garlic's benefit, as I don't interact or answer questions from people who won't post under their name. Life is too short to waste time on such foolishness. But since he's posting gobs of misinformation to the list, I'll explain for everyone else's benefit. First bit of misleading information is that the control (signalling) bits can somehow maintain ones density. It should be obvious to a anyone that this is impossible as the signalling bits need to have multiple values if they are going to signal anything. The only way the signalling bits could enforce ones density would be if they were always ones, and if the were, they wouldn't actually be able to signal anything. Second problem with the signalling bits is that they only occur every 6th and 12th frames. So even if they were always ones, they would only affect ones density during those frames. So "lots" (8) consecutive zero can and do occur on a CT1 line. Without B8ZS, the framer has to enforce ones density by stuffing ones, this causes a drop in the S/N ratio. (I seem to remember 4db as the figure, but I don't have any reference material in front of me to back that up.) B8ZS is able to handle these strings of zeros by inserting a bipolar violation that the receiver knows to remove. Since B8ZS doesn't have to force ones, it doesn't have the associated S/N degradation of AMI only. So try and get B8ZS if you can. On Sun, 23 Jan 2000, Garlic wrote: > > Before you go demand they do something, make sure you are not going to waste your > time. > > B8ZS is of no help on a CT1. The purpose of B8ZS is to ensure timing by preventing > lots of consecutive zeros on the line. This can't happen with a CT1. The control > bits in each channel will ensure enough ones density to maintain timing. > -- Aaron Nabil

Subject: (usr-tc) SNMP went away...
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-24 18:32:18

Ever since I upgraded my HiPer ARC, snmp didn't work, so I started poking around... The last release I had seemed to have it on by default, whereas this one (4.2.32-1) seems to not; although it did allow me to script my additions of communities and whatnot without any complaints. So I did a "add netWORK seRVICE snmp serVER_TYPE snmpd enABLED yes". But was still unable to get any data. Looked at it, and it showed this status: HiPer-1>> list network SERVICES CONFIGURED NETWORK SERVICES Server Admin Name Type Socket Close Status snmp SNMPD 161 FALSE DISABLED tftpd TFTPD 69 FALSE ENABLED telnetd TELNETD FALSE ENABLED Issued "enabLE netWORK serVICE snmp", and it still says "disabled". What am I missing here? The manual makes no mention of doing anything beyond adding the service and even states it should be enabled by default when added... Any clues? Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) SNMP went away...
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-24 19:01:52

Community names? Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Mon, 24 Jan 2000, Charles Sprickman wrote: > Ever since I upgraded my HiPer ARC, snmp didn't work, so I started poking > around... The last release I had seemed to have it on by default, whereas > this one (4.2.32-1) seems to not; although it did allow me to script my > additions of communities and whatnot without any complaints. > > So I did a "add netWORK seRVICE snmp serVER_TYPE snmpd enABLED yes". > > But was still unable to get any data. Looked at it, and it showed this > status: > > HiPer-1>> list network SERVICES > > CONFIGURED NETWORK SERVICES > Server Admin > Name Type Socket Close Status > snmp SNMPD 161 FALSE DISABLED > > tftpd TFTPD 69 FALSE ENABLED > > telnetd TELNETD FALSE ENABLED > > Issued "enabLE netWORK serVICE snmp", and it still says "disabled". What > am I missing here? The manual makes no mention of doing anything beyond > adding the service and even states it should be enabled by default when > added... > > Any clues? > > Thanks, > > Charles > > -- > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Attributes needed
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-24 19:03:41

http://www.dcr.net/~mandrews/usrtoys/dictionary.usr (this is for Cistron Radius but should get you close enough) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Mon, 24 Jan 2000, Brian wrote: > > Does anyone have these definitions they can send me from a dictionary? > > Mon Jan 24 15:44:06 2000: ERR: Attribute number 39000 (vendor 429) is not defined in your dictionary > Mon Jan 24 15:44:07 2000: ERR: Attribute number 39049 (vendor 429) is not defined in your dictionary > Mon Jan 24 15:44:08 2000: ERR: Attribute number 38998 (vendor 429) is not defined in your dictionary > Mon Jan 24 15:44:18 2000: ERR: Attribute number 39001 (vendor 429) is not defined in your dictionary > Mon Jan 24 15:44:18 2000: ERR: Attribute number 39051 (vendor 429) is not defined in your dictionary > > > These are new attributes that weren't reporting in 4.1.59-6, now we > switched to .22, and just trying to track these down. Thanks. > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Quad analog-digial modem cards not taking calls
From: mmm3@cornell.edu
Date: 2000-01-24 19:17:55

I have a chassis configured thusly (all cards have latest code): 1 Dual PRI 6 quad ana/digi modem cards 6 digital modem cards 2 HiPerDSPs 1 HiPerARC 1 NMC 2 PSUs Coming into the PRI card are two ISDN spans. Span2 is merrily taking calls; all 6 modem cards are filling up nicely. Span1 is NOT taking calls...none of the cards are in use. When the first span fills up, I tried dialing into the lead number and get a voice message "I'm sorry...we are unable to complete your call..." The only difference between the two sets of cards is what I noted above. The first six are analog/digital. Is it possible these cards are unable to receive calls from an ISDN? Thus far, I have: 1] Gone through *all* the settings, the only thing different was ISDN Modem Call Control Option/V110 Rate Adaption which was ENable on the ana/digi cards and DISabled on the digital cards. I disabled it on the ana/digi cards to no avail. 2] Then, I compared the settings for the two ISDNs on the PRI card. Nothing odd or out of wack there. 3] Then I got Bell Atlantic on the job looking to see if somehow the size of the pool got set back on their switch. Meanwhile, I though I'd ask the list and see if you all had any clues to pass me. Thanks! ********************************************************* Michelle M. Mogil Network and Computing Systems 721 Rhodes Hall, Cornell University, Ithaca, NY 14853 vox: (607) 255-0516, fax: (607) 255-8420 email: mmm3@cornell.edu **********************************************

Subject: Re: (usr-tc) SNMP went away...
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-24 20:16:45

No, I tried it also and : CONFIGURED NETWORK SERVICES Name Type Socket Close Status snmp SNMPD 161 FALSE DISABLED SNMP TRAP COMMUNITIES IP Address Community Pool Validate Address public 208.149.160.15 useAddress H running arc 4.1.22 NMC 6.2.17. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Mon, 24 Jan 2000, Mike Andrews wrote: > Community names? > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > "Don't sweat the petty things, and don't pet the sweaty things." > > On Mon, 24 Jan 2000, Charles Sprickman wrote: > > > Ever since I upgraded my HiPer ARC, snmp didn't work, so I started poking > > around... The last release I had seemed to have it on by default, whereas > > this one (4.2.32-1) seems to not; although it did allow me to script my > > additions of communities and whatnot without any complaints. > > > > So I did a "add netWORK seRVICE snmp serVER_TYPE snmpd enABLED yes". > > > > But was still unable to get any data. Looked at it, and it showed this > > status: > > > > HiPer-1>> list network SERVICES > > > > CONFIGURED NETWORK SERVICES > > Server Admin > > Name Type Socket Close Status > > snmp SNMPD 161 FALSE DISABLED > > > > tftpd TFTPD 69 FALSE ENABLED > > > > telnetd TELNETD FALSE ENABLED > > > > Issued "enabLE netWORK serVICE snmp", and it still says "disabled". What > > am I missing here? The manual makes no mention of doing anything beyond > > adding the service and even states it should be enabled by default when > > added... > > > > Any clues? > > > > Thanks, > > > > Charles > > > > -- > > =-----------------= = > > | Charles Sprickman Internet Channel | > > | INCH System Administration Team (212)243-5200 | > > | spork@inch.com access@inch.com | > > = =----------------= > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) SNMP went away...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-24 20:56:03

Thus spake Paul Farber >No, I tried it also and : >CONFIGURED NETWORK SERVICES >Name Type Socket Close Status >snmp SNMPD 161 FALSE DISABLED >SNMP TRAP COMMUNITIES >IP Address Community Pool Validate Address >public >208.149.160.15 useAddress >H >running arc 4.1.22 NMC 6.2.17. Looks like you configured the community names for your traps, but not for regular (client initiated) access. These are seperately configured...configuring one doesn't apply to the other. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) SNMP went away...
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-24 21:20:58

Hmm... I can snmpwalk the ARC card [farber@admin ]$ snmpwalk arc-ii XXXXXXXX | more system.sysDescr.0 = "3Com Corporation HiPer Access Router Card Built on Oct 22 1999 at 11:28:15." system.sysObjectID.0 = OID: enterprises.usRobotics.usrSysOIDs.usrHiPerArc system.sysUpTime.0 = Timeticks: (115566772) 13 days, 9:01:07.72 system.sysContact.0 = "Paul Farber" system.sysName.0 = "ARC-II" system.sysLocation.0 = "570-628-5303" system.sysServices.0 = 76 interfaces.ifNumber.0 = 220 interfaces.ifTable.ifEntry.ifIndex.1 = 1 interfaces.ifTable.ifEntry.ifIndex.2 = 2 interfaces.ifTable.ifEntry.ifIndex.3 = 3 interfaces.ifTable.ifEntry.ifIndex.4 = 4 interfaces.ifTable.ifEntry.ifIndex.5 = 5 interfaces.ifTable.ifEntry.ifIndex.6 = 6 interfaces.ifTable.ifEntry.ifIndex.7 = 7 interfaces.ifTable.ifEntry.ifIndex.8 = 8 interfaces.ifTable.ifEntry.ifIndex.9 = 9 interfaces.ifTable.ifEntry.ifIndex.10 = 10 interfaces.ifTable.ifEntry.ifIndex.11 = 11 interfaces.ifTable.ifEntry.ifIndex.12 = 12 even though the snmpd service is not running??? I will admit to not knowing much about the 'services'. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Mon, 24 Jan 2000, Jeff Mcadams wrote: > Thus spake Paul Farber > >No, I tried it also and : > > >CONFIGURED NETWORK SERVICES > >Name Type Socket Close Status > >snmp SNMPD 161 FALSE DISABLED > > >SNMP TRAP COMMUNITIES > >IP Address Community Pool Validate Address > >public > >208.149.160.15 useAddress > >H > > >running arc 4.1.22 NMC 6.2.17. > > Looks like you configured the community names for your traps, but not > for regular (client initiated) access. These are seperately > configured...configuring one doesn't apply to the other. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) SNMP went away...
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-24 21:33:15

Thus spake Paul Farber >Hmm... I can snmpwalk the ARC card Then everything is working on the Arc...go forth and be happy. :) Actually...it could mean that you have read-only access and not read-write...but the SNMP agent is running and responding at least. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) SNMP went away...
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-24 21:49:41

Yeah but it says disabled :( I don't really write to the ARC card at all.... so I'm not missing anything. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Mon, 24 Jan 2000, Jeff Mcadams wrote: > Thus spake Paul Farber > >Hmm... I can snmpwalk the ARC card > > Then everything is working on the Arc...go forth and be happy. :) > > Actually...it could mean that you have read-only access and not > read-write...but the SNMP agent is running and responding at least. :) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) SNMP went away...
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-24 21:52:30

At 09:33 PM 1/24/00 -0500, Jeff Mcadams wrote: >Thus spake Paul Farber >>Hmm... I can snmpwalk the ARC card > >Then everything is working on the Arc...go forth and be happy. :) > >Actually...it could mean that you have read-only access and not >read-write...but the SNMP agent is running and responding at least. :) SNMP doesn't even show up in my CONFIGURED NETWORK SERVICES, yet MRTG is pulling stats fine... -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000/886-2500 http://www.keyconn.net

Subject: Re: (usr-tc) HiPerDSP stops at 21
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-24 23:21:04

At , David Swearingin wrote: >I have one HiPER DSP that has 21 active calls and then returns a busy signal, >even though there should be three more modems available. Any suggestions as >to why this is happening? Sounds like you've got the "hung modem pair" syndrome. If you can figure out which modems are hung, soft busy them out through TCM to rool the calls to your next DSP. What I do then is wiat till off-peak and soft busy the rest of the card then reboot it once all callers are off of it. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000/886-2500 http://www.keyconn.net

Subject: Re: (usr-tc) SNMP went away...
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-24 23:45:50

I guess it's a combination of two things: I'd just moved these racks to new ips and had completely forgotten the snmp polling box has some ipfw rules on it that only allowed snmp from my old address block I was using. So after looking at all the router access lists and all I started digging through the arc v4.2 manual for snmp goodies, thinking the upgrade busted my snmp... That brought me to the "network services" stuff, which apparently is broken as far as telling you the state of snmpd... Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Mon, 24 Jan 2000, Paul Farber wrote: > No, I tried it also and : > > CONFIGURED NETWORK SERVICES > Name Type Socket Close Status > snmp SNMPD 161 FALSE DISABLED > > > SNMP TRAP COMMUNITIES > IP Address Community Pool Validate Address > public > 208.149.160.15 useAddress > H > > running arc 4.1.22 NMC 6.2.17. > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Mon, 24 Jan 2000, Mike Andrews wrote: > > > Community names? > > > > > > Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ > > VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY > > Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville > > "Don't sweat the petty things, and don't pet the sweaty things." > > > > On Mon, 24 Jan 2000, Charles Sprickman wrote: > > > > > Ever since I upgraded my HiPer ARC, snmp didn't work, so I started poking > > > around... The last release I had seemed to have it on by default, whereas > > > this one (4.2.32-1) seems to not; although it did allow me to script my > > > additions of communities and whatnot without any complaints. > > > > > > So I did a "add netWORK seRVICE snmp serVER_TYPE snmpd enABLED yes". > > > > > > But was still unable to get any data. Looked at it, and it showed this > > > status: > > > > > > HiPer-1>> list network SERVICES > > > > > > CONFIGURED NETWORK SERVICES > > > Server Admin > > > Name Type Socket Close Status > > > snmp SNMPD 161 FALSE DISABLED > > > > > > tftpd TFTPD 69 FALSE ENABLED > > > > > > telnetd TELNETD FALSE ENABLED > > > > > > Issued "enabLE netWORK serVICE snmp", and it still says "disabled". What > > > am I missing here? The manual makes no mention of doing anything beyond > > > adding the service and even states it should be enabled by default when > > > added... > > > > > > Any clues? > > > > > > Thanks, > > > > > > Charles > > > > > > -- > > > =-----------------= = > > > | Charles Sprickman Internet Channel | > > > | INCH System Administration Team (212)243-5200 | > > > | spork@inch.com access@inch.com | > > > = =----------------= > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Equipment List Confirmation
From: albert <emmanuel@mwt.net>
Date: 2000-01-25 01:01:31

please e mail me off list at: emmanuel@mwt.net or mailto:emmanuel@mwt.net albert. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of S O Okeyo > Sent: Tuesday, January 25, 2000 4:45 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Equipment List Confirmation > > > Thank you Albert, I'll contact the list owner. > > I do not understand what you mean by "set your e:mail to put your e:mail > address in your post". Please explain. And how do I do it? > > regards > > Okeyo. > > > At 09:29 AM 1/24/00 -0800, you wrote: > >Christopher Knight [chris@isp-lists.com] > > > >the address above is to the owner to the list you ask about,you > may want to > >write him? > >and on another note please set your email to put your email > address in your > >post. > > > >albert. > > > >> -----Original Message----- > >> From: owner-usr-tc@lists.xmission.com > >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of S O Okeyo > >> Sent: Monday, January 24, 2000 12:10 PM > >> To: usr-tc@lists.xmission.com > >> Subject: (usr-tc) Equipment List Confirmation > >> > >> > >> I am unable to mail confirmation message to the equipment list > >> administrator. I have typed OK ####### (identification number) > on Subject > >> line without success. Can someone help please! > >> > >> Okeyo > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) What Modem Ratio do you use?
From: Brian Gordon <administrator@westelcom.com>
Date: 2000-01-25 06:47:40

Has the industry changed the acceptable modem ratio or is it still 8.0? I'm curious to find out if it's changed due to changing usage demands. >Brian Gordon >MCP, A+, Network + >Network Administrator >Westelcom Internet >518.566.6726 Voice >419.831.9137 Fax >http://www.westelcom.com >administrator@westelcom.com

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-25 09:06:39

Thus spake Brian Gordon >Has the industry changed the acceptable modem ratio or is it still 8.0? I'm >curious to find out if it's changed due to changing usage demands. We don't monitor user-modem ratios...we just watch and as we start getting close to filling our lines we add more. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Modem ratio
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-25 09:19:53

This is a multi-part message in MIME format. ------=_NextPart_000_0031_01BF6715.568B3100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We have found that here in L.A. (Lower Arkansas) about the best we can = run is a 6.2/1 and not have busys. This seems to be the norm for Sept = thru May. During the summer months our usage drops dramatically due to = people being outdoors later, involved with summer activities etc. During = these months our ratio can go as high as 7.5/1 When we first went in = business other ISP's kept telling us as you get more and more customers = that ratio will increase. Well it really hasn't changed much since = getting our first couple hundred users. If anything it may have droped Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_0031_01BF6715.568B3100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>We have found that here in L.A. (Lower=20 Arkansas)   about the best we can run is a 6.2/1 and not have = busys.=20 This seems to be the norm for Sept thru May. During the summer months = our usage=20 drops dramatically due to people being outdoors later, involved with = summer=20 activities etc. During these months our ratio can go as high as = 7.5/1  When=20 we first went in business other ISP's kept telling us as you get more = and more=20 customers that ratio will increase. Well it really hasn't changed much = since=20 getting our first couple hundred users. If anything it may have=20 droped</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A>=20 </FONT></DIV></BODY></HTML> ------=_NextPart_000_0031_01BF6715.568B3100--

Subject: RE: (usr-tc) Equipment List Confirmation
From: S O Okeyo <okeyoso@skyweb.co.ke>
Date: 2000-01-25 09:45:13

Thank you Albert, I'll contact the list owner. I do not understand what you mean by "set your e:mail to put your e:mail address in your post". Please explain. And how do I do it? regards Okeyo. At 09:29 AM 1/24/00 -0800, you wrote: >Christopher Knight [chris@isp-lists.com] > >the address above is to the owner to the list you ask about,you may want to >write him? >and on another note please set your email to put your email address in your >post. > >albert. > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of S O Okeyo >> Sent: Monday, January 24, 2000 12:10 PM >> To: usr-tc@lists.xmission.com >> Subject: (usr-tc) Equipment List Confirmation >> >> >> I am unable to mail confirmation message to the equipment list >> administrator. I have typed OK ####### (identification number) on Subject >> line without success. Can someone help please! >> >> Okeyo >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-25 09:57:31

OK...you're closer than Garlic Whatziname...but still not quite there. :) I wish, I wish, I wish I knew of an online source for this printout that I have in my hand...its *very* instructive about how T1's work...but alas, you all will have to deal with my summarization. :) This just in <sound of teletype here>...found it online :) http://duracef.shout.net/~wildixon/telecom/t1/t1.html Thus spake Aaron Nabil >Second problem with the signalling bits is that they only occur every 6th >and 12th frames. So even if they were always ones, they would only affect >ones density during those frames. Correct so far (assuming D4 framing of course...which is what was being discussed, so a good assumption :) >So "lots" (8) consecutive zero can and do occur on a CT1 line. Depends on the application. With voice calls in the DS0's, the encoding of the voice data into the DS0's actually enforces one's density inherently. The encoding algorithm won't generate bit patterns that don't meet one's density requirements. >Without B8ZS, the framer has to enforce ones density by stuffing ones, >this causes a drop in the S/N ratio. (I seem to remember 4db as the >figure, but I don't have any reference material in front of me to back >that up.) I don't know what it translates into as far as a db loss, but it eats up one out of every eight bits of data meaning a loss of 192kbps on a T1 total...dropping the total useable bandwidth to 1.344Mbps >B8ZS is able to handle these strings of zeros by inserting a bipolar >violation that the receiver knows to remove. Actually, its two bipolar violations in a specific pattern...but you had the right idea. :) The specific pattern is 00011011, with BPV's at the 4th and 7th bits. >Since B8ZS doesn't have to force ones, it doesn't have the associated >S/N degradation of AMI only. Actually...AMI doesn't have any S/N degradation. I think you're thinking of ZCS, or Zero Code Substitution (I've also seen it referred to as simply "Ones Insertion"). Basically, with ZCS, the equipment jams a bit to one to enforce the one's density...of course the receiving equipment doesn't have any way to tell whether this bit was on because of the data or because of the need to maintain one's density, so you basically just cannot put any data into the bit used like this...this drops the data rate down to 1.344Mbps as above. Again, with voice encoding, neither ZCS or B8ZS is really needed as the encoding won't generate codes that don't meet one's density requirements...its when you get into data transmision that you have to be concerned about one's density since that can generate all zero's. AMI, for what its worth, is pretty much universal on all T1's. Basically, all AMI (Alternate Mark Inversion) means is that a "mark" or one bit, has the opposite voltage polarity from the previous mark or one bit. If two successive marks (with 0 or more interveaning spaces or zero bits) have the same voltage polarity, then you have a BiPolar Violation (BPV). As you can see...since B8ZS uses BPV's to indicate an all zero timeslot, B8ZS assumes AMI. :) >So try and get B8ZS if you can. If you're only running voice calls...B8ZS isn't really needed...now, having ZCS enabled (as our telco did on some of their trunks at one point) can cause some problems since that fairly significantly cuts down the total bandwidth...you're gonna see speed drops in that case. But as long as ZCS is off, you should be OK as far as transmission speeds even without B8ZS. As someone else mentioned...if you have problems B8ZS and ESF will be nice to have as they do have some trouble-shooting capabilities...but in general operation...its not really a problem if all you're doing is voice calls. Now, when you go to ISDN PRI, you have to have B8ZS with ESF because at that point you're encoding data onto the circuit which can result in all-zero timeslots. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-25 09:58:25

Do you patrol the modem usage to control abusers in any way? If so, how do you implement it in a positive way that doesn't offend the customers? I'm asking because this has become a bit of a problem with a few users who have decided that "unlimited" means just that. We do have an AUP that defines acceptable usage but I try to avoid being heavy handed with the clients. I don't really want session limits because I understand someone may need 24 hours to download the entire Linux anthology or NT upgrade and getting kicked off would be inappropriate. We are surviving with an 8:1 ratio at this time, but the ratio does seem to be declining slowly. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Tuesday, January 25, 2000 8:06 AM > Thus spake Brian Gordon > >Has the industry changed the acceptable modem ratio or is it still 8.0? I'm > >curious to find out if it's changed due to changing usage demands. > > We don't monitor user-modem ratios...we just watch and as we start > getting close to filling our lines we add more. > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Aaron Nabil <nabil@spiritone.com>
Date: 2000-01-25 10:21:17

On Tue, 25 Jan 2000, Jeff Mcadams wrote: > OK...you're closer than Garlic Whatziname...but still not quite there. > :) I wish, I wish, I wish I knew of an online source for this printout > that I have in my hand...its *very* instructive about how T1's > work...but alas, you all will have to deal with my summarization. :) > > This just in <sound of teletype here>...found it online :) > http://duracef.shout.net/~wildixon/telecom/t1/t1.html > > Thus spake Aaron Nabil > >Second problem with the signalling bits is that they only occur every 6th > >and 12th frames. So even if they were always ones, they would only affect > >ones density during those frames. > > Correct so far (assuming D4 framing of course...which is what was being > discussed, so a good assumption :) Gee, thanks. Nice to know that "I'm closer than Garlic Whatziname", and that I haven't managed to make any major blunders in my first sentence. I don't know why you'd say "assuming D4 of course" as RBS occurs at the same rate in both D4 and ESF. > >So "lots" (8) consecutive zero can and do occur on a CT1 line. > > Depends on the application. With voice calls in the DS0's, the encoding > of the voice data into the DS0's actually enforces one's density > inherently. The encoding algorithm won't generate bit patterns that > don't meet one's density requirements. Are you talking about CCITT mu-law encoding? Sure, CCITT mu-law enforces ones-density IN A SINGLE PCM CHANNEL. But when you stack mulitple channels together into a T1, how is one PCM channel supposed to know what's in the next channel? Well, it doesn't, and it's trivial to violate ones density with something like +127 in the DS0 1 (1000 0000) and -126 (0000 0010) in DS0 2, as they are simply catenated together in the T1 frame. 1000 0000 0000 0010 has a run of 13 zeros. > > >Without B8ZS, the framer has to enforce ones density by stuffing ones, > >this causes a drop in the S/N ratio. (I seem to remember 4db as the > >figure, but I don't have any reference material in front of me to back > >that up.) > > I don't know what it translates into as far as a db loss, but it eats up > one out of every eight bits of data meaning a loss of 192kbps on a T1 > total...dropping the total useable bandwidth to 1.344Mbps It only "eats" that bit in DATA. In voice (modems), that bit is still there, it's just noisy. > > >B8ZS is able to handle these strings of zeros by inserting a bipolar > >violation that the receiver knows to remove. > > Actually, its two bipolar violations in a specific pattern...but you had > the right idea. :) The specific pattern is 00011011, with BPV's at the > 4th and 7th bits. Yeah, I was simplifying. In the context of the original message, I didn't see any value in driving home and looking up the exact substitution value in a reference book or on the web. Obviously you did. Good for you. > > >Since B8ZS doesn't have to force ones, it doesn't have the associated > >S/N degradation of AMI only. > > Actually...AMI doesn't have any S/N degradation. I think you're > thinking of ZCS, or Zero Code Substitution (I've also seen it referred > to as simply "Ones Insertion"). Basically, with ZCS, the equipment jams > a bit to one to enforce the one's density...of course the receiving > equipment doesn't have any way to tell whether this bit was on because > of the data or because of the need to maintain one's density, so you > basically just cannot put any data into the bit used like this...this drops > the data rate down to 1.344Mbps as above. I'm "thinking" of the two alternatives the original author had available to him, a CT1 with B8ZS or without B8ZS (AMI only). One has a poorer S/N than the other. Your definition of ZCS (Zero code _supression_) would best be forgotten. > Again, with voice encoding, > neither ZCS or B8ZS is really needed as the encoding won't generate > codes that don't meet one's density requirements...its when you get into > data transmision that you have to be concerned about one's density since > that can generate all zero's. You are simply wrong. You are again confusing ones density in a single PCM channel with ones density in the T1 frame. > . . . Jeff, it's simply marvellous that you are able to use a search engine and come up with these "answers". In fact, it's a skill that I've wished would be more commonplace on a majority of mailing lists (especially inet-access). But in future, note that there is a difference between "knowing where to find something" and "knowing something". Both very useful, but in this case you are in the former category, not the latter. -- Aaron Nabil

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-25 10:24:43

> Well...first off, we make sure we don't use the term "unlimited" in any > of our marketing material. :) Neither do we. We use the term flatrate, but the general population seems to translate that on the fly. > We do have session limits at 12 hours I think. We very rarely, if ever, That sounds reasonable. I may add that to our system. > Most things that would require that > much download time can be done in chunks, not all at once. > Alternatively...many sites support "reget" now in ftp, so that takes > care of the problem as well. :) I had forgotten about that added functionality. Do you ever proactively ask an abuser to find another provider? Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-25 10:32:23

I thought the industry standard was 10.0 not 8.0... but that would explain why we've always had to run at about 7 to 7.5 here... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Tue, 25 Jan 2000, Brian Gordon wrote: > Has the industry changed the acceptable modem ratio or is it still 8.0? I'm > curious to find out if it's changed due to changing usage demands. > > >Brian Gordon > >MCP, A+, Network + > >Network Administrator > >Westelcom Internet > >518.566.6726 Voice > >419.831.9137 Fax > >http://www.westelcom.com > >administrator@westelcom.com > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Quad ana/dig modem not taking calls (another case of)
From: mmm3@cornell.edu
Date: 2000-01-25 10:43:12

Gah!!! I'm in the switchroom, ready to swap out the dual PRI card. You think I should instead swap the ana/digi modem cards??? Hmmm...I'm going to try the PRI first since, if the cards aren't taking calls anyway, I can always go back and swap them tonight... On Tue, 25 Jan 2000, Dan Borlovan wrote: > > Hello, > > I have a totalcontrol chassis with the following cards: > > - 1 dual e1/cas > - 8 digital quad modems > - 6 analog/digital quad modems > - 1 hiper arc > - 1 hiper nmc (p5nmc) > > All cards have at least tcs3.5 software > > Modem signal source is pritdm. > > The dual/e1 card recognizes the modem cards. > > I have 2 E1 (30 channels) active. The problem is that the ana/dig modems > do not take calls. All modems (both dig and ana/dig) have the same > configuration. > > What seems to happen: > > - a call arives; the dual/e1 tries to communicate with the modem (status > is 'dialling-in'); after about 10s failes and the caller gets a busy > signal from the telco. Meantime modem shows no reaction (doesn't go > off-hook) > > What was tried: > > - software reset, hardware reset, chassis powerdown/powerup > - reinserting modem cards > - chaging modem cards > - changing modem source from pritdm to nic, inserting an analog line and > making a call works - so the modem and the harc are fine > - swapping slot positions for dig and ana/dig modems - the dig modems > take calls, the ana/dig don't > > The same configuration seems to work in other places using same hardware. > > If you have any suggestion, I'll be glad to try. If needed I can provide > debug from the dual/e1 card (the ctrl/d menu), just tell me which debug > options to enable. > > Thanks, > > Dan > -- > Dan Borlovan <danb@dnttm.ro> > System Administrator, Network Operation Center > Dynamic Network Technologies - Timisoara, Romania > Telefon: +40-56-204967 FAX: +40-56-220201 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiPerDSP stops at 21
From: David Swearingin <david@carolnet.com>
Date: 2000-01-25 10:56:53

At 11:50 AM 1/25/2000 -0500, you wrote: >Have telco check the hunting. If it's a 'fast' busy its thier end. If >it's a 'normal' busy check the timeslot mapping and that the modems are >'on hook' and ready to take a call. > >Paul Farber Paul, From my home last night, it sounded like a normal busy signal. Where do I check the 'timeslot mapping'? David __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

Subject: (usr-tc) snmp management question
From: Chris Hanes <chanes@usacars.com>
Date: 2000-01-25 11:17:44

What kind of approaches are people taking to managing their total control units? I know MRTG is popular and that there are many perl scripts out there to analyze syslogs. What tools beyond this do administrators typically use? Also, what are the usual variables, people are using MRTG to track? Currently, I just track bandwidth usage, modem line states, total modem utilization, ping times. I'm wondering what things I'm missing that I should be tracking. Thanks, Chris Hanes Network Admin Internet Connections

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-25 11:27:24

Thus spake Mark Thornton >Do you patrol the modem usage to control abusers in any way? If so, how >do you implement it in a positive way that doesn't offend the >customers? I'm asking because this has become a bit of a problem with a >few users who have decided that "unlimited" means just that. Well...first off, we make sure we don't use the term "unlimited" in any of our marketing material. :) >We do have an AUP that defines acceptable usage but I try to avoid >being heavy handed with the clients. I don't really want session limits >because I understand someone may need 24 hours to download the entire >Linux anthology or NT upgrade and getting kicked off would be >inappropriate. We are surviving with an 8:1 ratio at this time, but >the ratio does seem to be declining slowly. We do have session limits at 12 hours I think. We very rarely, if ever, have any complaints about them. What we've found, is that of the people that do complain about them, they're generally the people that are trying to make a $19.95/month account function as a dedicated line...thus we're loosing money on them and if they get ticked off at us and leave...its no loss to us...that frees our modems up for other customers that *do* make us money. Most things that would require that much download time can be done in chunks, not all at once. Alternatively...many sites support "reget" now in ftp, so that takes care of the problem as well. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) SNMP went away...
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-25 11:30:28

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell |Sent: Monday, January 24, 2000 8:52 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) SNMP went away... | | |At 09:33 PM 1/24/00 -0500, Jeff Mcadams wrote: |>Thus spake Paul Farber |>>Hmm... I can snmpwalk the ARC card |> |>Then everything is working on the Arc...go forth and be happy. :) |> |>Actually...it could mean that you have read-only access and not |>read-write...but the SNMP agent is running and responding at least. :) | |SNMP doesn't even show up in my CONFIGURED NETWORK SERVICES, yet MRTG is |pulling stats fine... | The SNMPD network service is not currently used by the Hiper ARC. Configuring it has nothing to do with being able to use SNMP on the HARC. All that is required is setting up the proper community strings. You DO NOT need to add the service. -M

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-25 11:45:59

Thus spake Mark Thornton >Do you ever proactively ask an abuser to find another provider? Not as such...we will occasionally tell a user that to continue service with us, we'll have to switch the account to a dedicated account...which amounts to the same thing, but can't really be construed as kicking them off. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiPerDSP stops at 21
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-25 11:50:11

Have telco check the hunting. If it's a 'fast' busy its thier end. If it's a 'normal' busy check the timeslot mapping and that the modems are 'on hook' and ready to take a call. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Mon, 24 Jan 2000, David Swearingin wrote: > I have one HiPER DSP that has 21 active calls and then returns a busy signal, > even though there should be three more modems available. Any suggestions as > to why this is happening? > > David > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Aaron Nabil <nabil@spiritone.com>
Date: 2000-01-25 12:11:36

On Tue, 25 Jan 2000, Jeff Mcadams wrote: > Thus spake Aaron Nabil > >Gee, thanks. Nice to know that "I'm closer than Garlic Whatziname", > >and that I haven't managed to make any major blunders in my first > >sentence. > > >I don't know why you'd say "assuming D4 of course" as RBS occurs at the > >same rate in both D4 and ESF. > > Yeah...my apologies...mostly it was terminology thing. Of course the > RBS occurs at the same rate in SF and ESF...didn't mean to imply > otherwise. :) Just that it would occur at the 6th, 12th, 18th, and > 24th frame in ESF since ESF has 24 frames compared to SF's 12. Same > diff really...mostly a terminology thing. > > >Are you talking about CCITT mu-law encoding? Sure, CCITT mu-law > >enforces ones-density IN A SINGLE PCM CHANNEL. But when you stack > >mulitple channels together into a T1, how is one PCM channel supposed > >to know what's in the next channel? Well, it doesn't, and it's trivial > >to violate ones density with something like +127 in the DS0 1 (1000 > >0000) and -126 (0000 0010) in DS0 2, as they are simply catenated > >together in the T1 frame. 1000 0000 0000 0010 has a run of 13 zeros. > > Uhm...ones-density requires no more than 15 consecutive zero's, so your > run of 13 is fine. It also requires an minimum average of 12.5% of ones > (I don't know the period over which this average applies), which is > where the one in eight idea comes from I believe. The original T1 spec was 3 ones in 24 bits, with no more than 15 zeros. But the AT&T spec, (ie, the defacto standard) requires one pulse every 8 bits, not just 3 every 24. > >It only "eats" that bit in DATA. In voice (modems), that bit is still > >there, it's just noisy. > > True...the bit is still interpretted in voice applications...so its not > eaten per se...effectively, however, the bit is unuseable for practical > purposes...that's all I was trying to say there. The application in question _was_ a voice application, where it's perfectly usable. Surprising enough, the majority of T1's in the world are carrying voice, so I would hardly call that bit "unusable for practical purposes". > >Yeah, I was simplifying. In the context of the original message, I > >didn't see any value in driving home and looking up the exact > >substitution value in a reference book or on the web. Obviously you > >did. Good for you. > > Actually I waited until I got back to work since all my reference > material was at work...I didn't wait just so I could put the B8ZS > pattern though...I wanted to confirm a few other things. :) > > >Your definition of ZCS (Zero code _supression_) would best be > >forgotten. > > Dang...got that one wrong...my apologies...right idea...wrong acronym > expansion. The reason I said it should be forgotten was because it is a term that has different meaning in different contexts, of which your example would almost always be the LEAST likely to be what someone meant. Most typically by ZCS people are referring to "a ZCS technique" like B8ZS, ZBTSI or HDB3, not one-stuffing done by a CSU. -- Aaron Nabil

Subject: RE: (usr-tc) billing software
From: Aaron Nabil <nabil@spiritone.com>
Date: 2000-01-25 12:16:14

On Tue, 25 Jan 2000, Lon R. Stockton, Jr. wrote: > On Tue, 25 Jan 2000, Stainforth, Matthew wrote: > > > A company tried to pitch a package to us that used telnet to check > > periodically. *gag* > > This reminds me of something I forgot to mention in my previous > message. > > There's a radius server called Radiator which maintains a current- > calls database for concurrency checking; it updates it with the > accounting-start & stop records. To alleviate problems with lost > packets causing it to get out of sync, it periodically checks the > hub via SNMP and compares who's really on with who it thinks is > logged on. > > Pretty spiffy, if you ask me. It is spiffy, but it's doesn't periodically check with the hub to see who's logged on (at least it doesn't in my version, I am running one rev back). Only when it's about to deny someone a login because they are exceeding their max session count does it go out and look to see if the other sessions are still up. Since radiator is single threaded, I'd think this could really cause a problem if the check is slow or hangs. -- Aaron Nabil

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-25 12:17:33

On Tue, 25 Jan 2000, Jeff Mcadams wrote: > We don't monitor user-modem ratios...we just watch and as we start > getting close to filling our lines we add more. That's what we do here. And over the past few years, I've noticed that more-lines-time happens as the ratio approaches 8/1. 7-7.5 seems to be the sweet spot where nobody gets (unreasonable) busy signals yet there's good utilization of the lines. [when I talk about reasonable busy signals, I'm meaning that sure, they *occasionally* get a busy, but an *immediate* redial gets 'em in] Then again, we don't play that silly 'unlimited' marketing game where we say it but don't mean it. We set a soft limit of 150/hours per month; if they go over, they get another $10 tacked onto their bill (which gives 'em another 100 hour block. Cycle repeats at 250, etc). Sure, a (very) few potential customers don't sign up because we won't say unlimited, but in my experience they're the PIA's anyway. Most of 'em see the light when we mention that 150 hours/month is about 5 hours per day, every single day, and they realize that they won't use anywhere near that. And I get a marketing bonus as well. No extra charge for multi-channel use. Hook up that shotgun modem. Feel free to log on at work while your family is also connected at home...I don't care, each channel just adds to their limit (2channels for 1 hour == 2hours). No headaches for me policing simultaneous use, and I actually like it when people want to stay on 24x7. *grin* Not to mention that I don't have to have any strange clauses in my contracts which attempt to redefine what 'unlimited' means, or force my opinions on what constitutes a valid connection.

Subject: (usr-tc) More on connect times
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-25 12:19:18

Hello all, I've got some more info on the connect/disonnect issue with TC. Right now I'm running a mix of 2.0.19 and 2.0.80 (70/30 mix) and going back to 2.0.19 seems to have helped. There is a significant drop in the number or 00:00, 00:01 and 00:02 length calls (1243 for pure .80 and 870 for the .19/.80 mix -- 373 difference) while the total volume of calls is only different by 200. Here's a list of login times with pure 2.0.80 code: Date Tue Jan 18 Time calls %of total 00:00 466 13.0 00:01 262 7.3 00:02 515 14.4 00:03 89 2.5 00:04 75 2.1 00:05 97 2.7 00:06 60 1.7 00:07 78 2.2 00:08 40 1.1 00:09 50 1.4 00:10 48 1.3 00:11 49 1.4 00:12 41 1.1 00:13 40 1.1 00:14 43 1.2 00:15 39 1.1 00:16 24 0.7 00:17 25 0.7 00:18 43 1.2 00:19 25 0.7 00:20 67 1.9 00:21 37 1.0 00:22 30 0.8 00:23 35 1.0 00:24 29 0.8 00:25 32 0.9 00:26 27 0.8 00:27 26 0.7 00:28 24 0.7 00:29 22 0.6 00:30 25 0.7 00:31 24 0.7 00:32 26 0.7 00:33 17 0.5 00:34 22 0.6 00:35 17 0.5 00:36 15 0.4 00:37 24 0.7 00:38 22 0.6 00:39 15 0.4 00:40 25 0.7 00:41 22 0.6 00:42 13 0.4 00:43 12 0.3 00:44 21 0.6 00:45 11 0.3 00:46 14 0.4 00:47 21 0.6 00:48 19 0.5 00:49 9 0.3 00:50 27 0.8 00:51 9 0.3 00:52 12 0.3 00:53 15 0.4 00:54 11 0.3 00:55 14 0.4 00:56 11 0.3 00:57 14 0.4 00:58 5 0.1 00:59 18 0.5 01:00 16 0.4 01:01 10 0.3 01:02 7 0.2 01:03 9 0.3 01:04 6 0.2 01:05 9 0.3 01:06 10 0.3 01:07 9 0.3 01:08 9 0.3 01:09 6 0.2 01:10 9 0.3 01:11 9 0.3 01:12 8 0.2 01:13 9 0.3 01:14 7 0.2 01:15 7 0.2 01:16 8 0.2 01:17 8 0.2 01:18 4 0.1 01:19 11 0.3 01:20 8 0.2 01:21 7 0.2 01:22 11 0.3 01:23 7 0.2 01:24 6 0.2 01:25 7 0.2 01:26 5 0.1 01:27 5 0.1 01:28 3 0.1 01:29 7 0.2 01:30 3 0.1 01:31 2 0.1 01:32 1 0.0 01:33 2 0.1 01:34 9 0.3 01:35 6 0.2 01:36 1 0.0 01:37 6 0.2 01:38 2 0.1 01:39 7 0.2 01:40 1 0.0 01:41 5 0.1 01:42 3 0.1 01:43 3 0.1 01:44 3 0.1 01:45 5 0.1 01:46 7 0.2 01:47 3 0.1 01:48 4 0.1 01:49 1 0.0 01:50 4 0.1 01:52 3 0.1 01:53 5 0.1 01:54 1 0.0 01:55 4 0.1 01:56 1 0.0 01:57 3 0.1 01:58 4 0.1 01:59 3 0.1 02:00 2 0.1 02:01 6 0.2 02:02 1 0.0 02:03 4 0.1 02:04 1 0.0 02:05 1 0.0 02:06 3 0.1 02:07 5 0.1 02:08 1 0.0 02:09 1 0.0 02:10 1 0.0 02:11 6 0.2 02:12 3 0.1 02:13 2 0.1 02:14 1 0.0 02:16 4 0.1 02:17 3 0.1 02:18 2 0.1 02:19 2 0.1 02:20 1 0.0 02:21 2 0.1 02:22 3 0.1 02:23 2 0.1 02:24 3 0.1 02:25 4 0.1 02:26 6 0.2 02:27 1 0.0 02:28 2 0.1 02:29 4 0.1 02:30 2 0.1 02:31 2 0.1 02:32 1 0.0 02:33 1 0.0 02:34 1 0.0 02:35 2 0.1 02:36 1 0.0 02:37 2 0.1 02:38 4 0.1 02:42 2 0.1 02:43 1 0.0 02:44 2 0.1 02:45 1 0.0 02:47 5 0.1 02:49 1 0.0 02:51 1 0.0 02:52 1 0.0 02:53 2 0.1 02:54 1 0.0 02:55 2 0.1 02:56 1 0.0 02:58 2 0.1 03:02 1 0.0 03:03 2 0.1 03:08 3 0.1 03:11 2 0.1 03:16 2 0.1 03:17 3 0.1 03:19 1 0.0 03:20 1 0.0 03:21 1 0.0 03:23 3 0.1 03:24 2 0.1 03:27 1 0.0 03:28 1 0.0 03:30 1 0.0 03:31 2 0.1 03:32 2 0.1 03:33 3 0.1 03:34 2 0.1 03:37 1 0.0 03:41 1 0.0 03:43 2 0.1 03:44 2 0.1 03:46 1 0.0 03:47 1 0.0 03:51 1 0.0 03:52 1 0.0 03:53 1 0.0 03:54 2 0.1 03:55 1 0.0 03:56 1 0.0 03:57 1 0.0 04:03 1 0.0 04:04 1 0.0 04:07 1 0.0 04:08 1 0.0 04:11 1 0.0 04:12 2 0.1 04:14 1 0.0 04:16 1 0.0 04:18 1 0.0 04:19 1 0.0 04:20 1 0.0 04:25 1 0.0 04:29 1 0.0 04:30 1 0.0 04:31 2 0.1 04:33 1 0.0 04:37 2 0.1 04:39 1 0.0 04:40 1 0.0 04:44 1 0.0 04:45 1 0.0 04:49 1 0.0 04:52 2 0.1 04:53 1 0.0 05:07 1 0.0 05:08 1 0.0 05:10 1 0.0 05:16 1 0.0 05:20 1 0.0 05:23 1 0.0 05:28 1 0.0 05:29 2 0.1 05:32 1 0.0 05:38 1 0.0 05:44 2 0.1 05:47 1 0.0 05:49 1 0.0 05:50 1 0.0 05:52 1 0.0 05:57 1 0.0 06:00 69 1.9 06:01 3 0.1 09:21 1 0.0 10:44 1 0.0 Total calls: 3571 Here's the same list with a mix of 2.0.19 and 2.0.80 Date Mon Jan 24 Time calls %of calls 00:00 188 5.6 00:01 219 6.5 00:02 463 13.8 00:03 115 3.4 00:04 89 2.7 00:05 108 3.2 00:06 64 1.9 00:07 66 2.0 00:08 44 1.3 00:09 59 1.8 00:10 39 1.2 00:11 45 1.3 00:12 48 1.4 00:13 38 1.1 00:14 43 1.3 00:15 45 1.3 00:16 32 1.0 00:17 29 0.9 00:18 26 0.8 00:19 29 0.9 00:20 62 1.8 00:21 52 1.5 00:22 40 1.2 00:23 40 1.2 00:24 27 0.8 00:25 27 0.8 00:26 29 0.9 00:27 30 0.9 00:28 17 0.5 00:29 29 0.9 00:30 21 0.6 00:31 29 0.9 00:32 25 0.7 00:33 20 0.6 00:34 31 0.9 00:35 29 0.9 00:36 18 0.5 00:37 23 0.7 00:38 25 0.7 00:39 20 0.6 00:40 18 0.5 00:41 13 0.4 00:42 11 0.3 00:43 13 0.4 00:44 21 0.6 00:45 20 0.6 00:46 24 0.7 00:47 15 0.4 00:48 19 0.6 00:49 17 0.5 00:50 17 0.5 00:51 20 0.6 00:52 10 0.3 00:53 15 0.4 00:54 13 0.4 00:55 22 0.7 00:56 15 0.4 00:57 16 0.5 00:58 14 0.4 00:59 15 0.4 01:00 14 0.4 01:01 13 0.4 01:02 12 0.4 01:03 13 0.4 01:04 11 0.3 01:05 11 0.3 01:06 14 0.4 01:07 11 0.3 01:08 9 0.3 01:09 13 0.4 01:10 8 0.2 01:11 13 0.4 01:12 2 0.1 01:13 8 0.2 01:14 5 0.1 01:15 10 0.3 01:16 9 0.3 01:17 5 0.1 01:18 7 0.2 01:19 4 0.1 01:20 2 0.1 01:21 12 0.4 01:22 5 0.1 01:23 6 0.2 01:24 5 0.1 01:25 6 0.2 01:26 2 0.1 01:27 3 0.1 01:28 4 0.1 01:29 6 0.2 01:30 6 0.2 01:31 11 0.3 01:32 8 0.2 01:33 4 0.1 01:34 7 0.2 01:35 5 0.1 01:36 2 0.1 01:37 3 0.1 01:38 4 0.1 01:39 5 0.1 01:40 8 0.2 01:41 5 0.1 01:42 4 0.1 01:43 2 0.1 01:44 4 0.1 01:45 4 0.1 01:46 2 0.1 01:47 3 0.1 01:48 5 0.1 01:49 4 0.1 01:50 4 0.1 01:51 3 0.1 01:52 2 0.1 01:53 5 0.1 01:54 1 0.0 01:55 2 0.1 01:56 2 0.1 01:57 1 0.0 01:58 1 0.0 01:59 4 0.1 02:01 3 0.1 02:02 4 0.1 02:03 1 0.0 02:04 4 0.1 02:05 4 0.1 02:06 2 0.1 02:07 3 0.1 02:08 3 0.1 02:09 5 0.1 02:10 3 0.1 02:11 1 0.0 02:12 1 0.0 02:13 1 0.0 02:14 5 0.1 02:16 1 0.0 02:17 3 0.1 02:18 1 0.0 02:19 3 0.1 02:20 6 0.2 02:21 4 0.1 02:22 1 0.0 02:23 1 0.0 02:24 1 0.0 02:25 1 0.0 02:26 2 0.1 02:27 4 0.1 02:29 2 0.1 02:30 5 0.1 02:31 4 0.1 02:32 1 0.0 02:33 1 0.0 02:34 4 0.1 02:36 2 0.1 02:37 1 0.0 02:38 3 0.1 02:39 6 0.2 02:40 3 0.1 02:42 1 0.0 02:43 4 0.1 02:46 2 0.1 02:47 1 0.0 02:48 1 0.0 02:49 4 0.1 02:51 1 0.0 02:52 1 0.0 02:53 2 0.1 02:54 1 0.0 02:56 1 0.0 02:57 2 0.1 03:01 1 0.0 03:02 2 0.1 03:03 2 0.1 03:04 1 0.0 03:05 3 0.1 03:06 2 0.1 03:07 1 0.0 03:08 5 0.1 03:09 1 0.0 03:11 1 0.0 03:14 1 0.0 03:15 2 0.1 03:20 1 0.0 03:21 1 0.0 03:22 1 0.0 03:24 2 0.1 03:25 1 0.0 03:27 1 0.0 03:29 1 0.0 03:30 1 0.0 03:31 1 0.0 03:32 1 0.0 03:33 1 0.0 03:35 1 0.0 03:36 1 0.0 03:38 2 0.1 03:39 2 0.1 03:40 1 0.0 03:41 1 0.0 03:44 1 0.0 03:45 1 0.0 03:48 4 0.1 03:49 1 0.0 03:50 3 0.1 03:51 2 0.1 03:52 1 0.0 03:53 2 0.1 03:56 2 0.1 03:57 1 0.0 03:58 1 0.0 04:04 2 0.1 04:06 2 0.1 04:08 1 0.0 04:09 1 0.0 04:10 2 0.1 04:11 1 0.0 04:14 1 0.0 04:15 1 0.0 04:16 1 0.0 04:19 1 0.0 04:21 1 0.0 04:22 1 0.0 04:27 1 0.0 04:29 1 0.0 04:32 2 0.1 04:40 1 0.0 04:41 1 0.0 04:42 1 0.0 04:44 1 0.0 04:45 1 0.0 04:47 1 0.0 04:51 2 0.1 04:55 1 0.0 04:56 2 0.1 04:59 1 0.0 05:00 1 0.0 05:03 3 0.1 05:05 1 0.0 05:06 1 0.0 05:07 1 0.0 05:09 1 0.0 05:12 2 0.1 05:17 1 0.0 05:18 1 0.0 05:21 1 0.0 05:23 1 0.0 05:27 1 0.0 05:48 1 0.0 05:59 1 0.0 06:00 50 1.5 06:01 2 0.1 08:26 1 0.0 Total calls: 3358 Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-25 12:24:40

At 11:27 AM 1/25/00 -0500, Jeff Mcadams wrote: >Thus spake Mark Thornton >>Do you patrol the modem usage to control abusers in any way? If so, how >>do you implement it in a positive way that doesn't offend the >>customers? I'm asking because this has become a bit of a problem with a >>few users who have decided that "unlimited" means just that. > >Well...first off, we make sure we don't use the term "unlimited" in any >of our marketing material. :) Ditto here >We do have session limits at 12 hours I think. We very rarely, if ever, >have any complaints about them. We've had our session limit at 10 with no complaints. We drop the limit to 8 hours in the (we need to add a PRI) - (PRI gets installed) timeframe, then raise it back up. Actually we could probably get away with leaving it at 8 since nobody seems to notice. Our ratio, BTW, rarely gets far above 6:1 before we start seeing busies. Throughout the industry, this ratio seems to be dropping slowly as people use the Internet for more things. It's a 'Catch 22'...we want people to rely more on computers/Internet for their entertainment and information gathering, but this increased dependence also means that we need, on average, to dedicate more resources to servicing each customer. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000/886-2500 http://www.keyconn.net

Subject: Re: (usr-tc) billing software
From: Brian Elfert <brian@citilink.com>
Date: 2000-01-25 12:33:01

On Tue, 25 Jan 2000, Stainforth, Matthew wrote: > I've looked at a few packages but most of them seem to be based on radius > accounting which doesn't seem to be completely reliable. On the other hand, > if you guys are using radius accounting for billing data, do you also use it We use Platypus which uses radius for the time logging. How else could you record time used, syslog? If a radius stop record is missing, the customer just got a free call, not a big deal. > to limit concurrent logons? I see a lot of people on the list saying radius > accounting isn't reliable enough to be used to control concurrency. Just > wondering what the general concensus is... Conncurency control is a whole different deal. A missing stop record could cause a customer to not be able to login. Brian

Subject: Re: (usr-tc) More on connect times
From: Clint R. Sparks <csparks@cqc.com>
Date: 2000-01-25 12:34:45

Paul, We are running Hiper DSP 2.0.81 on PRI's with Hiper Arc 4.1.59-6 and our < 1 minute calls are 6% of our total calls in a 24 hr. period. Just information I wanted to pass along. I would say you have to figure at least half that 6% is people connecting and checking e-mail which they probably do not have any so they disconnect, so not that bad a percentage. Clint R. Sparks ComQuest Internet Services csparks@cqc.com > Hello all, I've got some more info on the connect/disonnect issue with TC. > > Right now I'm running a mix of 2.0.19 and 2.0.80 (70/30 mix) and going > back to 2.0.19 seems to have helped. > > There is a significant drop in the number or 00:00, 00:01 and 00:02 length > calls (1243 for pure .80 and 870 for the .19/.80 mix -- 373 difference) > while the total volume of calls is only different by 200.

Subject: Re: (usr-tc) Quad ana/dig modem not taking calls (another case of)
From: Dan Hollis <goemon@sasami.anime.net>
Date: 2000-01-25 12:37:29

On Tue, 25 Jan 2000, Ray Whelan wrote: > Check the configuration in case the Dual E1 cas is sending out AB bits set for > 11 backward which blocks calls, also the Telco could be sending Blocking. Is there anywhere that has good explanation of the ABCD forward/backward bits? None of my telco books has anything useful on robbed bit signaling. -Dan

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-25 12:43:32

This is a multi-part message in MIME format. ------=_NextPart_000_0039_01BF6731.C9D4FB20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >I have a session limit at 6 hours. It's gets the lazy people and the >kiddies who just like to have a connection up. Some do complian.. but >they quickly quiet down when I point out the service agreement they = signed >(and read.. hahahahha) Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 Same here...We have a 30 min idle out and 6 hour session limit. In 2 1/2 = years I think we have had 2 or 3 complaints. We also say unlimited and = usually limit it to 400 hrs. I think maybe after reading some of these = post we might consider changeing our wording to flatrate...might avoid a = big arguement somwhere down the line. Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 ------=_NextPart_000_0039_01BF6731.C9D4FB20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>>I have a session limit at 6 = hours.  It's=20 gets the lazy people and the<BR>>kiddies who just like to have a = connection=20 up.  Some do complian.. but<BR>>they quickly quiet down when I = point out=20 the service agreement they signed<BR>>(and read.. = hahahahha)<BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Paul Farber<BR>Farber Technology<BR><A=20 href=3D"mailto:farber@admin.f-tech.net">farber@admin.f-tech.net</A><BR>Ph=  =20 570-628-5303<BR>Fax 570-628-5545<BR></FONT></DIV> <DIV><FONT face=3DArial size=3D2>Same here...We have a 30 min idle out = and 6 hour=20 session limit. In 2 1/2 years I think we have had 2 or 3 complaints. We = also say=20 unlimited and usually limit it to 400 hrs. I think maybe after reading = some of=20 these post we might consider changeing our wording to flatrate...might = avoid a=20 big arguement somwhere down the line.<BR></DIV></FONT> <DIV><FONT face=3DArial size=3D2>Greg Owens<BR>Magnolia Internet = Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A>=20 </FONT></DIV></BODY></HTML> ------=_NextPart_000_0039_01BF6731.C9D4FB20--

Subject: Re: (usr-tc) HiPerDSP stops at 21
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-25 12:47:13

TCM. Select the 4 lights on the card (Hiper DSP Span) then click on Timeslot Mapping and Blocking. Make sure every modem has a channel assigned to it. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Tue, 25 Jan 2000, David Swearingin wrote: > At 11:50 AM 1/25/2000 -0500, you wrote: > >Have telco check the hunting. If it's a 'fast' busy its thier end. If > >it's a 'normal' busy check the timeslot mapping and that the modems are > >'on hook' and ready to take a call. > > > >Paul Farber > > Paul, > > >From my home last night, it sounded like a normal busy signal. Where do I > check the 'timeslot mapping'? > > David > __________________________________________________ > David Swearingin (david@carolnet.com) > CARROLLTON INTERNET SERVICE (www.carolnet.com) > First Financial Group, Inc. > 11 N. Folger, Carrollton, MO 64633 > 660-542-3002 Fax 660-542-3003 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) SNMP went away...
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-25 12:48:48

Then it's an easter egg of some sort? Wonder what other unused code is floating around the ARC flash memory??? Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Tue, 25 Jan 2000, Mike Wronski wrote: > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > |Sent: Monday, January 24, 2000 8:52 PM > |To: usr-tc@lists.xmission.com > |Subject: Re: (usr-tc) SNMP went away... > | > | > |At 09:33 PM 1/24/00 -0500, Jeff Mcadams wrote: > |>Thus spake Paul Farber > |>>Hmm... I can snmpwalk the ARC card > |> > |>Then everything is working on the Arc...go forth and be happy. :) > |> > |>Actually...it could mean that you have read-only access and not > |>read-write...but the SNMP agent is running and responding at least. :) > | > |SNMP doesn't even show up in my CONFIGURED NETWORK SERVICES, yet MRTG is > |pulling stats fine... > | > > The SNMPD network service is not currently used by the Hiper ARC. > Configuring it has nothing to do with being able to use SNMP on the HARC. > All that is required is setting up the proper community strings. You DO NOT > need to add the service. > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) billing software
From: Aaron Nabil <nabil@spiritone.com>
Date: 2000-01-25 12:48:54

On Tue, 25 Jan 2000, Brian wrote: > > > It is spiffy, but it's doesn't periodically check with the hub to see > > who's logged on (at least it doesn't in my version, I am running one rev > > back). Only when it's about to deny someone a login because they are > > exceeding their max session count does it go out and look to see if the > > other sessions are still up. Since radiator is single threaded, I'd > > think this could really cause a problem if the check is slow or hangs. > > Aaron, > > Are you using Radiators session database to limit your concurrent > sessions of your users? does it work well? No, but I've looked at it. Mostly been concerned about the potential for blocking, and the fact that I run a separate acct and auth instances. I _think_ gdbm is single writer, multiple reader safe (and I'm almost sure the other dbm's aren't), so it might work. The main problem that I see is that by hard blocking mulitple access it allows people to effectively multiplex one account across several users, something I'm not keen on encouraging. What I do now is run a program that checks for multiple connections every 5 mins, then I write people a nasty gram when I catch them. My _dream_ solution is to modify radiator (or write a separate program) that simply hangs up any other connections but allows the last person to call in to log on. People would get very tired of getting bumped off-line when their buddy calls in with their password. Then of course they call back in, bump the buddy off line, who then calls back in, etc... -- Aaron Nabil

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-25 12:50:21

I have a session limit at 6 hours. It's gets the lazy people and the kiddies who just like to have a connection up. Some do complian.. but they quickly quiet down when I point out the service agreement they signed (and read.. hahahahha) Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Tue, 25 Jan 2000, K Mitchell wrote: > At 11:27 AM 1/25/00 -0500, Jeff Mcadams wrote: > >Thus spake Mark Thornton > >>Do you patrol the modem usage to control abusers in any way? If so, how > >>do you implement it in a positive way that doesn't offend the > >>customers? I'm asking because this has become a bit of a problem with a > >>few users who have decided that "unlimited" means just that. > > > >Well...first off, we make sure we don't use the term "unlimited" in any > >of our marketing material. :) > > Ditto here > > >We do have session limits at 12 hours I think. We very rarely, if ever, > >have any complaints about them. > > We've had our session limit at 10 with no complaints. We drop the limit > to 8 hours in the (we need to add a PRI) - (PRI gets installed) timeframe, > then raise it back up. Actually we could probably get away with leaving it > at 8 since nobody seems to notice. > Our ratio, BTW, rarely gets far above 6:1 before we start seeing busies. > Throughout the industry, this ratio seems to be dropping slowly as people > use the Internet for more things. It's a 'Catch 22'...we want people to > rely more on computers/Internet for their entertainment and information > gathering, but this increased dependence also means that we need, on > average, to dedicate more resources to servicing each customer. > > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000/886-2500 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) billing software
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-25 12:53:25

Thus spake Stainforth, Matthew >I'm half following this discussion about unlimited access offerings and >wondering what billing software those who don't do "unlimited" actually >use. I'd love to move us from unlimited to something like what Jeff is >doing since normal people wouldn't typically use more than 150-200 >hours a month. I've looked at a few packages but most of them seem to >be based on radius accounting which doesn't seem to be completely >reliable. On the other hand, if you guys are using radius accounting >for billing data, do you also use it to limit concurrent logons? I see >a lot of people on the list saying radius accounting isn't reliable >enough to be used to control concurrency. Just wondering what the >general concensus is... We have a home-rolled billing system...we do get the usage from RADIUS accounting. Basically we only use the stop records as they have all the information that is needed to bill. We *don't* use it for concurrency checking because of the dangers that RADIUS based servers imply. Ie, if a start goes to one RADIUS server and the stop goes to the other for some reason...stuff like that. We do concurrency checking via a Perl script with an SNMP module...with some fairly slick Perl scripting (I'm not being arrogant here...I didn't write it :) we have a *VERY* low incidence of false positives on duplicate checking...in fact, I haven't seen any indication of any false positives. There is some indicates of false negatives...ie, people getting away with duplicate logins for a period of time...but even that is pretty low...our script is pretty accurate on that. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) billing software
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-25 13:09:09

On Tue, 25 Jan 2000, Stainforth, Matthew wrote: > I'm half following this discussion about unlimited access offerings and > wondering what billing software those who don't do "unlimited" actually use. Radius stop records get stuck in PostgreSQL database on a linux box. Monthly queries done and imported into *cough* Quicken accounting software. Statements exported into email. Warning: do not try this at home. Using Quicken was a 'quick and dirty' thing I did at the very beginning to get it done when I wasn't really expecting to get this large....and boy, is it dirty now. It officially can't handle all of the accounts, so we've gotta do some mighty strange things to make it work. I can't complain at the hair-pulling and tons of extra work it causes, since it's rather like running a furniture moving company and the only vehicle you have is a '86 Chevette. Anyway, all the billing/accounts stuff is being moved into the same PostgreSQL database that currently holds the call details, with a few perl scripts to work the magic. Customers will access the data directly as well with their web browsers. Not only their accounting statements, but they'll be able to get their usage summaries as well as being able to drill down to individual call levels and see all the details. "It'll be cool", sez the guy who's writing the perl (me). > since normal people wouldn't typically use more than 150-200 hours a month. Over 3 years, the average of all users (including the dedicated ones which, when they occasionally drop and show connect times of 45 days and such...but excluding the calls under 3 minutes) is about 32 hours per month. 32. That's something I point out to people when they're balking at my 150 hour limit. Oh yeah, that reminds me....when I calculate people's monthly usage, I exclude any call that is under three minutes in duration. As far as line usage goes, the in-and-out-to-check-email calls don't matter much. And it excludes ones where the connection was problematic as well. > I've looked at a few packages but most of them seem to be based on radius > accounting which doesn't seem to be completely reliable. On the other hand, > if you guys are using radius accounting for billing data, do you also use it > to limit concurrent logons? I don't limit concurrent, but there is the issue about the reliability of radius. My solution to that is to overengineer the radius server so it can handle the load without dropping stuff, and then to simply eat the few that get dropped. I record accounting-stops only, so if I drop one, I've got no idea that the call ever happened. Occasional spot checks don't reveal the few that get away to amount to much. Well below what I'd call 'negligable'. (:

Subject: (usr-tc) billing software
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-25 13:37:51

I'm half following this discussion about unlimited access offerings and wondering what billing software those who don't do "unlimited" actually use. I'd love to move us from unlimited to something like what Jeff is doing since normal people wouldn't typically use more than 150-200 hours a month. I've looked at a few packages but most of them seem to be based on radius accounting which doesn't seem to be completely reliable. On the other hand, if you guys are using radius accounting for billing data, do you also use it to limit concurrent logons? I see a lot of people on the list saying radius accounting isn't reliable enough to be used to control concurrency. Just wondering what the general concensus is... Matthew Stainforth || Technical Services Manager || BrunNet Inc.

Subject: RE: (usr-tc) billing software
From: Chris Pappe <chris@acronet.net>
Date: 2000-01-25 13:44:40

At 02:03 PM 1/25/00 -0500, you wrote: >On Tue, 25 Jan 2000, Stainforth, Matthew wrote: > > > A company tried to pitch a package to us that used telnet to check > > periodically. *gag* > >This reminds me of something I forgot to mention in my previous >message. > >There's a radius server called Radiator which maintains a current- >calls database for concurrency checking; it updates it with the >accounting-start & stop records. To alleviate problems with lost >packets causing it to get out of sync, it periodically checks the >hub via SNMP and compares who's really on with who it thinks is >logged on. Vircom (www.vircom.com) makes a proxy radius sever that does the same thing. It allows us to use multiple unix radius servers that all get queried by the proxy radius server. Also a list of users currently online can be viewed from a browser as can all login errors such as simultaneous logins or bad passwords. As with Radiator, SNMP is used to maintain an up to date list of users. This product has worked very well for us. Happy New Year! You may have survived the Y2K crisis... But what about the Y5B crisis? www.y5b.com Chris Pappe chris@acronet.net www.acronet.net AcroNet Professional Internet Services Inc 7850 30th Ave., Kenosha, WI 53142-4610 Tel: (414) 697-2220 Fax: (414) 697-2223

Subject: (usr-tc) PRI and CT1 on same HyperArc?
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-25 13:48:17

Are there any wierd problems with running PRI lines and CT1 lines through the same HyperArc? Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-25 13:50:55

Thus spake Aaron Nabil >Gee, thanks. Nice to know that "I'm closer than Garlic Whatziname", >and that I haven't managed to make any major blunders in my first >sentence. >I don't know why you'd say "assuming D4 of course" as RBS occurs at the >same rate in both D4 and ESF. Yeah...my apologies...mostly it was terminology thing. Of course the RBS occurs at the same rate in SF and ESF...didn't mean to imply otherwise. :) Just that it would occur at the 6th, 12th, 18th, and 24th frame in ESF since ESF has 24 frames compared to SF's 12. Same diff really...mostly a terminology thing. >Are you talking about CCITT mu-law encoding? Sure, CCITT mu-law >enforces ones-density IN A SINGLE PCM CHANNEL. But when you stack >mulitple channels together into a T1, how is one PCM channel supposed >to know what's in the next channel? Well, it doesn't, and it's trivial >to violate ones density with something like +127 in the DS0 1 (1000 >0000) and -126 (0000 0010) in DS0 2, as they are simply catenated >together in the T1 frame. 1000 0000 0000 0010 has a run of 13 zeros. Uhm...ones-density requires no more than 15 consecutive zero's, so your run of 13 is fine. It also requires an minimum average of 12.5% of ones (I don't know the period over which this average applies), which is where the one in eight idea comes from I believe. >It only "eats" that bit in DATA. In voice (modems), that bit is still >there, it's just noisy. True...the bit is still interpretted in voice applications...so its not eaten per se...effectively, however, the bit is unuseable for practical purposes...that's all I was trying to say there. >Yeah, I was simplifying. In the context of the original message, I >didn't see any value in driving home and looking up the exact >substitution value in a reference book or on the web. Obviously you >did. Good for you. Actually I waited until I got back to work since all my reference material was at work...I didn't wait just so I could put the B8ZS pattern though...I wanted to confirm a few other things. :) >Your definition of ZCS (Zero code _supression_) would best be >forgotten. Dang...got that one wrong...my apologies...right idea...wrong acronym expansion. ZCS is almost never used any more...but it is something to be aware of...as I said...I ran into some trunks that had it configured and were causing considerable problems. >You are simply wrong. You are again confusing ones density in a single >PCM channel with ones density in the T1 frame. Sorry...I'm well aware of the possibilities of interactions between different DS0's in a frame...I am still correct though...mu-law encoding will enforce ones-density (up to 15 consecutive zeros) on its own, with no need for B8ZS (or the sucky ZCS). >Jeff, it's simply marvellous that you are able to use a search engine >and come up with these "answers". In fact, it's a skill that I've >wished would be more commonplace on a majority of mailing lists >(especially inet-access). But in future, note that there is a >difference between "knowing where to find something" and "knowing >something". Both very useful, but in this case you are in the former >category, not the latter. Hey...I don't claim to be an expert on this...and I'll acknowledge that I didn't communicate well here (and got at least one detail wrong)...but I do have a fairly decent understanding of common T1 technologies. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: pferraro@wna-linknet.com
Date: 2000-01-25 13:52:56

We also limit our calls to 6 hours and idle time to 30 mins. We also incorporate a SOFT LIMIT for when our ports fillup. It is based on number of modems avail, I think it is set to 6 and if anyone is over the soft limit when there only become 5 avail, they are quietly logged out. This is a great feature, especially since the "soft-limit" is set at 4 hours! We use TSMon to handle all of this and out multiple logins too! It works great! We also limit hours to 450/mo. ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Tue, 25 Jan 2000, Greg owens wrote: > >I have a session limit at 6 hours. It's gets the lazy people and the > >kiddies who just like to have a connection up. Some do complian.. but > >they quickly quiet down when I point out the service agreement they signed > >(and read.. hahahahha) > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > Same here...We have a 30 min idle out and 6 hour session limit. In 2 1/2 years I think we have had 2 or 3 complaints. We also say unlimited and usually limit it to 400 hrs. I think maybe after reading some of these post we might consider changeing our wording to flatrate...might avoid a big arguement somwhere down the line. > > Greg Owens > Magnolia Internet Services > http://www.magnolia-net.com >

Subject: RE: (usr-tc) billing software
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-25 14:03:30

On Tue, 25 Jan 2000, Stainforth, Matthew wrote: > A company tried to pitch a package to us that used telnet to check > periodically. *gag* This reminds me of something I forgot to mention in my previous message. There's a radius server called Radiator which maintains a current- calls database for concurrency checking; it updates it with the accounting-start & stop records. To alleviate problems with lost packets causing it to get out of sync, it periodically checks the hub via SNMP and compares who's really on with who it thinks is logged on. Pretty spiffy, if you ask me.

Subject: (usr-tc) Missing Radius records... was Billing Software
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-25 14:11:00

There has been a fair amount of discussion about missing radius records, specifically stop records as regards to concurrency control. I posted a question about this a week or so back and didn't get a response. In my case I have a single chassis that is prone to this problem, but the others are not. Any ideas why? Also, if getting the stop record is so unreliable how do those of you who do hourly billing keep the system working? In our case the session is lost and not billed for. I can live with that but it bothers me that it isn't reliable. Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: RE: (usr-tc) billing software
From: Brian <signal@shreve.net>
Date: 2000-01-25 14:17:29

On Tue, 25 Jan 2000, Stainforth, Matthew wrote: > > -----Original Message----- > > From: Brian Elfert [mailto:brian@citilink.com] > > Sent: Tuesday, January 25, 2000 2:33 PM > > > if you guys are using radius accounting for billing data, > > do you also use it > > > > We use Platypus which uses radius for the time logging. How > > else could > > you record time used, syslog? > > A company tried to pitch a package to us that used telnet to check > periodically. *gag* Their's nothing wrong with that. Using telnet to grab stateful information about who is logged in works very well. The only other way, besides telnet, to grab that information reliably is SNMP. Because of missing records and whatnot, RADIUS I don't consider a good idea. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) What Modem Ratio do you use?
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-25 14:24:27

Sounds like what we have, except our call limit is 12 hours, the soft limit is 4 hours, idle time 30 minutes, and when things fill up, the first people to get killed are the people who haven't paid their bill on time -- regardless of whether they've hit the soft limit or not. They are emailed about why, too. Next up are the free/nonprofit accounts, then the soft limit is applied to paying customers who have hit the soft limit, starting with the user on the longest. All of this constantly checks the threshold, so if things are full and killing the delinquent payers frees up enough lines, it never moves on to the line hogs. Users who go over about 350 hours a month are emailed a warning with a pointer to our AUP, but there is no hard limit on hours. Lots of them are people who just forget to log out, or actually don't know where the 'disconnect' button is... :) Billing (and the late payer killer) is all homebrew Perl scripts, with MySQL on the backend, and a combo of Perl and a homebrew MS Access 97 app on the frontend depending on what you want to do. (i.e. entering checks is in Access, adding/deleting accounts is in Perl.) By the way, if anyone's got Access 2000 and MySQL talking to each other, email me off-list; I've got some weird issues I can't track down easily that are keeping us from upgrading... Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Tue, 25 Jan 2000 pferraro@wna-linknet.com wrote: > > We also limit our calls to 6 hours and idle time to 30 mins. We > also incorporate a SOFT LIMIT for when our ports fillup. It is based on > number of modems avail, I think it is set to 6 and if anyone is over the > soft limit when there only become 5 avail, they are quietly logged out. > This is a great feature, especially since the "soft-limit" is set at 4 > hours! > > We use TSMon to handle all of this and out multiple logins too! It > works great! We also limit hours to 450/mo. > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > On Tue, 25 Jan 2000, Greg owens wrote: > > > >I have a session limit at 6 hours. It's gets the lazy people and the > > >kiddies who just like to have a connection up. Some do complian.. but > > >they quickly quiet down when I point out the service agreement they signed > > >(and read.. hahahahha) > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > Same here...We have a 30 min idle out and 6 hour session limit. In 2 1/2 years I think we have had 2 or 3 complaints. We also say unlimited and usually limit it to 400 hrs. I think maybe after reading some of these post we might consider changeing our wording to flatrate...might avoid a big arguement somwhere down the line. > > > > Greg Owens > > Magnolia Internet Services > > http://www.magnolia-net.com > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Missing Radius records... was Billing Software
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-25 14:28:58

I certainly agree with the point that accounting records shouldn't be used alone for concurrency control. In my case I have a single radius server (that may be the problem;) and am trying to figure out why only one chassis has this problem. There have been so many great tips come out of this list as I lurk in the shadows that I have taken advantage of, I was hoping someone may have come across this problem. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Tuesday, January 25, 2000 2:35 PM > Thus spake Mark Thornton > >There has been a fair amount of discussion about missing radius > >records, specifically stop records as regards to concurrency control. I > >posted a question about this a week or so back and didn't get a > >response. In my case I have a single chassis that is prone to this > >problem, but the others are not. Any ideas why? > > >Also, if getting the stop record is so unreliable how do those of you > >who do hourly billing keep the system working? In our case the session > >is lost and not billed for. I can live with that but it bothers me that > >it isn't reliable. > > Its not so much that the stop records are unreliable...the RADIUS > standard indicates that RADIUS accounting is resent, to ensure that it > gets through (unlike syslog which sends it once...if it doesn't get > through...so sorry). The problem is really that if you have multiple > RADIUS servers for redundancy, the start may get sent to one and the > stop to the other, and its difficult to coordinate this between your > RADIUS servers. > > Also its just the whole idea of forcing state on what's designed to be a > stateless protocol (RADIUS). > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) billing software
From: Brian <signal@shreve.net>
Date: 2000-01-25 14:33:27

> It is spiffy, but it's doesn't periodically check with the hub to see > who's logged on (at least it doesn't in my version, I am running one rev > back). Only when it's about to deny someone a login because they are > exceeding their max session count does it go out and look to see if the > other sessions are still up. Since radiator is single threaded, I'd > think this could really cause a problem if the check is slow or hangs. Aaron, Are you using Radiators session database to limit your concurrent sessions of your users? does it work well? I use Radiator. But for concurrency I use tsmon, just because thats how I started. I may use radiators session database in time though. Their are alot of cool things you can do with Radiator, I love it. Brian > > > -- > Aaron Nabil > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) DSPCode 2.0.51
From: Brian <signal@shreve.net>
Date: 2000-01-25 14:33:54

2.0.51 is good for all DSP's On Tue, 25 Jan 2000, Cheryl Johnson wrote: > Is this code only recommended for hardware revisions .54 and .55 only? > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > since I do not see too many improvements. And is this compatible with > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > keep these things straight. > > -Cheryl Johnson > SEI Data Network Services, Inc. > A Division of SEI Communications > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: RE: (usr-tc) billing software
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-25 14:47:34

> -----Original Message----- > From: Brian Elfert [mailto:brian@citilink.com] > Sent: Tuesday, January 25, 2000 2:33 PM > > if you guys are using radius accounting for billing data, > do you also use it > > We use Platypus which uses radius for the time logging. How > else could > you record time used, syslog? A company tried to pitch a package to us that used telnet to check periodically. *gag* > If a radius stop record is missing, the customer just got a > free call, not > a big deal. > > > to limit concurrent logons? I see a lot of people on the > list saying radius > > accounting isn't reliable enough to be used to control > concurrency. Just > > wondering what the general concensus is... > > Conncurency control is a whole different deal. A missing stop record > could cause a customer to not be able to login. Since we are completely unlimited we haven't messed with radius accounting much. I completely missed the fact that the stop record contains the time elapsed since logon. My bad. I guess that's what the list is for....learn something new every day. :)

Subject: (usr-tc) Motorola SM56
From: Brian <signal@shreve.net>
Date: 2000-01-25 14:55:17

I am having some clients report that they are having problems connecting with Motorola SM56 modems (we are on DSP 2.0.51). Has anyone else seen this? any known fixes? Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Garlic <garlic@garlic.com>
Date: 2000-01-25 15:06:34

So after you throw out all the crap and gobblegook that the others use, the basic answer is still the same. * For a CT1, B8ZS is of no value. There is sufficent one's density for the equipment to operate just fine without it. * ESF is a diagnostic tool and is a good thing but a lot of voice equipment doesn't have the capability. As far as rest, the signal to noise ratio for this mailing list is one of the poorest of the other equipment support lists that I subscribe to. I would have hoped this was a list of network professionals that were trying to help each other. Some participants seem to want to just be very caustic. To the rest, I apologize for leaving off my signature if that's important to you Roy

Subject: RE: (usr-tc) billing software
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-25 15:22:42

On Tue, 25 Jan 2000, Stainforth, Matthew wrote: > ok, next question....how do those of you who DON'T do unlimited compete with > AOL and their unlimited package? Do you try to beat them on price, service, > or availability (ie they're not in your area yet)? Service. And in the case of AOL specifically, they're not here yet. But my competitors are doing $17.95 and $19.95 per month so-called unlimited accounts; my 150hour limited account is $25.00/month. Our service is such that customer migration is overwhelmingly one-way...from them to us. Our biggest reason for customer terminations is "moving out of area"...and at that, our churn rate is well under 1%. As soon as I can figure out how to get people to quit getting jobs elsewhere and having to move, I'll be set. (: Even then, I've got a few that moved and kept their email service...I even have one that moved out of the country and still uses us for dialup, simply because we've built that customer's trust in our reliability. I position myself as an ISP for people who are serious about the net: businesses and power-users (and the people who just gotta have the best for the prestige factor). We even tell people that if they're just casual users that they'd probably get a better deal with our competition (which surprisingly causes them to want us more). Simple 'skimming the cream'. While my market share is (I assume) smaller than my competition, a) they pay more, so it is offset, and b) they're just better customers (i.e., they do things like paying on time *grin*). The two biggest things that positions us thus is a) busy signals are rare...that's the one thing that'll piss off somebody *fast* is not being able to log on when they want to, and b) like Jedi's having to build their own lightsaber, everyone who even thinks about answering a phone here has a clue stick of their very own. No "duh, I dunno" impressions delivered to frustrated customers when they're having problems. And if the phone support will take over 20-30 minutes, we roll a truck and do it onsite. Expensive, but in most cases, it buys something that money typically can't buy....loyalty and trust.

Subject: Re: (usr-tc) PRI and CT1 on same HyperArc?
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 2000-01-25 15:25:51

On Tue, 25 Jan 2000, Mark Thornton wrote: > Are there any wierd problems with running PRI lines and CT1 lines through > the same HyperArc? I had no problems doing it back when we switched from CT1s to PRIs... we brought up the PRIs and got them running before turning down the CT1's. There was a while in the middle when we were running both.

Subject: (usr-tc) DSPCode 2.0.51
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-25 15:31:26

This is a multi-part message in MIME format. ------=_NextPart_000_02D6_01BF6749.3E464790 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is this code only recommended for hardware revisions .54 and .55 only? I = have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 since = I do not see too many improvements. And is this compatible with NMC = 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to keep = these things straight.=20 -Cheryl Johnson SEI Data Network Services, Inc. A Division of SEI Communications ------=_NextPart_000_02D6_01BF6749.3E464790 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Is this code only recommended for = hardware=20 revisions .54 and .55 only? I have .49 and was thinking of moving to the = 2.0.51=20 from the 2.0.60 since I do not see too many improvements. And is this = compatible=20 with NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to = keep=20 these things straight. </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>-Cheryl Johnson</FONT></DIV> <DIV><FONT face=3DArial size=3D2>SEI Data Network Services, = Inc.</FONT></DIV> <DIV><FONT face=3DArial size=3D2><EM>A Division of SEI=20 Communications</EM></FONT></DIV></BODY></HTML> ------=_NextPart_000_02D6_01BF6749.3E464790--

Subject: RE: (usr-tc) billing software
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-25 15:34:56

ok, next question....how do those of you who DON'T do unlimited compete with AOL and their unlimited package? Do you try to beat them on price, service, or availability (ie they're not in your area yet)? Matthew Stainforth || Technical Services Manager || BrunNet Inc. > -----Original Message----- > From: Lon R. Stockton, Jr. [mailto:lon@moonstar.com] > Sent: Tuesday, January 25, 2000 2:09 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) billing software > > > > On Tue, 25 Jan 2000, Stainforth, Matthew wrote: > > > I'm half following this discussion about unlimited access > offerings and > > wondering what billing software those who don't do > "unlimited" actually use. > > Radius stop records get stuck in PostgreSQL database on a linux box. > Monthly queries done and imported into *cough* Quicken accounting > software. Statements exported into email. > > Warning: do not try this at home. Using Quicken was a 'quick > and dirty' > thing I did at the very beginning to get it done when I wasn't really > expecting to get this large....and boy, is it dirty now. It officially > can't handle all of the accounts, so we've gotta do some > mighty strange > things to make it work. I can't complain at the hair-pulling and tons > of extra work it causes, since it's rather like running a furniture > moving company and the only vehicle you have is a '86 Chevette. > > Anyway, all the billing/accounts stuff is being moved into the same > PostgreSQL database that currently holds the call details, with a > few perl scripts to work the magic. Customers will access the data > directly as well with their web browsers. Not only their accounting > statements, but they'll be able to get their usage summaries as well > as being able to drill down to individual call levels and see all the > details. "It'll be cool", sez the guy who's writing the perl (me). > > > since normal people wouldn't typically use more than > 150-200 hours a month. > > Over 3 years, the average of all users (including the dedicated ones > which, when they occasionally drop and show connect times of 45 days > and such...but excluding the calls under 3 minutes) is about 32 hours > per month. 32. That's something I point out to people when they're > balking at my 150 hour limit. > > Oh yeah, that reminds me....when I calculate people's monthly usage, > I exclude any call that is under three minutes in duration. As far > as line usage goes, the in-and-out-to-check-email calls don't matter > much. And it excludes ones where the connection was > problematic as well. > > > I've looked at a few packages but most of them seem to be > based on radius > > accounting which doesn't seem to be completely reliable. > On the other hand, > > if you guys are using radius accounting for billing data, > do you also use it > > to limit concurrent logons? > > I don't limit concurrent, but there is the issue about the reliability > of radius. My solution to that is to overengineer the radius server so > it can handle the load without dropping stuff, and then to simply eat > the few that get dropped. I record accounting-stops only, so if I drop > one, I've got no idea that the call ever happened. Occasional > spot checks > don't reveal the few that get away to amount to much. Well below what > I'd call 'negligable'. (: > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Missing Radius records... was Billing Software
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-25 15:35:15

Thus spake Mark Thornton >There has been a fair amount of discussion about missing radius >records, specifically stop records as regards to concurrency control. I >posted a question about this a week or so back and didn't get a >response. In my case I have a single chassis that is prone to this >problem, but the others are not. Any ideas why? >Also, if getting the stop record is so unreliable how do those of you >who do hourly billing keep the system working? In our case the session >is lost and not billed for. I can live with that but it bothers me that >it isn't reliable. Its not so much that the stop records are unreliable...the RADIUS standard indicates that RADIUS accounting is resent, to ensure that it gets through (unlike syslog which sends it once...if it doesn't get through...so sorry). The problem is really that if you have multiple RADIUS servers for redundancy, the start may get sent to one and the stop to the other, and its difficult to coordinate this between your RADIUS servers. Also its just the whole idea of forcing state on what's designed to be a stateless protocol (RADIUS). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Quad ana/dig modem not taking calls (another case of)
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 2000-01-25 15:53:01

Hi Dan, Check the configuration in case the Dual E1 cas is sending out AB bits set for 11 backward which blocks calls, also the Telco could be sending Blocking. Debug Ctrl D 1 Cas Monitor Trace this allows you to see AB bits changes ,Time Stamts channel call coming in on line, Its a good starting point. Or try 2 Cas monitor trace it monitor all channels be careful this can slow down the system. Try the first trace and make a test call. Regards Ray Whelan Dan Borlovan <danb@dnttm.ro> on 25/01/2000 15:02:24 Please respond to usr-tc@lists.xmission.com Sent by: Dan Borlovan <danb@dnttm.ro> cc: (Ray Whelan/IE/3Com) Hello, I have a totalcontrol chassis with the following cards: - 1 dual e1/cas - 8 digital quad modems - 6 analog/digital quad modems - 1 hiper arc - 1 hiper nmc (p5nmc) All cards have at least tcs3.5 software Modem signal source is pritdm. The dual/e1 card recognizes the modem cards. I have 2 E1 (30 channels) active. The problem is that the ana/dig modems do not take calls. All modems (both dig and ana/dig) have the same configuration. What seems to happen: - a call arives; the dual/e1 tries to communicate with the modem (status is 'dialling-in'); after about 10s failes and the caller gets a busy signal from the telco. Meantime modem shows no reaction (doesn't go off-hook) What was tried: - software reset, hardware reset, chassis powerdown/powerup - reinserting modem cards - chaging modem cards - changing modem source from pritdm to nic, inserting an analog line and making a call works - so the modem and the harc are fine - swapping slot positions for dig and ana/dig modems - the dig modems take calls, the ana/dig don't The same configuration seems to work in other places using same hardware. If you have any suggestion, I'll be glad to try. If needed I can provide debug from the dual/e1 card (the ctrl/d menu), just tell me which debug options to enable. Thanks, Dan -- Dan Borlovan <danb@dnttm.ro> System Administrator, Network Operation Center Dynamic Network Technologies - Timisoara, Romania Telefon: +40-56-204967 FAX: +40-56-220201 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) DSPCode 2.0.51
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-25 16:08:26

On Tue, 25 Jan 2000, Brian wrote: > 2.0.51 is good for all DSP's How's it compare to 2.0.81? Better, worse, indifferent? Charles > On Tue, 25 Jan 2000, Cheryl Johnson wrote: > > > Is this code only recommended for hardware revisions .54 and .55 only? > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > > since I do not see too many improvements. And is this compatible with > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > > keep these things straight. > > > > -Cheryl Johnson > > SEI Data Network Services, Inc. > > A Division of SEI Communications > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) T1-186 & HyperArc 4.2.32-1?
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-25 16:24:16

According to the compatibility matrix the T1-186 code version 3.5 is not compatible with TCS 3.6 which includes the Arc code 4.2.32-1. I just noticed this is the configuration I am running with no apparent ill effects. This may go back to the discussion of what version of code to run on the Arc, but is anyone else running this configuration? Does it seem appear stable to you as well? What benefit is there to replacing the old T1 card with the newer PRI/T1 card? I'n not really keen on dumping the quads yet because they are working, and at times they seem to be more compatible with the worthless modems of the world than my DSP's. Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: Re: (usr-tc) AMI/D4 provisioning on CT1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-25 16:45:55

Thus spake Aaron Nabil >The original T1 spec was 3 ones in 24 bits, with no more than 15 >zeros. But the AT&T spec, (ie, the defacto standard) requires >one pulse every 8 bits, not just 3 every 24. Hrmm...all I can go on is my experience, what I've read, and what I've talked to telco folks about...I have almost never heard it put as no more than 8 zeros...virtually everyone I've talked to about it says it can be up to 15 zeros. This includes websites of many equipment vendors that make this stuff (including at least Lucent, Motorola, Cisco, and virtually every T1 tutorial/overview site that I've found...oh...and the U.S. Department of Agriculture...don't ask me why, but that one turned up). >The reason I said it should be forgotten was because it is a term that has >different meaning in different contexts, of which your example would >almost always be the LEAST likely to be what someone meant. Most >typically by ZCS people are referring to "a ZCS technique" like B8ZS, ZBTSI >or HDB3, not one-stuffing done by a CSU. OK...again...I've never heard of ZCS used those other ways...only as the bit-stuffing...though I have heard plenty of other terms for it as well...I'll be careful in using that then...thanks for the warning. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Quad ana/dig modem not taking calls (another case of)
From: Dan Borlovan <danb@dnttm.ro>
Date: 2000-01-25 17:02:24

Hello, I have a totalcontrol chassis with the following cards: - 1 dual e1/cas - 8 digital quad modems - 6 analog/digital quad modems - 1 hiper arc - 1 hiper nmc (p5nmc) All cards have at least tcs3.5 software Modem signal source is pritdm. The dual/e1 card recognizes the modem cards. I have 2 E1 (30 channels) active. The problem is that the ana/dig modems do not take calls. All modems (both dig and ana/dig) have the same configuration. What seems to happen: - a call arives; the dual/e1 tries to communicate with the modem (status is 'dialling-in'); after about 10s failes and the caller gets a busy signal from the telco. Meantime modem shows no reaction (doesn't go off-hook) What was tried: - software reset, hardware reset, chassis powerdown/powerup - reinserting modem cards - chaging modem cards - changing modem source from pritdm to nic, inserting an analog line and making a call works - so the modem and the harc are fine - swapping slot positions for dig and ana/dig modems - the dig modems take calls, the ana/dig don't The same configuration seems to work in other places using same hardware. If you have any suggestion, I'll be glad to try. If needed I can provide debug from the dual/e1 card (the ctrl/d menu), just tell me which debug options to enable. Thanks, Dan -- Dan Borlovan <danb@dnttm.ro> System Administrator, Network Operation Center Dynamic Network Technologies - Timisoara, Romania Telefon: +40-56-204967 FAX: +40-56-220201

Subject: Re: (usr-tc) DSPCode 2.0.51
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-25 17:19:34

I _think_ I've some improvement in disconnects running 2.0.51. Don't know about Rockwell improvements. I had a USR Sportster 56K _non_ winmodem having handsaking problems this morning on 2.0.81 and 2.0.19. He hit a 2.0.51 card and all was well. Could have been a co-inki-dink. -- Scot ----- Original Message ----- Sent: Tuesday, January 25, 2000 4:08 PM > On Tue, 25 Jan 2000, Brian wrote: > > > 2.0.51 is good for all DSP's > > How's it compare to 2.0.81? Better, worse, indifferent? > > Charles > > > On Tue, 25 Jan 2000, Cheryl Johnson wrote: > > > > > Is this code only recommended for hardware revisions .54 and .55 only? > > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > > > since I do not see too many improvements. And is this compatible with > > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > > > keep these things straight. > > > > > > -Cheryl Johnson > > > SEI Data Network Services, Inc. > > > A Division of SEI Communications > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) PRI and CT1 on same HyperArc?
From: Steve McConnell <stevem@emji.net>
Date: 2000-01-25 17:20:17

I am running 2 T1s (first in the rollover) and 4 PRIs. I have not seen anything weird, and we have been running it like this for 6 months. steve --On Tue, Jan 25, 2000 1:48 PM -0600 Mark Thornton <mark@corridor.net> wrote: > Are there any wierd problems with running PRI lines and CT1 lines through > the same HyperArc? > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Steve McConnell EMJI 919.303.3217:126

Subject: Re: (usr-tc) DSPCode 2.0.51
From: Brian <signal@shreve.net>
Date: 2000-01-25 17:30:21

I have seen more connection success rate with 2.0.51. I use to get 94-98% connection success overall for all calls to a chassis for a 24 hour period. I now see more like 96-98% average. On Tue, 25 Jan 2000, Charles Sprickman wrote: > On Tue, 25 Jan 2000, Brian wrote: > > > 2.0.51 is good for all DSP's > > How's it compare to 2.0.81? Better, worse, indifferent? > > Charles > > > On Tue, 25 Jan 2000, Cheryl Johnson wrote: > > > > > Is this code only recommended for hardware revisions .54 and .55 only? > > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > > > since I do not see too many improvements. And is this compatible with > > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > > > keep these things straight. > > > > > > -Cheryl Johnson > > > SEI Data Network Services, Inc. > > > A Division of SEI Communications > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) T1-186 & HyperArc 4.2.32-1?
From: Brian Elfert <brian@citilink.com>
Date: 2000-01-25 17:41:42

On Tue, 25 Jan 2000, Mark Thornton wrote: > According to the compatibility matrix the T1-186 code version 3.5 is not > compatible with TCS 3.6 which includes the Arc code 4.2.32-1. I just noticed > this is the configuration I am running with no apparent ill effects. This > may go back to the discussion of what version of code to run on the Arc, but The compatability matrix is a listing of what has been tested together as a group. It does not necessarily mean a particular rev won't work. They may not have gotten the 386 T1 code into that round of testing. How you tell if a code really doesn't work, or if it wasn't tested at all, I don't know. Brian

Subject: (usr-tc) Re: usr-tc) Motorola SM56
From: Greg owens <gowens@magnolia-net.com>
Date: 2000-01-25 18:15:16

This is a multi-part message in MIME format. ------=_NextPart_000_001D_01BF6760.217377C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian...Had the same problem here a few weeks ago you might try some of = the init strings found at=20 http://www.motorola.com/networking/products/sm56_ac-l/index.html I finally got the modem to connect about 7 out of 10 trys. Thats the = best we could ever do. Greg Owens Magnolia Internet Services http://www.magnolia-net.com=20 I am having some clients report that they are having problems connecting with Motorola SM56 modems (we are on DSP 2.0.51). Has anyone else seen this? any known fixes? Brian Feeny (BF304) signal@shreve.net =20 318-222-2638 x 109 http://www.shreve.net/~signal =20 Network Administrator ShreveNet Inc. (ASN 11881) =20 ------=_NextPart_000_001D_01BF6760.217377C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2614.3401" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Brian...Had the same problem here a few = weeks ago=20 you might try some of the init strings found at </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN = class=3D350014917-07012000><A=20 href=3D"http://www.motorola.com/networking/products/sm56_ac-l/index.html"= >http://www.motorola.com/networking/products/sm56_ac-l/index.html</A></SP= AN></FONT></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D350014917-07012000></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D350014917-07012000>I = finally got the=20 modem to connect about 7 out of 10 trys. Thats the best we could ever=20 do.</SPAN></FONT></DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D350014917-07012000></SPAN></FONT> </DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D350014917-07012000></SPAN></FONT> </DIV> <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20 class=3D350014917-07012000></SPAN></FONT> </FONT><FONT face=3DArial = size=3D2>Greg=20 Owens<BR>Magnolia Internet Services<BR><A=20 href=3D"http://www.magnolia-net.com">http://www.magnolia-net.com</A> = </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>I am having some clients report that = they are=20 having problems connecting<BR>with Motorola SM56 modems (we are on DSP=20 2.0.51).  Has anyone else seen<BR>this? any known=20 fixes?<BR><BR><BR>-----------------------------------------------------<B= R>Brian=20 Feeny (BF304)     <A=20 href=3D"mailto:signal@shreve.net">signal@shreve.net</A>  =20 <BR>318-222-2638 x 109 <A=20 href=3D"http://www.shreve.net/~signal">http://www.shreve.net/~signal</A>&= nbsp;    =20 <BR>Network Administrator   ShreveNet Inc. (ASN=20 11881)      =20 <BR><BR><BR></FONT></DIV></DIV></BODY></HTML> ------=_NextPart_000_001D_01BF6760.217377C0--

Subject: RE: (usr-tc) DSPCode 2.0.51
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-25 18:29:51

I've been getting reports of non-winmodem sportsters and couriers having the same prob with 2.0.60 > -----Original Message----- > From: Scot Desort [SMTP:scot@njaccess.net] > Sent: Tuesday, January 25, 2000 6:20 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) DSPCode 2.0.51 > > I _think_ I've some improvement in disconnects running 2.0.51. Don't know > about Rockwell improvements. > > I had a USR Sportster 56K _non_ winmodem having handsaking problems this > morning on 2.0.81 and 2.0.19. He hit a 2.0.51 card and all was well. Could > have been a co-inki-dink. > > -- > Scot > > > > ----- Original Message ----- > From: Charles Sprickman <spork@inch.com> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, January 25, 2000 4:08 PM > Subject: Re: (usr-tc) DSPCode 2.0.51 > > > > On Tue, 25 Jan 2000, Brian wrote: > > > > > 2.0.51 is good for all DSP's > > > > How's it compare to 2.0.81? Better, worse, indifferent? > > > > Charles > > > > > On Tue, 25 Jan 2000, Cheryl Johnson wrote: > > > > > > > Is this code only recommended for hardware revisions .54 and .55 > only? > > > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > > > > since I do not see too many improvements. And is this compatible > with > > > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > > > > keep these things straight. > > > > > > > > -Cheryl Johnson > > > > SEI Data Network Services, Inc. > > > > A Division of SEI Communications > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Problems with HiperARC 4.2.32
From: Jorge Lozano <jorge@andinet.com>
Date: 2000-01-25 18:54:54

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have 4 Hiper ARC, three with 4.1.72 and just one with 4.2.32 software version Everyone work with my RADIUS server, but after a minutes... the hiper with 4.2.32 begin to send garbage in the password field.... I reboot the card and everything its ok again... for some minutes... :-) Can somebody help me with this anormal situation? Jorge Lozano -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.2 for non-commercial use <http://www.pgp.com> iQA/AwUBOI43zqp3oywyFVUlEQJL9gCg8VO0ZbhNleK4RwWYq/D/TByfwKMAoPh9 /JnaRqALsKyPCq/s4SnRk6jy =AK0h -----END PGP SIGNATURE-----

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-25 19:12:57

On Tue, 25 Jan 2000, Rick wrote: > I would be happy to hear what others think of 3coms implementation of OSPF? > > We have been testing it on 4 boxes for afew months now and have noticed one > major flaw. If an 8 character auth_key is used it has to be entered anytime > the box reboots. > > Krish, maybe you can look into this. I confirmed this in my own testing using > numerous combinations of 4-8 character ospf keys and ONLY 8 character keys > cause this bug. Hmmm.. So a 8 charecter authkey for OSPF will reboot the ARC., Bad - will check it out and hopefully it is already fixed in later ER versions will let you know regards krish > > Brian wrote: > > > I think what I hear is that 4.2 you really only need to goto if you want > > OSPF. And that the OSPF in 4.2 is flaky anyways. So 4.2 doesn't sound to > > production ready yet. > > > > Brian > > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone > Head of Network Engineering | Monmouth Internet Corporation > 732-842-5366=====Option #6 | http://www.monmouth.com > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Motorola SM56
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-25 20:00:52

Yes and no, in that order :p Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Tue, 25 Jan 2000, Brian wrote: > > I am having some clients report that they are having problems connecting > with Motorola SM56 modems (we are on DSP 2.0.51). Has anyone else seen > this? any known fixes? > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Rick <rallan@monmouth.com>
Date: 2000-01-25 20:01:10

I would be happy to hear what others think of 3coms implementation of OSPF? We have been testing it on 4 boxes for afew months now and have noticed one major flaw. If an 8 character auth_key is used it has to be entered anytime the box reboots. Krish, maybe you can look into this. I confirmed this in my own testing using numerous combinations of 4-8 character ospf keys and ONLY 8 character keys cause this bug. Brian wrote: > I think what I hear is that 4.2 you really only need to goto if you want > OSPF. And that the OSPF in 4.2 is flaky anyways. So 4.2 doesn't sound to > production ready yet. > > Brian > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====Option #6 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Subject: Re: (usr-tc) HiPerDSP stops at 21
From: Jason A. Nunnelley <interests@linkfast.net>
Date: 2000-01-25 21:35:10

See if you telco capped your inbound available calls... JN ----- Original Message ----- Sent: Monday, January 24, 2000 12:00 AM > I have one HiPER DSP that has 21 active calls and then returns a busy signal, > even though there should be three more modems available. Any suggestions as > to why this is happening? > > David > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-25 22:13:18

Yipe. That one I hadn't run into, but check the archives of the list and you'll find multiple posts from me describing other OSPF problems we've had. I won't bore everyone else by repeating it yet again here. :) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Tue, 25 Jan 2000, Rick wrote: > I would be happy to hear what others think of 3coms implementation of OSPF? > > We have been testing it on 4 boxes for afew months now and have noticed one > major flaw. If an 8 character auth_key is used it has to be entered anytime > the box reboots. > > Krish, maybe you can look into this. I confirmed this in my own testing using > numerous combinations of 4-8 character ospf keys and ONLY 8 character keys > cause this bug. > > Brian wrote: > > > I think what I hear is that 4.2 you really only need to goto if you want > > OSPF. And that the OSPF in 4.2 is flaky anyways. So 4.2 doesn't sound to > > production ready yet. > > > > Brian > > > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone > Head of Network Engineering | Monmouth Internet Corporation > 732-842-5366=====Option #6 | http://www.monmouth.com > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Rip Routing question
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-25 22:36:58

We, like others tried to implement OSPF because it was supposed to be the holy grail of internal routing as far as 3Com was concerned. I had high hopes for it because we have occasional lapses in RIP2 propogation to the Cisco router. By that I mean occasionally the rip routes for a given chassis just disappear, then reappear after about 20 to 30 minutes. I had to place static routes to each chassis defining the space containing the assigned ip address pool to get consistent access for the majority of our clients. Dedicated ip clients still occasionally experienced the problem until I put a static route to one of the Arcs for each client. If the RIP was working it seemed to overide the static route, if not the traffic bounced of the Arc on to the correct Arc in most cases. 3Com was of abosolutely no help on this matter while we were under contract, hence no current contract. I never could get OSPF to work but that is probably because I have never worked with it before and the docs are a bit thin on application. Has anyone else experienced RIP problems? I thought it might be someone stuffing the Cisco with bad routes so I moved to authenticated RIP with no change in behaviour. I haven't removed the static routes since we got to 4.2.32-1 to see if the problem is still there. Mark Thornton San Marcos Internet, Inc. 512-393-5300

Subject: RE: (usr-tc) DSPCode 2.0.51
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-26 07:37:01

Another thing I just noticed about 2.0.51 -- ISDN calls setup much faster (not that they were slow before). I have a 3COM Impact, and I used to get about a 1.5 second delay during which Win95 would display "verifying username". Now, when I connect to a 2.0.51 card, windows barely has enough time to even display that dialog. The setup and authentication is almost instantaneous. -- Scot >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stainforth, Matthew >Sent: Tuesday, January 25, 2000 5:30 PM >To: 'usr-tc@lists.xmission.com' >Subject: RE: (usr-tc) DSPCode 2.0.51 > > > >I've been getting reports of non-winmodem sportsters and couriers >having the >same prob with 2.0.60 > >> -----Original Message----- >> From: Scot Desort [SMTP:scot@njaccess.net] >> Sent: Tuesday, January 25, 2000 6:20 PM >> To: usr-tc@lists.xmission.com >> Subject: Re: (usr-tc) DSPCode 2.0.51 >> >> I _think_ I've some improvement in disconnects running 2.0.51. Don't know >> about Rockwell improvements. >> >> I had a USR Sportster 56K _non_ winmodem having handsaking problems this >> morning on 2.0.81 and 2.0.19. He hit a 2.0.51 card and all was >well. Could >> have been a co-inki-dink. >> >> -- >> Scot >> >> >> >> ----- Original Message ----- >> From: Charles Sprickman <spork@inch.com> >> To: <usr-tc@lists.xmission.com> >> Sent: Tuesday, January 25, 2000 4:08 PM >> Subject: Re: (usr-tc) DSPCode 2.0.51 >> >> >> > On Tue, 25 Jan 2000, Brian wrote: >> > >> > > 2.0.51 is good for all DSP's >> > >> > How's it compare to 2.0.81? Better, worse, indifferent? >> > >> > Charles >> > >> > > On Tue, 25 Jan 2000, Cheryl Johnson wrote: >> > > >> > > > Is this code only recommended for hardware revisions .54 and .55 >> only? >> > > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 >> > > > since I do not see too many improvements. And is this compatible >> with >> > > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to >> > > > keep these things straight. >> > > > >> > > > -Cheryl Johnson >> > > > SEI Data Network Services, Inc. >> > > > A Division of SEI Communications >> > > > >> > > >> > > ----------------------------------------------------- >> > > Brian Feeny (BF304) signal@shreve.net >> > > 318-222-2638 x 109 http://www.shreve.net/~signal >> > > Network Administrator ShreveNet Inc. (ASN 11881) >> > > >> > > >> > > - >> > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > > with "unsubscribe usr-tc" in the body of the message. >> > > For information on digests or retrieving files and old messages send >> > > "help" to the same address. Do not use quotes in your message. >> > > >> > >> > >> > - >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the message. >> > For information on digests or retrieving files and old messages send >> > "help" to the same address. Do not use quotes in your message. >> > >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) DSPCode 2.0.51
From: K Mitchell <mitch@keyconn.net>
Date: 2000-01-26 08:16:16

At 07:37 AM 1/26/00 -0500, Scot Desort wrote: >Another thing I just noticed about 2.0.51 -- ISDN calls setup much faster >(not that they were slow before). I have a 3COM Impact, and I used to get >about a 1.5 second delay during which Win95 would display "verifying >username". Now, when I connect to a 2.0.51 card, windows barely has enough >time to even display that dialog. The setup and authentication is almost >instantaneous. Thus far the weight of responses seems to be in favor of 2.0.51, but I'm still a bit wary of moving from 2.0.81, which has been stable here for months. So...I got a couple of questions for those running 2.0.51, particularly with 0.49 hardware. 1. What ARC code are you running? 2. Hung modem pairs...more, less, same? 3. Re: MR 1832-Rockwell v.90 disconnects during speedshift; I've not received a lot of complaints regarding this while running 2.0.81, is there any noticeable difference for better or worse with 2.0.51? Thanks, -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000/886-2500 http://www.keyconn.net

Subject: (usr-tc) Not accepting ISDN calls... still.
From: Stephen Amadei <amadei@dandy.net>
Date: 2000-01-26 08:26:21

I wrote a long time about this, but none of the replys really helped me, and recently it has come back up as an issue, so let's see if new knowledge can shed some light... I have two older chassises with HiperARCs in them... both have Dual-PRI cards, 12 Quads of various Digital and A/D type, a HiperARC and a NMC card. One unit has two HiperDSPs in it... the other has one HiperDSP, but it's not operational yet. These TC's can be seen on my demo TCView page, http://www.dandy.net/statistics/tc.html as Atlantic City and Pleasantville. Both chassis are up to date with TCS3.6 and the lastest code from the Totalservice website... I never can remember the version numbers, but we are _current_. Yes, even 2.0.51 on the DSPs. The problem we have is that when we upgraded from Netservers to HiperARCs, Atlantic City lost the ability to accept ISDN calls. P'ville accepts them fine, but for A.C., they come up in RADIUS as async instead of ISDN. I have turned both boxes inside out to find a difference, but could find none. Both TCs are identical but in name, phone-number and the extra DSP card. Recently, it has come to light that A.C. _is_ accepting ISDN calls, but only on the DSP cards... not the Quads. Hopefully, this will spark some suggestions on enabling ISDN. Thanx in advance. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Subject: Re: (usr-tc) Not accepting ISDN calls... still.
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-26 08:40:14

Thus spake Stephen Amadei >The problem we have is that when we upgraded from Netservers to >HiperARCs, Atlantic City lost the ability to accept ISDN calls. >P'ville accepts them fine, but for A.C., they come up in RADIUS as >async instead of ISDN. I have turned both boxes inside out to find a >difference, but could find none. Both TCs are identical but in name, >phone-number and the extra DSP card. >Recently, it has come to light that A.C. _is_ accepting ISDN calls, but >only on the DSP cards... not the Quads. Hopefully, this will spark >some suggestions on enabling ISDN. Thanx in advance. Sounds like the dual-pri card is set with the isdn gateway slot as 16 rather than 0. Basically, with it set to 16, it sends ISDN calls to the card in slot 16 to be terminated...with it set to 0, it spreads them across the quads. The reason this worked with the NETServer and not the Arc is because the NETServer had the Munich ISDN daughtercard which could terminate ISDN calls, the Arc does not. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) HiPerDSP stops at 21
From: David Swearingin <david@carolnet.com>
Date: 2000-01-26 09:15:55

Yesterday I checked all the DSP Modem programmed settings. The channels that have not been working are 3, 23, & 24. The only differences in the settings of these three and the rest that are working was in the Call Control Options. The Verbal/Numeric Result codes on the three was set at Verbal instead of Numeric. The Result Code Groups (X) was 1 instead of 0, and Rings for Auto Answer (SO|Dip 5) was 1 instead of 0. I changed these and then rebooted the card. Didn't help. Last night it still stopped at 21 calls with those three channels not working. This morning, I pulled the card out and re-inserted it. When calls came in, Channel three was skipped. Channels 1,2, 4, 5, 6 accepted calls. I have reported this to the telco and they are checking their end. Any more ideas? Running DSP code 2.0.60 David At 09:35 PM 1/25/2000 -0600, you wrote: >See if you telco capped your inbound available calls... > >JN > >----- Original Message ----- >From: "David Swearingin" <david@carolnet.com> >To: <usr-tc@lists.xmission.com> >Sent: Monday, January 24, 2000 12:00 AM >Subject: (usr-tc) HiPerDSP stops at 21 > > >> I have one HiPER DSP that has 21 active calls and then returns a busy >signal, >> even though there should be three more modems available. Any suggestions >as >> to why this is happening? >> >> David >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

Subject: Re: (usr-tc) (USR-TC) MISSING RADIUS R
From: Steve Valiunas <steve_valiunas@mw.3com.com>
Date: 2000-01-26 09:35:52

I've also seen cases where the NAS was talking to a remote radius server over shakey/saturated links, causing a lot of radius retransmissions- If the Radius server can't handle starts & stops coming in out of order, then session-limiting based on this will break. In at least a couple of cases things cleaned up by fixing the link. To see if this might be contributing to the problem, compare the count of retransmitted accounting packets between the working and not working Harcs ("show accounting counters"). It -might- be as simple as that. Of course this isn't likely if all the chassis are local. STeve jeff.binkley@asacomp.com (Jeff Binkley) on 01/26/2000 09:15:21 AM Please respond to usr-tc@lists.xmission.com Sent by: jeff.binkley@asacomp.com (Jeff Binkley) cc: (Steve Valiunas/MW/US/3Com) U>There has been a fair amount of discussion about missing radius U>records, specifically stop records as regards to concurrency control. U>I posted a question about this a week or so back and didn't get a U>response. In my case I have a single chassis that is prone to this U>problem, but the others are not. Any ideas why? U>Also, if getting the stop record is so unreliable how do those of you U>who do hourly billing keep the system working? In our case the session U>is lost and not billed for. I can live with that but it bothers me U>that it isn't reliable. U>Mark Thornton U>San Marcos Internet, Inc. U>512-393-5300 Unfortunately it is a HiPerArc problem that crept in at a certain release of code. 3Com claims it has been fixed in the newer code but with the problems many folks have had, including myself, with the newer code, some folks are afraid to try it. I plan to try another HiPerArc upgrade soon. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) (USR-TC) MISSING RADIUS R
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-26 09:37:32

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley |Sent: Wednesday, January 26, 2000 9:15 AM |To: USR-TC@lists.xmission.com |Subject: (usr-tc) (USR-TC) MISSING RADIUS R | | |U>There has been a fair amount of discussion about missing radius |U>records, specifically stop records as regards to concurrency control. |U>I posted a question about this a week or so back and didn't get a |U>response. In my case I have a single chassis that is prone to this |U>problem, but the others are not. Any ideas why? | |U>Also, if getting the stop record is so unreliable how do those of you |U>who do hourly billing keep the system working? In our case the session |U>is lost and not billed for. I can live with that but it bothers me |U>that it isn't reliable. | |U>Mark Thornton |U>San Marcos Internet, Inc. |U>512-393-5300 | | |Unfortunately it is a HiPerArc problem that crept in at a certain |release of code. 3Com claims it has been fixed in the newer code but |with the problems many folks have had, including myself, with the newer |code, some folks are afraid to try it. I plan to try another HiPerArc |upgrade soon. | I am not aware of any missing stop records in current code. But in some scenarios the card my discard accounting information. This scenario is a heavily loaded chassis (90%+ capacity) that has lost connectivity to its Accounting server. The HARC will retransmit accounting packets forever. But there is only so much memory available for buffering packets (based on available free memory in your specific configuration it is dynamic). If the packet buffer fills up, the HARC starts to discard the oldest packets to make room. In this scenario, there would be NO accounting packets sent for those sessions when the server comes back up. Having backup servers should prevent this from ever happening. There is also another solution that provides very good results. The HARC supports a feature called "interim accounting". This causes the HARC to send accounting data throughout the session at a configured interval. This data is updated with all current call stats, Bytes, timers, retrains etc. In a scenario where the actual stop record is lost, you never are off by more than your configured interval. Your concurrent session scheme needs to realize that if it starts logging accounting for a different user on the same port, the old user has disconnected and his counter should be decremented. This gives the max time a user would be blocked by his concurrent session counter at 2X configured accounting interval. Before the flames start, this does require a Radius server support and possibly relational DB backend. 3Com S&A does not support this but if your looking to customize or have Radius customized, the Harc does provide enough information from RADIUS accounting to get the job done.

Subject: Re: (usr-tc) DSPCode 2.0.51
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-26 09:46:55

We saw some of that when we load 2.0.60, but the problem was offset by a reduced number of problems with V90/KFlex modems attempting to connect. It used to be a continuous battle, now it is just a nuisance. We only had a few 28.8 connections that failed and it is my recollection that tech support got them going somehow. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Wednesday, January 26, 2000 9:48 AM > We have seen an increase in calls to our help desk when we flashed 2.0.51 on > all our DSP's. > > Older 28.8 modems were having trouble connecting (including USR's) > > We flashed back to 2.0.60. > > Did anyone else experience this?? > > John Verreault > AEI Internet > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman > > Sent: Tuesday, January 25, 2000 4:08 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) DSPCode 2.0.51 > > > > > > On Tue, 25 Jan 2000, Brian wrote: > > > > > 2.0.51 is good for all DSP's > > > > How's it compare to 2.0.81? Better, worse, indifferent? > > > > Charles > > > > > On Tue, 25 Jan 2000, Cheryl Johnson wrote: > > > > > > > Is this code only recommended for hardware revisions .54 and .55 only? > > > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > > > > since I do not see too many improvements. And is this compatible with > > > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > > > > keep these things straight. > > > > > > > > -Cheryl Johnson > > > > SEI Data Network Services, Inc. > > > > A Division of SEI Communications > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Rip Routing question
From: Brian <signal@shreve.net>
Date: 2000-01-26 10:08:59

I have no problems with RIPv2 on the ARC's. Perhaps you can post the relevent lines of your cisco and arc configs (the rip parts). Brian On Tue, 25 Jan 2000, Mark Thornton wrote: > We, like others tried to implement OSPF because it was supposed to be the > holy grail of internal routing as far as 3Com was concerned. I had high > hopes for it because we have occasional lapses in RIP2 propogation to the > Cisco router. By that I mean occasionally the rip routes for a given chassis > just disappear, then reappear after about 20 to 30 minutes. I had to place > static routes to each chassis defining the space containing the assigned ip > address pool to get consistent access for the majority of our clients. > Dedicated ip clients still occasionally experienced the problem until I put > a static route to one of the Arcs for each client. If the RIP was working it > seemed to overide the static route, if not the traffic bounced of the Arc on > to the correct Arc in most cases. 3Com was of abosolutely no help on this > matter while we were under contract, hence no current contract. > > I never could get OSPF to work but that is probably because I have never > worked with it before and the docs are a bit thin on application. > > Has anyone else experienced RIP problems? I thought it might be someone > stuffing the Cisco with bad routes so I moved to authenticated RIP with no > change in behaviour. I haven't removed the static routes since we got to > 4.2.32-1 to see if the problem is still there. > > Mark Thornton > San Marcos Internet, Inc. > 512-393-5300 > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: RE: (usr-tc) DSPCode 2.0.51
From: Brian <signal@shreve.net>
Date: 2000-01-26 10:10:10

> 1. What ARC code are you running? 4.1.22 > 2. Hung modem pairs...more, less, same? none since moving to 2.0.51 > 3. Re: MR 1832-Rockwell v.90 disconnects during speedshift; I've not > received a lot of complaints regarding this while running 2.0.81, is there > any noticeable difference for better or worse with 2.0.51? I have noticed that the connection success rate has improved a bit > > Thanks, > -- > Kirk Mitchell-General Manager mitch@keyconn.net > Keystone Connect Unlock Your World > Altoona, PA 814-941-5000/886-2500 http://www.keyconn.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) HiPerDSP stops at 21
From: Brian <signal@shreve.net>
Date: 2000-01-26 10:11:50

get into the dsp chdev span dis atstat dis atab what do those show? you did check your channel/modem mapping right? On Wed, 26 Jan 2000, David Swearingin wrote: > Yesterday I checked all the DSP Modem programmed settings. The channels > that have not been working are 3, 23, & 24. The only differences in the > settings of these three and the rest that are working was in the Call > Control Options. The Verbal/Numeric Result codes on the three was set at > Verbal instead of Numeric. The Result Code Groups (X) was 1 instead of 0, > and Rings for Auto Answer (SO|Dip 5) was 1 instead of 0. I changed these > and then rebooted the card. > > Didn't help. Last night it still stopped at 21 calls with those three > channels not working. This morning, I pulled the card out and re-inserted > it. When calls came in, Channel three was skipped. Channels 1,2, 4, 5, 6 > accepted calls. > > I have reported this to the telco and they are checking their end. > > Any more ideas? Running DSP code 2.0.60 > > David > > At 09:35 PM 1/25/2000 -0600, you wrote: > >See if you telco capped your inbound available calls... > > > >JN > > > >----- Original Message ----- > >From: "David Swearingin" <david@carolnet.com> > >To: <usr-tc@lists.xmission.com> > >Sent: Monday, January 24, 2000 12:00 AM > >Subject: (usr-tc) HiPerDSP stops at 21 > > > > > >> I have one HiPER DSP that has 21 active calls and then returns a busy > >signal, > >> even though there should be three more modems available. Any suggestions > >as > >> to why this is happening? > >> > >> David > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > >> > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > __________________________________________________ > David Swearingin (david@carolnet.com) > CARROLLTON INTERNET SERVICE (www.carolnet.com) > First Financial Group, Inc. > 11 N. Folger, Carrollton, MO 64633 > 660-542-3002 Fax 660-542-3003 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: (usr-tc) (USR-TC) MISSING RADIUS R
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 2000-01-26 10:15:21

U>There has been a fair amount of discussion about missing radius U>records, specifically stop records as regards to concurrency control. U>I posted a question about this a week or so back and didn't get a U>response. In my case I have a single chassis that is prone to this U>problem, but the others are not. Any ideas why? U>Also, if getting the stop record is so unreliable how do those of you U>who do hourly billing keep the system working? In our case the session U>is lost and not billed for. I can live with that but it bothers me U>that it isn't reliable. U>Mark Thornton U>San Marcos Internet, Inc. U>512-393-5300 Unfortunately it is a HiPerArc problem that crept in at a certain release of code. 3Com claims it has been fixed in the newer code but with the problems many folks have had, including myself, with the newer code, some folks are afraid to try it. I plan to try another HiPerArc upgrade soon. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: (usr-tc) RE: (USR-TC) AMI/D4 PROVI
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 2000-01-26 10:15:21

U>Depends on the application. With voice calls in the DS0's, the U>encoding of the voice data into the DS0's actually enforces one's U>density inherently. The encoding algorithm won't generate bit U>patterns that don't meet one's density requirements. U>>Without B8ZS, the framer has to enforce ones density by stuffing U>ones, >this causes a drop in the S/N ratio. (I seem to remember 4db U>as the >figure, but I don't have any reference material in front of me U>to back >that up.) U>I don't know what it translates into as far as a db loss, but it eats U>up one out of every eight bits of data meaning a loss of 192kbps on a U>T1 total...dropping the total useable bandwidth to 1.344Mbps Not quite. AMI has nothing to do with the amount of available bandwith per se'. What is getting mixed up here is that folks are assuming inband signalling (i.e. Robbed Bit Signalling) equals AMI. This is not true. RBS equals CTI because there is no out of band signalling like a D channel on a PRI for a CTI T-1. Thus A/B bit inband signalling is used. Now RBS does eat ever so slightly into the S/N ratio because in teh 6/12th timeslots the Least Significant Bit (LSB) is used out of the 64kbs PCM encoding process for each channel. Thus you have 56kbs of PCM data instead of 64kbs. How much does that equate to on the S/N ratio ? There are two answers to this. First if the samlping values of the lost PCM bits is lower than the ambient noise of the local facility connected to them, then you probably will see no S/N degredation (a likely scenario). Otherwise there might be some but since the data transmission power level used is also much higher than the lost PCM bits, the effect should be neglible. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: RE: (usr-tc) DSPCode 2.0.51
From: John Verreault <verreaul@aei.ca>
Date: 2000-01-26 10:48:59

We have seen an increase in calls to our help desk when we flashed 2.0.51 on all our DSP's. Older 28.8 modems were having trouble connecting (including USR's) We flashed back to 2.0.60. Did anyone else experience this?? John Verreault AEI Internet > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman > Sent: Tuesday, January 25, 2000 4:08 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) DSPCode 2.0.51 > > > On Tue, 25 Jan 2000, Brian wrote: > > > 2.0.51 is good for all DSP's > > How's it compare to 2.0.81? Better, worse, indifferent? > > Charles > > > On Tue, 25 Jan 2000, Cheryl Johnson wrote: > > > > > Is this code only recommended for hardware revisions .54 and .55 only? > > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > > > since I do not see too many improvements. And is this compatible with > > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > > > keep these things straight. > > > > > > -Cheryl Johnson > > > SEI Data Network Services, Inc. > > > A Division of SEI Communications > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Quad ana/dig modem not taking calls (another case of)
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 2000-01-26 11:00:01

Hi Dan , Am I correct in thinking from your original mail both Analog and Digital were failing, from your Debug you attached in you second mail Analog call connect. What I see from the Debug is a follows Working Analog calls Failed Digital Call Telco Nas Telco Nas I -3 -> I -3 -> A-1 <- A1 ( 5seconds) 0 A1 A-3 3 A1 3 A1 -----> Clear Fwd 3 A1 I-3 A3 ii-1 B6 <- Answer The problem is when a Digital calls comes form your telco, we get the first digit and we respond to it with a A-1, The telco should then should send the next digit but the NAS times out ( normal condition) as no other digits or recieved, the NAS then sends a digit complete , but the telco send a clear forward . Two issues to look into either telco not seeing our A-1 or there is a problem with the telco digital call service. Talk to your telco make sure you service can have a digital service. Regards Ray Whelan

Subject: (usr-tc) Global Access list on arc's
From: Brian <signal@shreve.net>
Date: 2000-01-26 11:12:49

Can you make a global access list on the ARC's, basically like an access list applied to its eth interface, so that it applies to all users? I don't want to enable it via radius, I just want to do this via CLI (its an access list to prevent stuff to our core). Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) DSPCode 2.0.51
From: Mark Lemmert <cto@athenet.net>
Date: 2000-01-26 11:48:27

At 05:30 PM 1/25/00 -0600, Brian wrote: >I have seen more connection success rate with 2.0.51. I use to get 94-98% >connection success overall for all calls to a chassis for a 24 hour >period. > >I now see more like 96-98% average. How do you get those sorts of statistics? I have been having a very large number of complains from people saying the can't connect. I am running 2.0.81. Thanks. -MGL >On Tue, 25 Jan 2000, Charles Sprickman wrote: > > > On Tue, 25 Jan 2000, Brian wrote: > > > > > 2.0.51 is good for all DSP's > > > > How's it compare to 2.0.81? Better, worse, indifferent? > > > > Charles > > > > > On Tue, 25 Jan 2000, Cheryl Johnson wrote: > > > > > > > Is this code only recommended for hardware revisions .54 and .55 only? > > > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > > > > since I do not see too many improvements. And is this compatible with > > > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > > > > keep these things straight. > > > > > > > > -Cheryl Johnson > > > > SEI Data Network Services, Inc. > > > > A Division of SEI Communications > > > > > > > > > > ----------------------------------------------------- > > > Brian Feeny (BF304) signal@shreve.net > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > >----------------------------------------------------- >Brian Feeny (BF304) signal@shreve.net >318-222-2638 x 109 http://www.shreve.net/~signal >Network Administrator ShreveNet Inc. (ASN 11881) > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Mark Lemmert CTO AthEnet Data Exchange 920-954-9799 mark.lemmert@athenet.net

Subject: Re: (usr-tc) Global Access list on arc's
From: dciresi@defunct.ae.usr.com
Date: 2000-01-26 14:23:00

You could do this: set user default input_filter <filter> I'm not sure if that will affect user adm, !root, or whatever. Dominic On Wed, 26 Jan 2000, Brian wrote: > > Can you make a global access list on the ARC's, basically like an access > list applied to its eth interface, so that it applies to all users? I > don't want to enable it via radius, I just want to do this via CLI (its an > access list to prevent stuff to our core). > > Brian > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Not accepting ISDN calls... still.
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-26 14:52:25

On Wed, 26 Jan 2000, Stephen Amadei wrote: > On Wed, 26 Jan 2000, Jeff Mcadams wrote: > > > Sounds like the dual-pri card is set with the isdn gateway slot as 16 > > rather than 0. Basically, with it set to 16, it sends ISDN calls to the > > card in slot 16 to be terminated...with it set to 0, it spreads them > > across the quads. The reason this worked with the NETServer and not the > > Arc is because the NETServer had the Munich ISDN daughtercard which > > could terminate ISDN calls, the Arc does not. > > I understand this. On my dual-pri card I have a choice between 1-16 and > NONE for no Gateway. Both P'ville and Atlantic City are NONE. As in my > previous message, P'ville accepts ISDN, A.C. doesn't. > Also on your dual-pri the quad modems should show up as quad-I-modem, Make sure that they are quad-i and not just quad krish > I did notice that "Inbound Phone Number Routing Configuration Status" > is slightly different between the two TCs... but I've never what info > this page is displaying, or how to copy the info from one TC to the other. > > ----Steve > Stephen Amadei > Director of MIS > Dandy Connections, Inc. > Atlantic City, NJ > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Quad ana/dig modem not taking calls (another case of)
From: Dan Borlovan <danb@dnttm.ro>
Date: 2000-01-26 15:28:54

On Wed, 26 Jan 2000, Ray Whelan wrote: > The problem is when a Digital calls comes form your telco, we get the first > digit and we respond to it with a A-1, The telco should then should send the > next digit but > the NAS times out ( normal condition) as no other digits or recieved, the NAS > then sends a digit complete , but the telco send a clear forward . You can call me stupid. Yes the e1/cas got the first digit, sent the A-1, but the telco didn't recognize the A-1 so it never sent the other digits. The problem: the e1/cas had the 'companding' setting on 'use modem country code'. Well, the digital modems are for europe (A-law) and the analog/digitals are for US (u-law). I wonder how an A-law encoded signal sounds after decoded with u-law. And viceversa. The 'companding' is set to A-law now, and all the modems are taking calls. Now an unrelated question: the e1/cas shows 'project id' as a=R2 q=Q412, but I can set only one value for 'project id'. As a result, each time I reset the e1/cas card, I have to do it twice, because after first reset the a= and c= values are incorrect (both Q421 or R2), and after the seconde reset it takes about 30s to detect the correct values and start taking calls. Is there anything that can be done? Dan -- Dan Borlovan <danb@dnttm.ro> System Administrator, Network Operation Center Dynamic Network Technologies - Timisoara, Romania Telefon: +40-56-204967 FAX: +40-56-220201

Subject: Re: (usr-tc) Not accepting ISDN calls... still.
From: Stephen Amadei <amadei@dandy.net>
Date: 2000-01-26 15:40:25

On Wed, 26 Jan 2000, Jeff Mcadams wrote: > Sounds like the dual-pri card is set with the isdn gateway slot as 16 > rather than 0. Basically, with it set to 16, it sends ISDN calls to the > card in slot 16 to be terminated...with it set to 0, it spreads them > across the quads. The reason this worked with the NETServer and not the > Arc is because the NETServer had the Munich ISDN daughtercard which > could terminate ISDN calls, the Arc does not. I understand this. On my dual-pri card I have a choice between 1-16 and NONE for no Gateway. Both P'ville and Atlantic City are NONE. As in my previous message, P'ville accepts ISDN, A.C. doesn't. I did notice that "Inbound Phone Number Routing Configuration Status" is slightly different between the two TCs... but I've never what info this page is displaying, or how to copy the info from one TC to the other. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Subject: (usr-tc) Ascend to 3com
From: Brian Burgmeier <brianb@ntwrld.com>
Date: 2000-01-26 16:06:36

This is a multi-part message in MIME format. --------------29D6D207E5B12E70DEB760C7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit We are in the process of merging two ISPs. Our ISP runs on the 3Com Hiper Arch Chassis the other ISP runs on Ascend. Since we both use ELI for our Channelized T-1s we are considering porting their dial in number over to our 3Com chassis at our location.. What problems should we anticipate moving customers from an ASCEND unit to 3com? Both are using the "V90 standard." protocol. Would we be better off using their ASCEND equipment? Any feedback is appreciated. Thanks -Brian --------------29D6D207E5B12E70DEB760C7 Content-Type: text/x-vcard; charset=us-ascii; name="brianb.vcf" Content-Transfer-Encoding: 7bit Content-Description: Card for Brian Burgmeier Content-Disposition: attachment; filename="brianb.vcf" begin:vcard n:Burgmeier;Brian x-mozilla-html:FALSE org:Net-World version:2.1 email;internet:brianb@ntwrld.com x-mozilla-cpt:;0 fn:Brian Burgmeier end:vcard --------------29D6D207E5B12E70DEB760C7--

Subject: Re: (usr-tc) DSPCode 2.0.51
From: Brian <signal@shreve.net>
Date: 2000-01-26 16:43:52

On Wed, 26 Jan 2000, Mark Lemmert wrote: > At 05:30 PM 1/25/00 -0600, Brian wrote: > > >I have seen more connection success rate with 2.0.51. I use to get 94-98% > >connection success overall for all calls to a chassis for a 24 hour > >period. > > > >I now see more like 96-98% average. > > > How do you get those sorts of statistics? I have been having a very > large number of complains from people saying the can't connect. I > am running 2.0.81. I wrote a script to check syslog data for successfull/non-successfull connects. Brian > > Thanks. > > -MGL > > > >On Tue, 25 Jan 2000, Charles Sprickman wrote: > > > > > On Tue, 25 Jan 2000, Brian wrote: > > > > > > > 2.0.51 is good for all DSP's > > > > > > How's it compare to 2.0.81? Better, worse, indifferent? > > > > > > Charles > > > > > > > On Tue, 25 Jan 2000, Cheryl Johnson wrote: > > > > > > > > > Is this code only recommended for hardware revisions .54 and .55 only? > > > > > I have .49 and was thinking of moving to the 2.0.51 from the 2.0.60 > > > > > since I do not see too many improvements. And is this compatible with > > > > > NMC 6.1.17 and ARC 4.1.22? It seems to be getting more difficult to > > > > > keep these things straight. > > > > > > > > > > -Cheryl Johnson > > > > > SEI Data Network Services, Inc. > > > > > A Division of SEI Communications > > > > > > > > > > > > > ----------------------------------------------------- > > > > Brian Feeny (BF304) signal@shreve.net > > > > 318-222-2638 x 109 http://www.shreve.net/~signal > > > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > >----------------------------------------------------- > >Brian Feeny (BF304) signal@shreve.net > >318-222-2638 x 109 http://www.shreve.net/~signal > >Network Administrator ShreveNet Inc. (ASN 11881) > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > Mark Lemmert > CTO > AthEnet Data Exchange > 920-954-9799 > mark.lemmert@athenet.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) Global Access list on arc's
From: Brian <signal@shreve.net>
Date: 2000-01-26 16:44:44

ok thanks On Wed, 26 Jan 2000 dciresi@defunct.ae.usr.com wrote: > You could do this: > set user default input_filter <filter> > I'm not sure if that will affect user adm, !root, or whatever. > > Dominic > > On Wed, 26 Jan 2000, Brian wrote: > > > > > Can you make a global access list on the ARC's, basically like an access > > list applied to its eth interface, so that it applies to all users? I > > don't want to enable it via radius, I just want to do this via CLI (its an > > access list to prevent stuff to our core). > > > > Brian > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) Quad ana/dig modem not taking calls (another case of)
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 2000-01-26 17:03:18

Dan, A = active and C= configured this means that if you reset the cared the C becomes active, If both are the same this should not be an issue if you save the configuration. 30 second after reset is normal for this card to become active after reset. Ray Whelan Dan Borlovan <danb@dnttm.ro> on 26/01/2000 13:28:54 Please respond to usr-tc@lists.xmission.com Sent by: Dan Borlovan <danb@dnttm.ro> cc: usr-tc@lists.xmission.com (Ray Whelan/IE/3Com) On Wed, 26 Jan 2000, Ray Whelan wrote: > The problem is when a Digital calls comes form your telco, we get the first > digit and we respond to it with a A-1, The telco should then should send the > next digit but > the NAS times out ( normal condition) as no other digits or recieved, the NAS > then sends a digit complete , but the telco send a clear forward . You can call me stupid. Yes the e1/cas got the first digit, sent the A-1, but the telco didn't recognize the A-1 so it never sent the other digits. The problem: the e1/cas had the 'companding' setting on 'use modem country code'. Well, the digital modems are for europe (A-law) and the analog/digitals are for US (u-law). I wonder how an A-law encoded signal sounds after decoded with u-law. And viceversa. The 'companding' is set to A-law now, and all the modems are taking calls. Now an unrelated question: the e1/cas shows 'project id' as a=R2 q=Q412, but I can set only one value for 'project id'. As a result, each time I reset the e1/cas card, I have to do it twice, because after first reset the a= and c= values are incorrect (both Q421 or R2), and after the seconde reset it takes about 30s to detect the correct values and start taking calls. Is there anything that can be done? Dan -- Dan Borlovan <danb@dnttm.ro> System Administrator, Network Operation Center Dynamic Network Technologies - Timisoara, Romania Telefon: +40-56-204967 FAX: +40-56-220201 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Ascend to 3com
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-26 17:46:42

Wow, this is directly opposed to four other private messages I received on this same topic. We just bought more DSP's as opposed to a fallback Ascend chassis. Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Wednesday, January 26, 2000 5:48 PM > I use the TotCtrl chassis and Ascend Maxes (6000&4000) > I have found that the Maxes are much more reliable for some user modem > types. > It is my Failsafe if the user cant connect to the 3com. > > Scott Boggs > AccessUnited ISP > > > > -----Original Message----- > > From: Brian Burgmeier [SMTP:brianb@ntwrld.com] > > Sent: Wednesday, January 26, 2000 6:07 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Ascend to 3com > > > > We are in the process of merging two ISPs. Our ISP runs on > > the 3Com Hiper Arch Chassis the other ISP runs on Ascend. > > Since we both use ELI for our Channelized T-1s we are > > considering porting their dial in number over to our 3Com chassis > > at our location.. > > What problems should we anticipate moving customers from > > an ASCEND unit to 3com? Both are using the "V90 standard." > > protocol. Would we be better off using > > their ASCEND equipment? Any feedback is appreciated. > > > > > > Thanks -Brian > > > > << File: Card for Brian Burgmeier >> > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Not accepting ISDN calls... still.
From: Stephen Amadei <amadei@dandy.net>
Date: 2000-01-26 18:00:58

On Wed, 26 Jan 2000, Tatai SV Krishnan wrote: > Also on your dual-pri the quad modems should show up as quad-I-modem, > Make sure that they are quad-i and not just quad Actually they came up as Qbch-I-mdms. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Subject: RE: (usr-tc) Ascend to 3com
From: Scott Boggs <sboggs@unitedbank.net>
Date: 2000-01-26 18:48:07

I use the TotCtrl chassis and Ascend Maxes (6000&4000) I have found that the Maxes are much more reliable for some user modem types. It is my Failsafe if the user cant connect to the 3com. Scott Boggs AccessUnited ISP > -----Original Message----- > From: Brian Burgmeier [SMTP:brianb@ntwrld.com] > Sent: Wednesday, January 26, 2000 6:07 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Ascend to 3com > > We are in the process of merging two ISPs. Our ISP runs on > the 3Com Hiper Arch Chassis the other ISP runs on Ascend. > Since we both use ELI for our Channelized T-1s we are > considering porting their dial in number over to our 3Com chassis > at our location.. > What problems should we anticipate moving customers from > an ASCEND unit to 3com? Both are using the "V90 standard." > protocol. Would we be better off using > their ASCEND equipment? Any feedback is appreciated. > > > Thanks -Brian > > << File: Card for Brian Burgmeier >>

Subject: (usr-tc) static to dynamic
From: David Swearingin <david@carolnet.com>
Date: 2000-01-26 21:22:21

How do I "set chassis slot x type" from static to dynamic? David __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 660-542-3002 Fax 660-542-3003

Subject: (usr-tc) 2.0.51 improvements
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-26 21:26:48

hello all... after the discussion of the 2.0.51 performance.. I'm gonna give it a shot. the release notes (we all read the release notes... don't we?) 3Com has 'resolved' MR2346: improved connections with Rockwell HCF modems with roundtrip delays of 30-40ms. Also v42 detection has been improved...... well there's 2 bits of good new. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545

Subject: (usr-tc) Problem with new PRI
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-27 02:33:24

We added another PRI to our hunt group today. Telco says all trunks in group are set to UCD hunt method. New PRI is only taking 1 call on channel 1. It has taken both analog and digital calls on that channel. I have checked the card in TCM and all channels are enabled. I have done a hardware reset on the card, with no effect. Have not had the opporunity to switch the PRI to see if the problem follows the card or the trunk. Any ideas on what I might be missing? -- Scot

Subject: Re: (usr-tc) Ascend to 3com
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-27 07:07:48

On Wed, 26 Jan 2000, Brian Burgmeier wrote: > We are in the process of merging two ISPs. Our ISP runs on > the 3Com Hiper Arch Chassis the other ISP runs on Ascend. > Since we both use ELI for our Channelized T-1s we are > considering porting their dial in number over to our 3Com chassis > at our location.. Regular dialup should not have any problems, however, Ascend uses radius attributes that are speicific to certain versions and its radius attributes overlap standard attributes. Other than that you should not have any other problems. Oh, one other - modems that connect v.90 (but actually connection k56 ) would have problems with v90 if not using the correct protocol. > What problems should we anticipate moving customers from > an ASCEND unit to 3com? Both are using the "V90 standard." > protocol. Would we be better off using > their ASCEND equipment? Any feedback is appreciated. > No just use 3com its better....:-) krish > > Thanks -Brian > > >

Subject: Re: (usr-tc) Not accepting ISDN calls... still.
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-27 07:10:11

On the pri card you can run debug to see how the call translates and what is happeing - on the main menu if you type crtl-D it will pop up a menu - I guess the option 4 in that menu is to trace the call, enabling that will put out q931 / layer 3 info, based on that info we can see if there is a problem with the incoming call or if its actually a 33k voice call etc. Other than that everything should work by default. krish On Wed, 26 Jan 2000, Stephen Amadei wrote: > On Wed, 26 Jan 2000, Tatai SV Krishnan wrote: > > > Also on your dual-pri the quad modems should show up as quad-I-modem, > > Make sure that they are quad-i and not just quad > > Actually they came up as Qbch-I-mdms. > > ----Steve > Stephen Amadei > Director of MIS > Dandy Connections, Inc. > Atlantic City, NJ > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) static to dynamic
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-27 07:16:28

If you have setup a chassis in which you have programed a slot to be static and save that configuration, once done it will remain static unless and untill removed manually. For your ports to be dynamic, here is what you need to do First remove the port from static configuration Then enable nmc chassis awarenss. When you do a sh nmc you will see three options in there nmc chassis awarness DSA DSA Idle rebla if you have only one hiper arc in the chassis then enable nmc chassis awarness and disable the other two. If you have more than one hyper arc and want to maintain dynamic configuration then enable all three. If you have two hiper arcs and you want to make static configurations disable all the three in nmc chassis awarness and then reboot the card. krish On Wed, 26 Jan 2000, David Swearingin wrote: > You wrote: > > > From: D A Substanley <das@gol.com> > > To: usr-tc@lists.xmission.com > > Date: Thu, 27 Jan 2000 12:33:12 +0900 > > Subject: Re: (usr-tc) static to dynamic > > > > > > Enable nmc chassis awareness > > > > das > > Didn't work for me. > > David > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Problem with new PRI
From: Brian <signal@shreve.net>
Date: 2000-01-27 08:55:32

channel/slot mappings, check them. ds0 service states, check those. Go into session monitor, and look at ds0 statistics, it may also show something. On Thu, 27 Jan 2000, Scot Desort wrote: > We added another PRI to our hunt group today. Telco says all trunks in group > are set to UCD hunt method. > > New PRI is only taking 1 call on channel 1. It has taken both analog and > digital calls on that channel. I have checked the card in TCM and all > channels are enabled. I have done a hardware reset on the card, with no > effect. Have not had the opporunity to switch the PRI to see if the problem > follows the card or the trunk. > > Any ideas on what I might be missing? > > > -- > Scot > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) static to dynamic
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 2000-01-27 09:16:13

Well in order to remove it from static configuration you have set the owner of that slot as no - Basically say if you have slot 1 configured as static then you would issue set chass slot 1 o n enable nmc chas save all reboot krish On Thu, 27 Jan 2000, D A Substanley wrote: > Good information, thanks Krish. > One question, how do you remove the port from static configuration. > > das > > Tatai SV Krishnan (tkrishna@bubba.ae.usr.com) spake: > > > If you have setup a chassis in which you have programed a slot to be > > static and save that configuration, once done it will remain static > > unless and untill removed manually. > > > > For your ports to be dynamic, here is what you need to do > > > > First remove the port from static configuration > > Then enable nmc chassis awarenss. > > When you do a sh nmc > > you will see three options in there > > > > nmc chassis awarness > > DSA > > DSA Idle rebla > > > > if you have only one hiper arc in the chassis then enable nmc chassis > > awarness and disable the other two. > > > > If you have more than one hyper arc and want to maintain dynamic > > configuration then enable all three. > > > > If you have two hiper arcs and you want to make static configurations > > disable all the three in nmc chassis awarness > > > > and then reboot the card. > > > > > > krish > > > > On Wed, 26 Jan 2000, David Swearingin wrote: > > > > > You wrote: > > > > > > > From: D A Substanley <das@gol.com> > > > > To: usr-tc@lists.xmission.com > > > > Date: Thu, 27 Jan 2000 12:33:12 +0900 > > > > Subject: Re: (usr-tc) static to dynamic > > > > > > > > > > > > Enable nmc chassis awareness > > > > > > > > das > > > > > > Didn't work for me. > > > > > > David > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > ______________________________________________ > Alex Substanley Exodus Communications K.K. > Engineering Department > Das Man TEL: 81-3-5334-1700 > Systems Engineer FAX: 81-3-5334-1711 > ______________________________________________ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) ARC Filters
From: Brian <signal@shreve.net>
Date: 2000-01-27 10:02:46

Is their anything for ARC filters equivelent to: access-list 101 permit tcp any any established or do you have to parse the entire access list for each packet? Also, am I correct in saying something like this: access-list 101 permit tcp any 208.206.76.57 0.0.0.0 eq 20 would get broken into two lines on an ARC filter, like this: 010 AND tcp-dst-port = 20; 020 PERMIT dst-addr = 208.206.76.57/32; you can't do it on one line, it takes 2 right? Thanks Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: RE: (usr-tc) Equipment List Confirmation
From: albert <emmanuel@mwt.net>
Date: 2000-01-27 10:24:02

Join the ISP-Equipment Moderated Digest today to get the best of what's o= n the ISP-Equipment Email Discussion List in one concise weekly email. mailto:join-isp-equipment-moderated@isp-equipment.com ___________ =95 The ISP-EQUIPMENT Discussion List =95 ___________ To Join: mailto:join-isp-equipment@isp-equipment.com To Remove: mailto:remove-isp-equipment@isp-equipment.com Archives: http://isp-lists.isp-planet.com/isp-equipment/archives/ > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of S O Okeyo > Sent: Thursday, January 27, 2000 1:15 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Equipment List Confirmation > > > I am unable to get confirmation for my equipment list membership. I hav= e > mailed confirmation according to instructions several times but > each time I > get a message back that the number I have put after "OK" is not > right yet I > put in the actual number mailed to me by Sparklist. I have been typing > OK######E on the Subjet line. > > Can someone help me out of this? > > Okeyo > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Problem with new PRI
From: Brian <signal@shreve.net>
Date: 2000-01-27 10:46:13

check the ds0 service states in tcm, or from the dsp command line: chdev span dis atstat brian On Thu, 27 Jan 2000, Scot Desort wrote: > OK. Duh on me. > > Where can one tell if modems are soft-busied. That is what was wrong. I have > since restored to service all of those channels. But before I figured it > out, there didn't seem to be anywhere in TCM that told me the channels were > busied out. Did I miss something??? > > > > ----- Original Message ----- > From: Brian <signal@shreve.net> > To: usr list <usr-tc@lists.xmission.com> > Sent: Thursday, January 27, 2000 9:55 AM > Subject: Re: (usr-tc) Problem with new PRI > > > > > > channel/slot mappings, check them. > > > > ds0 service states, check those. > > > > Go into session monitor, and look at ds0 statistics, it may also show > > something. > > > > > > On Thu, 27 Jan 2000, Scot Desort wrote: > > > > > We added another PRI to our hunt group today. Telco says all trunks in > group > > > are set to UCD hunt method. > > > > > > New PRI is only taking 1 call on channel 1. It has taken both analog and > > > digital calls on that channel. I have checked the card in TCM and all > > > channels are enabled. I have done a hardware reset on the card, with no > > > effect. Have not had the opporunity to switch the PRI to see if the > problem > > > follows the card or the trunk. > > > > > > Any ideas on what I might be missing? > > > > > > > > > -- > > > Scot > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > ----------------------------------------------------- > > Brian Feeny (BF304) signal@shreve.net > > 318-222-2638 x 109 http://www.shreve.net/~signal > > Network Administrator ShreveNet Inc. (ASN 11881) > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: (usr-tc) ARC Filters
From: Brian <signal@shreve.net>
Date: 2000-01-27 10:53:58

Does the ARC Filter have a limit of 20 rules or something? I am making a filter and its erroring on line 20, and I don't see the error: HiPer>> verify filter filter_in FM: In filter file filter_in, protocol IP, unexpected symbols in action at line 20 here is the first 28 or so lines................rule 170 is what its considering line 20. #filter IP: 010 AND tcp-dst-port = 20; 020 PERMIT dst-addr = 208.206.76.57/32; 030 AND tcp-dst-port = 20; 040 PERMIT dst-addr = 208.206.76.58/32; 050 AND tcp-dst-port = 20; 060 PERMIT dst-addr = 208.206.76.5/32; 070 AND tcp-dst-port = 20; 080 PERMIT dst-addr = 208.206.76.13/32; 090 AND tcp-dst-port = 20; 100 PERMIT dst-addr = 208.206.76.33/32; 110 AND tcp-dst-port = 20; 120 PERMIT dst-addr = 208.206.76.45/32; 130 AND tcp-dst-port = 21; 140 PERMIT dst-addr = 208.206.76.57/32; 150 AND tcp-dst-port = 21; 160 PERMIT dst-addr = 208.206.76.58/32; 170 AND tcp-dst-port = 21; 180 PERMIT dst-addr = 208.206.76.5/32; 190 AND tcp-dst-port = 21; 200 PERMIT dst-addr = 208.206.76.13/32; 210 AND tcp-dst-port = 21; 220 PERMIT dst-addr = 208.206.76.33/32; 230 AND tcp-dst-port = 21; 240 PERMIT dst-addr = 208.206.76.45/32; Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) Ascend to 3com
From: Brian Elfert <brian@citilink.com>
Date: 2000-01-27 11:05:19

On Thu, 27 Jan 2000, Tatai SV Krishnan wrote: > No just use 3com its better....:-) Personally, I'd be much more likely to continue to use 3Com if somebody from logistics would ever call me with an RMA for my bad Dual PRI NAC. Brian

Subject: Re: (usr-tc) Problem with new PRI
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-27 11:07:09

OK. Duh on me. Where can one tell if modems are soft-busied. That is what was wrong. I have since restored to service all of those channels. But before I figured it out, there didn't seem to be anywhere in TCM that told me the channels were busied out. Did I miss something??? ----- Original Message ----- Sent: Thursday, January 27, 2000 9:55 AM > > channel/slot mappings, check them. > > ds0 service states, check those. > > Go into session monitor, and look at ds0 statistics, it may also show > something. > > > On Thu, 27 Jan 2000, Scot Desort wrote: > > > We added another PRI to our hunt group today. Telco says all trunks in group > > are set to UCD hunt method. > > > > New PRI is only taking 1 call on channel 1. It has taken both analog and > > digital calls on that channel. I have checked the card in TCM and all > > channels are enabled. I have done a hardware reset on the card, with no > > effect. Have not had the opporunity to switch the PRI to see if the problem > > follows the card or the trunk. > > > > Any ideas on what I might be missing? > > > > > > -- > > Scot > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Lost Carrier
From: Brian Becker <brian@semo.net>
Date: 2000-01-27 12:17:09

We've been told by 3Com reps that when Radius shows "Lost-Carrier" as the disconnect reason, it is solely caused by the user modem shutting down with no warning or physical line being terminated. That a "Lost-Carrier" will not be displayed if the call was terminated by the Total Control modem. We've started to show a large number of disconnections in an area and all of them are reported in Radius as "Lost-Carrier." Before we start telling customers that it "Isn't our equipment" I'd like some confirmation. Can anyone verify that? or direct me to some literature that would explain the reasons for a "Lost-Carrier" to be transmitted from a Total Control box to Radius Accounting. Thanks, Brian Brian Becker President, Poplar Bluff Internet http://www.semo.net TotallyFabricated.com Software http://www.TotallyFabricated.com Home of JerusalemPerspective.com http://www.JerusalemPerspective.com Personal Page http://Tonionio.com / http://BenjaminBecker.com

Subject: Re: (usr-tc) static to dynamic
From: D A Substanley <das@gol.com>
Date: 2000-01-27 12:33:12

Enable nmc chassis awareness das David Swearingin (david@carolnet.com) spake: > How do I "set chassis slot x type" from static to dynamic? > > David > __________________________________________________ > David Swearingin (david@carolnet.com) > CARROLLTON INTERNET SERVICE (www.carolnet.com) > First Financial Group, Inc. > 11 N. Folger, Carrollton, MO 64633 > 660-542-3002 Fax 660-542-3003 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: (usr-tc) Radius Framed-Route problem
From: Richard Stuplich <dick@dwave.net>
Date: 2000-01-27 12:57:15

zaza Password = "UNIX" User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 207.0.68.214, Framed-Netmask = 255.255.255.255, Framed-Route = "207.0.68.213 207.0.68.214 1" Framed-Compression = Van-Jacobsen-TCP-IP, Idle-Timeout = 0, Framed-MTU = 1500 When this user logs in the local net route for the hiperarc is gone. They logout and it is back again. Like this it doesn't break the local net rout, but then again the 2nd address doesn't work for the customer. zaza Password = "UNIX" User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 207.0.68.214, Framed-Netmask = 255.255.255.255, Framed-Route = "207.0.68.213/32 207.0.68.214 1" Framed-Compression = Van-Jacobsen-TCP-IP, Idle-Timeout = 0, Framed-MTU = 1500 What is the correct way to route a 2nd IP address, or small subnet, to a dialup user? Brian Becker wrote: > We've been told by 3Com reps that when Radius shows "Lost-Carrier" as the > disconnect reason, it is solely caused by the user modem shutting down with > no warning or physical line being terminated. That a "Lost-Carrier" will not > be displayed if the call was terminated by the Total Control modem. > > We've started to show a large number of disconnections in an area and all of > them are reported in Radius as "Lost-Carrier." Before we start telling > customers that it "Isn't our equipment" I'd like some confirmation. > > Can anyone verify that? or direct me to some literature that would explain > the reasons for a "Lost-Carrier" to be transmitted from a Total Control box > to Radius Accounting. > > Thanks, > Brian > > Brian Becker > President, Poplar Bluff Internet > http://www.semo.net > TotallyFabricated.com Software > http://www.TotallyFabricated.com > Home of JerusalemPerspective.com > http://www.JerusalemPerspective.com > Personal Page > http://Tonionio.com / http://BenjaminBecker.com > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) ARC Filters
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 2000-01-27 13:14:21

Subject: RE: (usr-tc) ARC Filters
From: Brian <signal@shreve.net>
Date: 2000-01-27 13:21:21

On Thu, 27 Jan 2000, Mike Wronski wrote: > Try ACCEPT instead of PERMIT.. Its line 020 that is first error... > -M That worked. And on my final line I had like 650 ACCEPT; and it didn't like that, it wanted PERMIT!! I didn't see where it explained the differences of PERMIT/ACCEPT. In the docs, it actually says: (p. 12-5 4.2 product guide) Specifying the Filtering Action You can specif the filtering action for each protocol section that determines whether a packet is accepted or rejected if no match occurs with any of the rules defined in the section. To do so, enter one of the following values as the last rule line of the section: o ACCEPT o DENY yet, it really wants PERMIT as the last rule, not ACCEPT. And as you pointed out, it wants you to use ACCEPT's (not PERMIT's) in your normal rules.............is their a method to the madness? Brian > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian > |Sent: Thursday, January 27, 2000 10:54 AM > |To: USRobotics TC Mailing List > |Subject: (usr-tc) ARC Filters > | > | > | > |Does the ARC Filter have a limit of 20 rules or something? > | > |I am making a filter and its erroring on line 20, and I don't see the > |error: > | > |HiPer>> verify filter filter_in > |FM: In filter file filter_in, protocol IP, unexpected symbols in > |action at line 20 > | > |here is the first 28 or so lines................rule 170 is what its > |considering line 20. > | > |#filter > |IP: > |010 AND tcp-dst-port = 20; > |020 PERMIT dst-addr = 208.206.76.57/32; > |030 AND tcp-dst-port = 20; > |040 PERMIT dst-addr = 208.206.76.58/32; > |050 AND tcp-dst-port = 20; > |060 PERMIT dst-addr = 208.206.76.5/32; > |070 AND tcp-dst-port = 20; > |080 PERMIT dst-addr = 208.206.76.13/32; > |090 AND tcp-dst-port = 20; > |100 PERMIT dst-addr = 208.206.76.33/32; > |110 AND tcp-dst-port = 20; > |120 PERMIT dst-addr = 208.206.76.45/32; > | > |130 AND tcp-dst-port = 21; > |140 PERMIT dst-addr = 208.206.76.57/32; > |150 AND tcp-dst-port = 21; > |160 PERMIT dst-addr = 208.206.76.58/32; > |170 AND tcp-dst-port = 21; > |180 PERMIT dst-addr = 208.206.76.5/32; > |190 AND tcp-dst-port = 21; > |200 PERMIT dst-addr = 208.206.76.13/32; > |210 AND tcp-dst-port = 21; > |220 PERMIT dst-addr = 208.206.76.33/32; > |230 AND tcp-dst-port = 21; > |240 PERMIT dst-addr = 208.206.76.45/32; > | > | > | > |----------------------------------------------------- > |Brian Feeny (BF304) signal@shreve.net > |318-222-2638 x 109 http://www.shreve.net/~signal > |Network Administrator ShreveNet Inc. (ASN 11881) > | > | > |- > | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > | with "unsubscribe usr-tc" in the body of the message. > | For information on digests or retrieving files and old messages send > | "help" to the same address. Do not use quotes in your message. > | > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) static to dynamic
From: D A Substanley <das@gol.com>
Date: 2000-01-27 13:32:38

Whoops, I meant enable nmc dynamic_slot_assignment Sorry about that. das David Swearingin (david@carolnet.com) spake: > You wrote: > > > From: D A Substanley <das@gol.com> > > To: usr-tc@lists.xmission.com > > Date: Thu, 27 Jan 2000 12:33:12 +0900 > > Subject: Re: (usr-tc) static to dynamic > > > > > > Enable nmc chassis awareness > > > > das > > Didn't work for me. > > David > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) static to dynamic
From: D A Substanley <das@gol.com>
Date: 2000-01-27 14:24:22

Interesting... I was able to do it the first time: Test Two>>li chassIS Slot Owner Description Ports Type Console 1 YES --EMPTY-- 0 STATIC NO 2 YES --EMPTY-- 0 STATIC NO 3 YES --EMPTY-- 0 STATIC NO 4 YES --EMPTY-- 0 STATIC NO 5 YES --EMPTY-- 0 STATIC NO 6 YES --EMPTY-- 0 STATIC NO 7 YES --EMPTY-- 0 STATIC NO 8 YES --EMPTY-- 0 STATIC NO 9 YES --EMPTY-- 0 STATIC NO 10 YES --EMPTY-- 0 STATIC NO 11 YES --EMPTY-- 0 STATIC NO 12 YES --EMPTY-- 0 STATIC NO 13 NO --EMPTY-- 0 STATIC NO 14 NO --EMPTY-- 0 STATIC NO 15 NO --EMPTY-- 0 STATIC NO 16 NO --EMPTY-- 0 STATIC NO Test Two>>enable nmc dynAMIC_SLOT_ASSIGNMENT Test Two>>li chassis Slot Owner Description Ports Type Console 1 YES 24 Channel High Density Modem 23 DYNAMIC YES 2 YES 24 Channel High Density Modem 23 DYNAMIC YES 3 YES 24 Channel High Density Modem 23 DYNAMIC YES 4 YES 24 Channel High Density Modem 23 DYNAMIC YES 5 YES 24 Channel High Density Modem 23 DYNAMIC YES 6 YES 24 Channel High Density Modem 23 DYNAMIC YES 7 YES 24 Channel High Density Modem 23 DYNAMIC YES 8 YES 24 Channel High Density Modem 23 DYNAMIC YES 9 YES 24 Channel High Density Modem 23 DYNAMIC YES 10 YES 24 Channel High Density Modem 23 DYNAMIC YES 11 YES 24 Channel High Density Modem 23 DYNAMIC YES 12 YES 24 Channel High Density Modem 23 DYNAMIC YES 13 NO --EMPTY-- 0 STATIC NO 14 NO --EMPTY-- 0 STATIC NO 15 NO HiPer Access Router NAC 0 DYNAMIC NO 16 NO HiPer Access Router NAC 0 DYNAMIC NO But I can't do it again. das David Swearingin (david@carolnet.com) spake: > You wrote: > > > From: D A Substanley <das@gol.com> > > To: usr-tc@lists.xmission.com > > Date: Thu, 27 Jan 2000 13:32:38 +0900 > > Subject: Re: (usr-tc) static to dynamic > > > > > > Whoops, I meant enable nmc dynamic_slot_assignment > > > I tried that also, but a li chas still shows slot 2-13 as type STATIC > > David > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: (usr-tc) Strange Speed Problems
From: Mark Lemmert <cto@athenet.net>
Date: 2000-01-27 17:22:25

I have encountered two problems recently regarding connect speeds that have just plain baffled me. In one location I moved to a new building and switched telcos (Ameritech -> TDS Metrocom) at the same time. Ever since then I have received a huge number of complaints from people saying their connect speeds dropped. An example drop would be from 52000 to 38666. A few people have said they connect faster but they are by far the minority. I have another POP where I moved it from one location to another. It is the same telco but different COs. The equipment is same equipment that with in the original location. I have the same problem here, people report that there connect speeds have gone down. I am at a compete loss at how to approach this problem. My first suspicion is that it is a telco problem since that is the thing that really changed. If that is the problem I don't know how to even go about approaching them with it with enough evidence to get them to actually take the issue seriously (you know telcos). Any advice anybody can offer on how to troubleshoot a situation like this would be greatly appreciated! I am running 2.0.81 in both locations. I'm running ARC 4.2.32 -1 -MGL Mark Lemmert CTO AthEnet Data Exchange 920-954-9799 mark.lemmert@athenet.net

Subject: (usr-tc) Equipment List Confirmation
From: S O Okeyo <okeyoso@skyweb.co.ke>
Date: 2000-01-27 18:14:49

I am unable to get confirmation for my equipment list membership. I have mailed confirmation according to instructions several times but each time I get a message back that the number I have put after "OK" is not right yet I put in the actual number mailed to me by Sparklist. I have been typing OK######E on the Subjet line. Can someone help me out of this? Okeyo

Subject: Re: (usr-tc) Strange Speed Problems
From: Brian Elfert <brian@citilink.com>
Date: 2000-01-27 19:04:22

On Thu, 27 Jan 2000, Mark Lemmert wrote: > I have encountered two problems recently regarding > connect speeds that have just plain baffled me. > > In one location I moved to a new building and > switched telcos (Ameritech -> TDS Metrocom) > at the same time. Ameritech is likely to have much better trunking than any CLEC. The CLEC has to connect to the Ameritech COs somehow. If the CLEC doesn't have enough trunks to the COs, calls are likely to route through a tandem, which may slow calls down. We used a terrible CLEC once that routed many calls through a tandem, instead of having direct trunking to each US West CO. Connect speeds were bad, x2 didn't work in many cases, and callers got lots of fasy busies. We switched to another CLEC that has run fiber to most US West COs, and we are very happy now. Brian

Subject: Re: (usr-tc) Lost Carrier
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-27 20:12:59

Then why are there so many disconnect reasons in the USR dictionary? The DSP's should signal as close to the disconnect reason as possible. I also was to by 3Com that rcvdGatewayDiconnect was also a 'generic' disco term.... how many 'generic' terms is 3Com gonna use?? Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Fri, 28 Jan 2000, Campbell Simpson wrote: > Brian > > The "Lost-Carrier" you get in your RADIUS files is very generic. We also see a lot of lost carrier in our RADIUS logs. The modems on the TCHs can report on a huge range of disconnection reasons, but many of the individual reasons get lumped together as lost carrier with RADIUS. I would suggest looking at your modem disconnection reasons under TCM under performance monitoring menu option and seeing what the modems are reporting as their disconnection reasons. You may find that many of the disconnection reasons are quite acceptable. > > Hope this helps > > Campbell > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Rick <rallan@monmouth.com>
Date: 2000-01-27 21:10:49

Tatai SV Krishnan wrote: > On Tue, 25 Jan 2000, Rick wrote: > > > I would be happy to hear what others think of 3coms implementation of OSPF? > > > > We have been testing it on 4 boxes for afew months now and have noticed one > > major flaw. If an 8 character auth_key is used it has to be entered anytime > > the box reboots. > > > > Krish, maybe you can look into this. I confirmed this in my own testing using > > numerous combinations of 4-8 character ospf keys and ONLY 8 character keys > > cause this bug. > > Hmmm.. So a 8 charecter authkey for OSPF will reboot the ARC., Bad - will > check it out and hopefully it is already fixed in later ER versions will > let you know > > regards > > krish > Krish, an 8 character does NOT make the arc reboot. Rather an arc does not retain an 8 character ospf key once rebooted. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rick Allan / rick@monmouth.com | Connect to a Backbone not a Wishbone Head of Network Engineering | Monmouth Internet Corporation 732-842-5366=====extension 102 | http://www.monmouth.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Subject: Re: (usr-tc) static to dynamic
From: D A Substanley <das@gol.com>
Date: 2000-01-27 23:40:24

Good information, thanks Krish. One question, how do you remove the port from static configuration. das Tatai SV Krishnan (tkrishna@bubba.ae.usr.com) spake: > If you have setup a chassis in which you have programed a slot to be > static and save that configuration, once done it will remain static > unless and untill removed manually. > > For your ports to be dynamic, here is what you need to do > > First remove the port from static configuration > Then enable nmc chassis awarenss. > When you do a sh nmc > you will see three options in there > > nmc chassis awarness > DSA > DSA Idle rebla > > if you have only one hiper arc in the chassis then enable nmc chassis > awarness and disable the other two. > > If you have more than one hyper arc and want to maintain dynamic > configuration then enable all three. > > If you have two hiper arcs and you want to make static configurations > disable all the three in nmc chassis awarness > > and then reboot the card. > > > krish > > On Wed, 26 Jan 2000, David Swearingin wrote: > > > You wrote: > > > > > From: D A Substanley <das@gol.com> > > > To: usr-tc@lists.xmission.com > > > Date: Thu, 27 Jan 2000 12:33:12 +0900 > > > Subject: Re: (usr-tc) static to dynamic > > > > > > > > > Enable nmc chassis awareness > > > > > > das > > > > Didn't work for me. > > > > David > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) static to dynamic
From: D A Substanley <das@gol.com>
Date: 2000-01-28 00:59:17

Great, thanks! das Tatai SV Krishnan (tkrishna@bubba.ae.usr.com) spake: > Well in order to remove it from static configuration you have set the > owner of that slot as no - Basically say if you have slot 1 configured as > static then you would issue > > set chass slot 1 o n > > enable nmc chas > save all > reboot > > krish > > On Thu, 27 Jan 2000, D A Substanley wrote: > > > Good information, thanks Krish. > > One question, how do you remove the port from static configuration. > > > > das > > > > Tatai SV Krishnan (tkrishna@bubba.ae.usr.com) spake: > > > > > If you have setup a chassis in which you have programed a slot to be > > > static and save that configuration, once done it will remain static > > > unless and untill removed manually. > > > > > > For your ports to be dynamic, here is what you need to do > > > > > > First remove the port from static configuration > > > Then enable nmc chassis awarenss. > > > When you do a sh nmc > > > you will see three options in there > > > > > > nmc chassis awarness > > > DSA > > > DSA Idle rebla > > > > > > if you have only one hiper arc in the chassis then enable nmc chassis > > > awarness and disable the other two. > > > > > > If you have more than one hyper arc and want to maintain dynamic > > > configuration then enable all three. > > > > > > If you have two hiper arcs and you want to make static configurations > > > disable all the three in nmc chassis awarness > > > > > > and then reboot the card. > > > > > > > > > krish > > > > > > On Wed, 26 Jan 2000, David Swearingin wrote: > > > > > > > You wrote: > > > > > > > > > From: D A Substanley <das@gol.com> > > > > > To: usr-tc@lists.xmission.com > > > > > Date: Thu, 27 Jan 2000 12:33:12 +0900 > > > > > Subject: Re: (usr-tc) static to dynamic > > > > > > > > > > > > > > > Enable nmc chassis awareness > > > > > > > > > > das > > > > > > > > Didn't work for me. > > > > > > > > David > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > -- > > ______________________________________________ > > Alex Substanley Exodus Communications K.K. > > Engineering Department > > Das Man TEL: 81-3-5334-1700 > > Systems Engineer FAX: 81-3-5334-1711 > > ______________________________________________ > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) Ascend to 3com
From: The NOC $COX Internet$ <usrtc@tyler.net>
Date: 2000-01-28 09:48:33

Brian, We are having to make the same decision. Our decision is to move everything over to Ascend Maxes because they are a much more stabile unit than the 3Com gear. We hardly ever have any problems with our Maxes yet it seems like we always have issues with the 3Com TCH. Also, Ascend (now called Lucent) doesn't have as many problems with v.90 and very few problems with the Rockwell chipset. And Lucent's support is better than 3coms. Bryan NOC Technician COX Internet ----- Original Message ----- Sent: Wednesday, January 26, 2000 5:06 PM > We are in the process of merging two ISPs. Our ISP runs on > the 3Com Hiper Arch Chassis the other ISP runs on Ascend. > Since we both use ELI for our Channelized T-1s we are > considering porting their dial in number over to our 3Com chassis > at our location.. > What problems should we anticipate moving customers from > an ASCEND unit to 3com? Both are using the "V90 standard." > protocol. Would we be better off using > their ASCEND equipment? Any feedback is appreciated. > > > Thanks -Brian > > >

Subject: Re: (usr-tc) HiPer ARC 4.2.32-1
From: Jeff Carneal <jeff@apex.net>
Date: 2000-01-28 10:21:47

On Thu, 27 Jan 2000, Rick wrote: > Krish, an 8 character does NOT make the arc reboot. Rather an arc does > not retain an 8 character ospf key once rebooted. We have noticed the same. -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (270) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.

Subject: Re: (usr-tc) Lost Carrier
From: Campbell Simpson <campbell.simpson@telecom.co.nz>
Date: 2000-01-28 11:47:40

Brian The "Lost-Carrier" you get in your RADIUS files is very generic. We also = see a lot of lost carrier in our RADIUS logs. The modems on the TCHs can = report on a huge range of disconnection reasons, but many of the individual= reasons get lumped together as lost carrier with RADIUS. I would suggest = looking at your modem disconnection reasons under TCM under performance = monitoring menu option and seeing what the modems are reporting as their = disconnection reasons. You may find that many of the disconnection reasons = are quite acceptable. Hope this helps Campbell

Subject: (usr-tc) Been Gone for a long time
From: John Lange <microjl@palacenet.net>
Date: 2000-01-28 13:36:02

HI I have been gone for over a year and am wondering if this list is still active? Or if I should be looking in another place. JOhn :} ----- Whatever you do, work at it with all your heart, as working for the Lord, not for men >Colossians 3:23 (NIV) John C. Lange, Sr. PALACE dot NET, INC. microjl@palacenet.net MICRO-TECH Computers, Inc. 608.742.1601 & 6980 1819 New Pinery Road http://www.palacenet.net/ Portage, WI 53901 MSCE Training for only $150.00 - http://dpec.palacenet.net/ All 200+ Web Based Courses for $150.00 Per Year - "Really" --- __o --- _-\<,_ Fastest Service in Town --- (_)/ (_)

Subject: (usr-tc) failed DSP
From: Mike <mikew@ll.net>
Date: 2000-01-28 13:40:01

I have a new DSP card that first of all wouldn't allow me to flash new code to it through TCM, it kept giving a "TFTP error: Access violation" error. So I hooked up to the console port and was able to upload the 2.0.51 code to it. After I reset the card it came up fine and reported the correct software version, but after a couple of hours TCM reports the card failed. I can do a hardware reset and it will be fine for a few more hours, but it will eventually report failed. What can I do to resolve this? Thanks. -- Mike Wilker Director of Network Operations Local Link, Inc.

Subject: (usr-tc) GTD5 NFAS and Dual Pri Card
From: USRobotics TC Mailing List <usroboticstcmailinglist@imagenisp.com>
Date: 2000-01-28 14:18:02

I have a TC Chassis with a Dual Pri Card (3.1.5), 12 A/D Quad's (6.1.6), NSC (3.8.1) & NMC (6.1.17). This chassis was originally setup and working on a DMS100 switch, but I've since moved it to another location which employs a GTD5 switch, same Telco. The new location only has one PRI, and I have it plugged into the first Port. All lights on the chassis are green. The chassis is not answering and only returning a busy signal, not a fast busy, but a normal busy. The Telco is reporting that they are receiving a "D channel protocol error." I have the following set Framing - ds1ESF Line Coding - b8zs Switch Type - 5ESS I have also double checked that the A/D's are setup for PRI. The Telco is suggesting that I turn off NFAS, but I'm not quite sure how to do that or if that would even fix the problem. I've also searched through the 3Com Knowledge Base, List Archive, TC Newsgroup and the net itself. Nothing yet. Any help most appreciated.

Subject: Re: (usr-tc) Been Gone for a long time
From: Brian <signal@shreve.net>
Date: 2000-01-28 15:59:50

On Fri, 28 Jan 2000, John Lange wrote: > HI > > I have been gone for over a year and am wondering if this list is still > active? Or if I should be looking in another place. > > JOhn :} This list is as active as ever. This is the best place to come for clues on TC gear. Their aren't as many "issues" these days with TC stuff, but alot of people here that can help you. Brian > > ----- Whatever you do, work at it with all your heart, as working for the > Lord, not for men >Colossians 3:23 (NIV) > > John C. Lange, Sr. PALACE dot NET, INC. > microjl@palacenet.net MICRO-TECH Computers, Inc. > 608.742.1601 & 6980 1819 New Pinery Road > http://www.palacenet.net/ Portage, WI 53901 > MSCE Training for only $150.00 - http://dpec.palacenet.net/ > All 200+ Web Based Courses for $150.00 Per Year - "Really" > > --- __o > --- _-\<,_ Fastest Service in Town > --- (_)/ (_) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) Been Gone for a long time
From: Brian <signal@shreve.net>
Date: 2000-01-28 15:59:50

Subject: Re: (usr-tc) failed DSP
From: Brian <signal@shreve.net>
Date: 2000-01-28 16:00:49

On Fri, 28 Jan 2000, Mike wrote: > I have a new DSP card that first of all wouldn't allow me to flash new code > to it through TCM, it kept giving a "TFTP error: Access violation" error. > So I hooked up to the console port and was able to upload the 2.0.51 code to > it. After I reset the card it came up fine and reported the correct > software version, but after a couple of hours TCM reports the card failed. > I can do a hardware reset and it will be fine for a few more hours, but it > will eventually report failed. What can I do to resolve this? Thanks. Make sure your write community string is correct. It sounds like the issue you are having is more of an NMC issue than a DSP issue. What NMC code? is it a HiperNMC? Is the NMC communities set right? Brian > > > -- > Mike Wilker > Director of Network Operations > Local Link, Inc. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Subject: Re: (usr-tc) failed DSP
From: Mike Wilker <mikew@ll.net>
Date: 2000-01-28 16:12:35

I have 8 other DSPs in this chassis, it is a HiperNMC running 6.2.17. Mike ----- Original Message ----- Sent: Friday, January 28, 2000 4:00 PM > On Fri, 28 Jan 2000, Mike wrote: > > > I have a new DSP card that first of all wouldn't allow me to flash new code > > to it through TCM, it kept giving a "TFTP error: Access violation" error. > > So I hooked up to the console port and was able to upload the 2.0.51 code to > > it. After I reset the card it came up fine and reported the correct > > software version, but after a couple of hours TCM reports the card failed. > > I can do a hardware reset and it will be fine for a few more hours, but it > > will eventually report failed. What can I do to resolve this? Thanks. > > Make sure your write community string is correct. It sounds like the > issue you are having is more of an NMC issue than a DSP issue. > > What NMC code? is it a HiperNMC? Is the NMC communities set right? > > Brian > > > > > > > > -- > > Mike Wilker > > Director of Network Operations > > Local Link, Inc. > > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > ----------------------------------------------------- > Brian Feeny (BF304) signal@shreve.net > 318-222-2638 x 109 http://www.shreve.net/~signal > Network Administrator ShreveNet Inc. (ASN 11881) > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Been Gone for a long time
From: Brian Elfert <brian@citilink.com>
Date: 2000-01-28 18:16:05

On Fri, 28 Jan 2000, John Lange wrote: > How are reliability issues? We've had one bad card out of 5 chassis installed here. We also have a number of portmaster products, and none of those has failed. > How about modem compatibility? Very good on the older quad modem cards. List members have reported various problems on the different releases for the HiperDSP cards. > Any issues I should be aware of? OSPF doesn't appear to work 100% yet. If you are routing subnets and such, you might need to use RIPv2 for a while. > How many of you purchase a support contract on ALL of your TC's or just a > few and wing it??? Supposedly, you have to buy support for every Total Control item you have. You can't pick and choose. Brian

Subject: Re: (usr-tc) Been Gone for a long time
From: John Lange <microjl@palacenet.net>
Date: 2000-01-28 18:17:49

HI & TIA I am now researching the possibility of converting from my Lucent PM-3's to USR TC's with DSP cards. How are reliability issues? How about modem compatibility? Any issues I should be aware of? How many of you purchase a support contract on ALL of your TC's or just a few and wing it??? Thanks JOhn :} ----- Whatever you do, work at it with all your heart, as working for the Lord, not for men >Colossians 3:23 (NIV) John C. Lange, Sr. PALACE dot NET, INC. microjl@palacenet.net MICRO-TECH Computers, Inc. 608.742.1601 & 6980 1819 New Pinery Road http://www.palacenet.net/ Portage, WI 53901 MSCE Training for only $150.00 - http://dpec.palacenet.net/ All 200+ Web Based Courses for $150.00 Per Year - "Really" --- __o --- _-\<,_ Fastest Service in Town --- (_)/ (_)

Subject: Re: (usr-tc) failed DSP
From: Nicolas St-Pierre <nstpierre@iasl.com>
Date: 2000-01-28 19:16:23

Hello Brian, If it's a new DSP, perhaps you can check if it's the new DSP model. These new cards show up as rev 0.49.0, and are easily recognizable when you pull them out: Double Sided, 6 DSPs on one side, 6 DSPs on the back DIP switch for Console port speed (the previous model had no dip switch for port speed) 2 empty DSP sockets on each side (used for the E1 model) Lack of daughterboard (E1) connectors, and penny sized PPC chips (instead of the rather big PPC chip on the older rev) I've had some trouble flashing these cards with TCM, but once I flashed them to 2.0.51 through the AUX port, they were fine and I was able to re-flash them succesfully with TCM. Nick Brian wrote: > > On Fri, 28 Jan 2000, Mike wrote: > > > I have a new DSP card that first of all wouldn't allow me to flash new code > > to it through TCM, it kept giving a "TFTP error: Access violation" error. > > So I hooked up to the console port and was able to upload the 2.0.51 code to > > it. After I reset the card it came up fine and reported the correct > > software version, but after a couple of hours TCM reports the card failed. > > I can do a hardware reset and it will be fine for a few more hours, but it > > will eventually report failed. What can I do to resolve this? Thanks. > > Make sure your write community string is correct. It sounds like the > issue you are having is more of an NMC issue than a DSP issue. > > What NMC code? is it a HiperNMC? Is the NMC communities set right? > > Brian > > > > > > > -- > > Mike Wilker > > Director of Network Operations > > Local Link, Inc. > > > > > > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > -- Nicolas St-Pierre Systems Engineer Internet Access Solutions Ltd. Tel (905) 469-4953 Fax (905) 469-4954

Subject: Re: (usr-tc) Lost Carrier
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-28 20:48:20

I posted just such a list last week. (Check the list archives, or see http://www.dcr.net/~mandrews/usrtoys) You need to look at more than just the Radius disconnect reason ... you need to look at the disconnect reason generated by the *modem* also. You can get these logged by Radius if you have your NMC log to your Radius accounting server, and enable the modems to send traps to Radius. I can't remember which trap it is exactly... one having to do with disconnects I think :) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Thu, 27 Jan 2000, Brian Becker wrote: > We've been told by 3Com reps that when Radius shows "Lost-Carrier" as the > disconnect reason, it is solely caused by the user modem shutting down with > no warning or physical line being terminated. That a "Lost-Carrier" will not > be displayed if the call was terminated by the Total Control modem. > > We've started to show a large number of disconnections in an area and all of > them are reported in Radius as "Lost-Carrier." Before we start telling > customers that it "Isn't our equipment" I'd like some confirmation. > > Can anyone verify that? or direct me to some literature that would explain > the reasons for a "Lost-Carrier" to be transmitted from a Total Control box > to Radius Accounting. > > Thanks, > Brian > > Brian Becker > President, Poplar Bluff Internet > http://www.semo.net > TotallyFabricated.com Software > http://www.TotallyFabricated.com > Home of JerusalemPerspective.com > http://www.JerusalemPerspective.com > Personal Page > http://Tonionio.com / http://BenjaminBecker.com > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Lost Carrier
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-28 20:52:37

rcvdGatewayDisconnect, and the others in the dictionary, are logged by the modem, not the ARC. "Lost-carrier" is logged by the ARC. "Received Gateway Disconnect" means that the ARC told the modem to hang up. (i.e. it dropped DTR, or the packet bus equivalent. :) So for that one, you hung up on the customer, rather than the other way around. Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Thu, 27 Jan 2000, Paul Farber wrote: > Then why are there so many disconnect reasons in the USR dictionary? The > DSP's should signal as close to the disconnect reason as possible. > > I also was to by 3Com that rcvdGatewayDiconnect was also a 'generic' disco > term.... how many 'generic' terms is 3Com gonna use?? > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Fri, 28 Jan 2000, Campbell Simpson wrote: > > > Brian > > > > The "Lost-Carrier" you get in your RADIUS files is very generic. We also see a lot of lost carrier in our RADIUS logs. The modems on the TCHs can report on a huge range of disconnection reasons, but many of the individual reasons get lumped together as lost carrier with RADIUS. I would suggest looking at your modem disconnection reasons under TCM under performance monitoring menu option and seeing what the modems are reporting as their disconnection reasons. You may find that many of the disconnection reasons are quite acceptable. > > > > Hope this helps > > > > Campbell > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Been Gone for a long time
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-28 22:49:06

Thus spake John Lange >How many of you purchase a support contract on ALL of your TC's or just >a few and wing it??? Oh...now you've done it...you've gone and opened up the support contract issue again. OK...just as a show of hands (e-hands?). How many of you have support contracts on your equipment? I wanna get a feel for how many people really do actually get the support. I'll keep track and post a summary. Lurkers, feel free to drop me a line privately if you'd like to continue lurking, I won't post names or anything...just totals of how many do and how many don't. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Been Gone for a long time
From: Kirk Mitchell <mitch@keyconn.net>
Date: 2000-01-28 23:06:21

At 10:49 PM 1/28/00 -0500, Jeff Mcadams wrote: >OK...just as a show of hands (e-hands?). How many of you have support >contracts on your equipment? I wanna get a feel for how many people >really do actually get the support. I'll keep track and post a summary. >Lurkers, feel free to drop me a line privately if you'd like to continue >lurking, I won't post names or anything...just totals of how many do and >how many don't. :) My support contract ran out in August. I could only afford to replace it with the software upgrade contract. Pay-per-incident will have to be my last-ditch bacon-saver if something comes up that I can't resolve by myself or via this list. -- Kirk Mitchell-General Manager mitch@keyconn.net Keystone Connect Unlock Your World Altoona, PA 814-941-5000/886-2500 http://www.keyconn.net

Subject: Re: (usr-tc) Been Gone for a long time
From: stevec <stevec@mail.computer-geeks.com>
Date: 2000-01-29 05:32:34

We are a new ISP and all our equipment (routers, USR TC) were installed by our TELCO provider for warranty purposes. However, I would like to learn as much a possible about our equipment, specifically our TC chassis. I don't know what kind of cards we have, what revisions, etc. This is all information I would like to know. Where can I get familiar with the equipment I have? ---------- Original Message ---------------------------------- Reply-To: usr-tc@lists.xmission.com >At 10:49 PM 1/28/00 -0500, Jeff Mcadams wrote: >>OK...just as a show of hands (e-hands?). How many of you have support >>contracts on your equipment? I wanna get a feel for how many people >>really do actually get the support. I'll keep track and post a summary. >>Lurkers, feel free to drop me a line privately if you'd like to continue >>lurking, I won't post names or anything...just totals of how many do and >>how many don't. :) > >My support contract ran out in August. I could only afford to replace it >with the software upgrade contract. Pay-per-incident will have to be my >last-ditch bacon-saver if something comes up that I can't resolve by myself >or via this list. > > >-- >Kirk Mitchell-General Manager mitch@keyconn.net >Keystone Connect Unlock Your World >Altoona, PA 814-941-5000/886-2500 http://www.keyconn.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > -- Steve Cobb stevec@computer-geeks.com Computer Geeks www.computer-geeks.com --

Subject: Re: (usr-tc) Been Gone for a long time
From: Dave Lajoie <dave@ncia.net>
Date: 2000-01-29 08:46:43

Jeff, We _do_ have a contract for the equipment we have. I have made use of it to solve config, abnormal function, and RMA. At the risk of starting something I will have to say we have been treated 'well' for the most part. Dave Lajoie RA Administrator North Country Internet Access E-Mail: dave@ncia.net On Fri, 28 Jan 2000, Jeff Mcadams wrote: > Thus spake John Lange > >How many of you purchase a support contract on ALL of your TC's or just > >a few and wing it??? > > Oh...now you've done it...you've gone and opened up the support contract > issue again. > > OK...just as a show of hands (e-hands?). How many of you have support > contracts on your equipment? I wanna get a feel for how many people > really do actually get the support. I'll keep track and post a summary. > Lurkers, feel free to drop me a line privately if you'd like to continue > lurking, I won't post names or anything...just totals of how many do and > how many don't. :) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Been Gone for a long time
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-29 09:57:55

Thus spake Dave Lajoie > We _do_ have a contract for the equipment we have. I have made >use of it to solve config, abnormal function, and RMA. At the risk of >starting something I will have to say we have been treated 'well' for >the most part. Alright. :) Fair enough. And to be fair to 3Com...my experience has also been that if you have a support contract, or through some other means manage to get help, that they help they provide any more is pretty decent, courteous, and the techs work their butts off to help. I have to give 3Com credit that they have addressed these problems over the past couple of years. However, the problems with the structure, and rules surrounding *obtaining* the support contracts are still seriously problematic. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Looking for TCH Fan tray
From: M. Tsai <tsaim@mft.com>
Date: 2000-01-29 12:18:35

Hi All, tsaim@mft.com - off line address please Hopefuly , you don't mind that I am looking for buying a FAN tray for my unfaned TCH. New or used is OK. Our TCH chasis is the kind that has no internal base fan embeded to it. If you have the added on FAN tray, please email me off line and let me know its cost. Thanks Meng tsaim@mft.com - off line address please.

Subject: (usr-tc) gaming modem
From: Allen Marsalis <am@shreve.net>
Date: 2000-01-29 16:54:25

So what's the low down on the 3com gaming modem they have on their webpage: http://www.3com.com/client/pcd/products/prod-gamemod5613-int.html Did anyone ever get their hands on one? What does it do differently than a standard 3com 56k modem? I certainly didn't see/hear any hype that I expected over the holidays. but I guess gamers are a pretty small minority overall.. am

Subject: RE: (usr-tc) Been Gone for a long time
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-29 18:25:46

I don't. It's cheaper to keep spare equipment on-hand and buy per-incident support if I'm really stuck. > -----Original Message----- > From: Jeff Mcadams [SMTP:jeffm@iglou.com] > Sent: Friday, January 28, 2000 11:49 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Been Gone for a long time > > Thus spake John Lange > >How many of you purchase a support contract on ALL of your TC's or just > >a few and wing it??? > > Oh...now you've done it...you've gone and opened up the support contract > issue again. > > OK...just as a show of hands (e-hands?). How many of you have support > contracts on your equipment? I wanna get a feel for how many people > really do actually get the support. I'll keep track and post a summary. > Lurkers, feel free to drop me a line privately if you'd like to continue > lurking, I won't post names or anything...just totals of how many do and > how many don't. :) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Soft busy on HDM
From: D A Substanley <das@gol.com>
Date: 2000-01-29 19:43:14

Thanks, Kobayashi-san. That seems to work fine. I am sure my customers appreciate not having to be disconnected for maintenance. ^_^; das Yuichi_Kobayashi@jp.3com.com (Yuichi_Kobayashi@jp.3com.com) spake: > > > Das, > > Regarding of software busy out , from TCM , you can go to program setting of > SPAN line , then select blocking , chose block all , then call connecting HDSP > will not be disconnected and new coming call will be busied out , that the way > Japanese customer doing in Japan . From command , and selecting time-slot , > selecting all with H/W busy or S/W busy won't work in INS1500 . Please let us > know your result of doing this. > > Regards, > Kobayashi. > > >

Subject: (usr-tc) Quad modem x2 tx level
From: Dan Borlovan <danb@dnttm.ro>
Date: 2000-01-30 11:22:41

Hello, In order to try improve user x2 connect speeds, I tried to raise the x2 transmit level on quad modem cards. The problem is I have two quad modem models (analog/digital vs. digital only) and the first don't let me go higher than -12dB, while the other ones happily accepted -10dB (this is as far as I may go from the telco point of view) Now the only difference between modems is the analog capability (referring to the possibility of getting signal from nic or pritdm) and the country code. All modems are setup as digital, taking signal via pritdm from e1 card. Is there anything I can do about this one? Dan -- Dan Borlovan <danb@dnttm.ro> System Administrator, Network Operation Center Dynamic Network Technologies - Timisoara, Romania Telefon: +40-56-204967 FAX: +40-56-220201

Subject: (usr-tc) Connect Speed issues
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 2000-01-30 17:15:08

Folks, I know this issue has been belabored numerous times but I thought I'd kick the dead horse one more time. Recently we have had 3 customers with HSP modems either leave or threaten to leave due to them being able to connect to other ISPs at higher speeds. As a last resort on two of them we replaced their modems with 3Com modems and they stayed. Here is what we saw: HSP 3Com Cust 1 26400 37333 Cust 2 29333 41666 In both cases all that was changed is the modem. As expected the connections got more stable too (i.e. less disconnects). In the case of the third customer he won't replace his modem but swears he gets 40K connections with other ISPs. I tend to believe him and we will probably lose him. In all cases when we looked at the analog stats, all we saw was a slight rolloff at 3750 but everything else looked good. With the HSP and other el cheapo' modems now shipping as standard issue on the low end machines, including the dreaded E-Machines, I suspect this problem is going to get worse not better unless 3Com can help us here. I am running the latest Quad code and 2.0.51 DSP code. Jeff CMPQwk 1.42-21 9999

Subject: (usr-tc) Booting a user
From: Steve Sherwick <hostmaster@minnmicro.com>
Date: 2000-01-30 17:34:40

This is a multi-part message in MIME format. ------=_NextPart_000_0011_01BF6B48.49CDBAA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi there, I have couple business users running demand dial accounts that are problematic to me. They don't seem to get their systems programmed to demand dial. Since they are running "right to resell" accounts that I'm suppossed to be able to resell in the evenings I wanna boot them when they get anal. The knowlege base says I can login and type show session <user> and get a S number for their session. You're supposed to then do a reset of that s number. I'm afraid the generic Neserver instructions don't match this Hiper monstor I have as it doesn't report an S number at all, It reports the slot/port. Reset doesn't seem to know what to do with it.... So how does one boot a user on this beast Thanks, Steve Minnetonka Micro - Superior Communications Services Since 1984 ------=_NextPart_000_0011_01BF6B48.49CDBAA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII+jCCAq0w ggIWoAMCAQICAwHD2jANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAx OTk5LjkuMTYwHhcNOTkxMjAzMjM1OTU5WhcNMDAxMjAyMjM1OTU5WjBKMR8wHQYDVQQDExZUaGF3 dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhob3N0bWFzdGVyQG1pbm5taWNyby5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMMvpObXaWvSTbvXhTh6aa84XvvaLsPZ0spX cyPcIS+He3yswL2gP980QNQjG5zsd2nFYd9YQ32dQTG9ZIDJfWikQQUFK4aEcE5Tn2GTTVpRZjnV Tl8hrk5uq+pkSnrartoZBMwtYKY12uMcsIToh/6wbwsKDiI+3XApjPdP5/WFAgMBAAGjVjBUMCMG A1UdEQQcMBqBGGhvc3RtYXN0ZXJAbWlubm1pY3JvLmNvbTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQY MBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAEIAP9OIkvQnKs9poSjB gMcfb6lrcFXDvqtvNGwB+PzyqjnT8Z6upZnOIawSyFz98YWRrcwpsfk+0Sn8R0ZerOcp2sBU8JeJ vpnsTA7IE+9yMCzzINbsN/rlJLYK17FGqi7+Unkkf3uHI5806ieOHv7r/QLoB5pTM/W+vh8rbsMQ MIIDFDCCAn2gAwIBAgIBCzANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTk5MDkxNjE0MDE0MFoXDTAxMDkxNTE0MDE0MFowgZQxCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYD VQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz b25hbCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCz aVqX1NAWC3q1xV3pIZwjcs0STEv3fs/H+8pyJPRCUqxXleN7YXoXhOf9cjk4lLTq7WWnkgZeveBl 9hm7lHl2TD65aHB1hBz0EXQAvAUsTwkDFzHM9EHUcsamXeKIRLCLLsRN8fDWhT5s85WUeJF+QOmc 0Y0VV47Cc+Uw3kb1TwIDAQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJ wnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBAGvGWekx+um27LED2N9ycv6RYEjq xlXde/BnjsZhcOdtwqU32J23FyhWBYvdXHVvxpGQxmxmcRPQEHxrkW+G4CE2LcHX6rIJrc8tbcaD Upv7u/6ch538t+l0kuRcl678fqzKDW9yemcsa3P1hvmd9QBu9B0Hzp2egmMp75MJflXeMIIDLTCC ApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX 1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5E rHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Ha o5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH 7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJs YHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1 iwzdUYRr5PjRzneigTGCAgAwggH8AgEBMIGcMIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQL ExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5 OTkuOS4xNgIDAcPaMAkGBSsOAwIaBQCggbowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDAwMTMwMTczNDQwWjAjBgkqhkiG9w0BCQQxFgQUOnoLrrVipttc7+ow5idP UapXyZUwWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0wDQYJKoZIhvcNAQEBBQAE gYB+M7SQkl92JFPMvzbIw4FBHsqbkXJFqKj8kllWsCTvTYdsD8MGH5a3iJwSfmMQZq/spna0i2jc YpN8ELIuiScjaRAmSm/LRb+l6+smx0oJB4MTPz0vN/zUNH5wTdaw6l0pBh9hSr+d+SOWqCvZUtMQ rd64sS3NWt1SZv/6vDYBPgAAAAAAAA== ------=_NextPart_000_0011_01BF6B48.49CDBAA0--

Subject: Re: (usr-tc) Connect Speed issues
From: Mark E. Levy <mark@fsi.net>
Date: 2000-01-30 17:37:44

I second the 3Com compatibility issue problem. In rare cases, I've sold (not given) customers with chronic connect problems a USR modem. I'll sell it below cost (about $100) provided that they pay for a year of service in advance. That way, I'm reasonably assured that they're not going to take my modem and bug out anyway. It's cheaper in the long run to give away a few modems than to buy, say, an Ascend box (and it's corresponding PRI or CT1). It can't be part of my existing trunk group, so I would need to populate it with more than just the troublesome customers in order to make it financially worthwhile. Paul Farber wrote: > 3Com has long had interoperability issues. > > Giving away modems is not good fort he bottom line. You may want to get > an ascend rack and have 'troublesome' modems call that box. > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Sun, 30 Jan 2000, Jeff Binkley wrote: > > > > > > > > > Folks, > > > > I know this issue has been belabored numerous times but I thought I'd > > kick the dead horse one more time. Recently we have had 3 customers > > with HSP modems either leave or threaten to leave due to them being able > > to connect to other ISPs at higher speeds. As a last resort on two of > > them we replaced their modems with 3Com modems and they stayed. Here is > > what we saw: > > > > HSP 3Com > > > > Cust 1 26400 37333 > > Cust 2 29333 41666 > > > > > > In both cases all that was changed is the modem. As expected the > > connections got more stable too (i.e. less disconnects). In the case of > > the third customer he won't replace his modem but swears he gets 40K > > connections with other ISPs. I tend to believe him and we will probably > > lose him. In all cases when we looked at the analog stats, all we saw > > was a slight rolloff at 3750 but everything else looked good. With the > > HSP and other el cheapo' modems now shipping as standard issue on the > > low end machines, including the dreaded E-Machines, I suspect this > > problem is going to get worse not better unless 3Com can help us here. > > I am running the latest Quad code and 2.0.51 DSP code. > > > > > > Jeff > > > > CMPQwk 1.42-21 9999 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.net

Subject: Re: (usr-tc) Connect Speed issues
From: Paul Farber <farber@admin.f-tech.net>
Date: 2000-01-30 18:29:01

3Com has long had interoperability issues. Giving away modems is not good fort he bottom line. You may want to get an ascend rack and have 'troublesome' modems call that box. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sun, 30 Jan 2000, Jeff Binkley wrote: > > > > Folks, > > I know this issue has been belabored numerous times but I thought I'd > kick the dead horse one more time. Recently we have had 3 customers > with HSP modems either leave or threaten to leave due to them being able > to connect to other ISPs at higher speeds. As a last resort on two of > them we replaced their modems with 3Com modems and they stayed. Here is > what we saw: > > HSP 3Com > > Cust 1 26400 37333 > Cust 2 29333 41666 > > > In both cases all that was changed is the modem. As expected the > connections got more stable too (i.e. less disconnects). In the case of > the third customer he won't replace his modem but swears he gets 40K > connections with other ISPs. I tend to believe him and we will probably > lose him. In all cases when we looked at the analog stats, all we saw > was a slight rolloff at 3750 but everything else looked good. With the > HSP and other el cheapo' modems now shipping as standard issue on the > low end machines, including the dreaded E-Machines, I suspect this > problem is going to get worse not better unless 3Com can help us here. > I am running the latest Quad code and 2.0.51 DSP code. > > > Jeff > > CMPQwk 1.42-21 9999 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Connect Speed issues
From: Ed <ed@taylors.com>
Date: 2000-01-30 18:31:41

It's sad but true... we have seen repeatedly that Ascend has less problems. Too bad 3com thinks things are better now because their is less noise about it. However nothing is further from the truth... people are just giving up. They just will not listen ;-( So instead of the frustration more and more people are switching to Ascend... sooner or later it will hit 3com's bottom line and they might wake up. Until then the solution is Ascend. Ed ----- Original Message ----- Sent: Sunday, January 30, 2000 6:29 PM 3Com has long had interoperability issues. Giving away modems is not good fort he bottom line. You may want to get an ascend rack and have 'troublesome' modems call that box. Paul Farber Farber Technology farber@admin.f-tech.net Ph 570-628-5303 Fax 570-628-5545 On Sun, 30 Jan 2000, Jeff Binkley wrote: > > > > Folks, > > I know this issue has been belabored numerous times but I thought I'd > kick the dead horse one more time. Recently we have had 3 customers > with HSP modems either leave or threaten to leave due to them being able > to connect to other ISPs at higher speeds. As a last resort on two of > them we replaced their modems with 3Com modems and they stayed. Here is > what we saw: > > HSP 3Com > > Cust 1 26400 37333 > Cust 2 29333 41666 > > > In both cases all that was changed is the modem. As expected the > connections got more stable too (i.e. less disconnects). In the case of > the third customer he won't replace his modem but swears he gets 40K > connections with other ISPs. I tend to believe him and we will probably > lose him. In all cases when we looked at the analog stats, all we saw > was a slight rolloff at 3750 but everything else looked good. With the > HSP and other el cheapo' modems now shipping as standard issue on the > low end machines, including the dreaded E-Machines, I suspect this > problem is going to get worse not better unless 3Com can help us here. > I am running the latest Quad code and 2.0.51 DSP code. > > > Jeff > > CMPQwk 1.42-21 9999 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Connect Speed issues
From: Ed <ed@taylors.com>
Date: 2000-01-30 18:41:53

Why make 3com more money though? If they will not fix the issues don't send more money their way by giving customers 3com client modems... which even then don't always fix the problem. We see Ascend connect better with 3com all the time than 3com to 3com. Don't get me wrong I want 3com to be the best however we are losing faith fast... Ed ----- Original Message ----- Sent: Sunday, January 30, 2000 6:37 PM I second the 3Com compatibility issue problem. In rare cases, I've sold (not given) customers with chronic connect problems a USR modem. I'll sell it below cost (about $100) provided that they pay for a year of service in advance. That way, I'm reasonably assured that they're not going to take my modem and bug out anyway. It's cheaper in the long run to give away a few modems than to buy, say, an Ascend box (and it's corresponding PRI or CT1). It can't be part of my existing trunk group, so I would need to populate it with more than just the troublesome customers in order to make it financially worthwhile. Paul Farber wrote: > 3Com has long had interoperability issues. > > Giving away modems is not good fort he bottom line. You may want to get > an ascend rack and have 'troublesome' modems call that box. > > Paul Farber > Farber Technology > farber@admin.f-tech.net > Ph 570-628-5303 > Fax 570-628-5545 > > On Sun, 30 Jan 2000, Jeff Binkley wrote: > > > > > > > > > Folks, > > > > I know this issue has been belabored numerous times but I thought I'd > > kick the dead horse one more time. Recently we have had 3 customers > > with HSP modems either leave or threaten to leave due to them being able > > to connect to other ISPs at higher speeds. As a last resort on two of > > them we replaced their modems with 3Com modems and they stayed. Here is > > what we saw: > > > > HSP 3Com > > > > Cust 1 26400 37333 > > Cust 2 29333 41666 > > > > > > In both cases all that was changed is the modem. As expected the > > connections got more stable too (i.e. less disconnects). In the case of > > the third customer he won't replace his modem but swears he gets 40K > > connections with other ISPs. I tend to believe him and we will probably > > lose him. In all cases when we looked at the analog stats, all we saw > > was a slight rolloff at 3750 but everything else looked good. With the > > HSP and other el cheapo' modems now shipping as standard issue on the > > low end machines, including the dreaded E-Machines, I suspect this > > problem is going to get worse not better unless 3Com can help us here. > > I am running the latest Quad code and 2.0.51 DSP code. > > > > > > Jeff > > > > CMPQwk 1.42-21 9999 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Mark E. Levy, President FSINet, Inc. 800-827-6085 x202 847-753-6832 fax www.fsi.net mark@fsi.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Booting a user
From: Steve Sherwick <hostmaster@minnmicro.com>
Date: 2000-01-30 18:47:02

This is a multi-part message in MIME format. ------=_NextPart_000_000C_01BF6B52.65870120 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Yes!! Thank you!!! Now for a little PERL code to automate it. Thanks again, Steve > > on a hiper it's "disconnect user username" and it's case sensitive. > > To see who's on, it's "list connections". TO see what IP address they have, > do "list ip networks". > > > -----Original Message----- > > From: Steve Sherwick [SMTP:hostmaster@minnmicro.com] > > Sent: Sunday, January 30, 2000 7:35 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Booting a user > > > > Hi there, > > > > I have couple business users running demand dial accounts that are > > problematic to me. > > They don't seem to get their systems programmed to demand dial. Since > > they are running "right to resell" accounts that I'm suppossed to be able > > to > > resell in the evenings I wanna boot them when they get anal. > > > > The knowlege base says I can login and type show session <user> and > > get > > a S number for their session. You're supposed to then do a reset of that s > > number. I'm afraid the generic Neserver instructions don't match this > > Hiper > > monstor I have as it doesn't report an S number at all, It reports the > > slot/port. > > > > Reset doesn't seem to know what to do with it.... > > > > So how does one boot a user on this beast > > > > Thanks, > > > > Steve > > > > Minnetonka Micro - Superior Communications Services Since 1984 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. ------=_NextPart_000_000C_01BF6B52.65870120 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIII+jCCAq0w ggIWoAMCAQICAwHD2jANBgkqhkiG9w0BAQQFADCBlDELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdl c3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UE CxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAx OTk5LjkuMTYwHhcNOTkxMjAzMjM1OTU5WhcNMDAxMjAyMjM1OTU5WjBKMR8wHQYDVQQDExZUaGF3 dGUgRnJlZW1haWwgTWVtYmVyMScwJQYJKoZIhvcNAQkBFhhob3N0bWFzdGVyQG1pbm5taWNyby5j b20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMMvpObXaWvSTbvXhTh6aa84XvvaLsPZ0spX cyPcIS+He3yswL2gP980QNQjG5zsd2nFYd9YQ32dQTG9ZIDJfWikQQUFK4aEcE5Tn2GTTVpRZjnV Tl8hrk5uq+pkSnrartoZBMwtYKY12uMcsIToh/6wbwsKDiI+3XApjPdP5/WFAgMBAAGjVjBUMCMG A1UdEQQcMBqBGGhvc3RtYXN0ZXJAbWlubm1pY3JvLmNvbTAMBgNVHRMBAf8EAjAAMB8GA1UdIwQY MBaAFIir8WCDZlX05FjHRh3AYb0j18OMMA0GCSqGSIb3DQEBBAUAA4GBAEIAP9OIkvQnKs9poSjB gMcfb6lrcFXDvqtvNGwB+PzyqjnT8Z6upZnOIawSyFz98YWRrcwpsfk+0Sn8R0ZerOcp2sBU8JeJ vpnsTA7IE+9yMCzzINbsN/rlJLYK17FGqi7+Unkkf3uHI5806ieOHv7r/QLoB5pTM/W+vh8rbsMQ MIIDFDCCAn2gAwIBAgIBCzANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgT DFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3Vs dGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMb VGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVl bWFpbEB0aGF3dGUuY29tMB4XDTk5MDkxNjE0MDE0MFoXDTAxMDkxNTE0MDE0MFowgZQxCzAJBgNV BAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMQ8wDQYD VQQKEwZUaGF3dGUxHTAbBgNVBAsTFENlcnRpZmljYXRlIFNlcnZpY2VzMSgwJgYDVQQDEx9QZXJz b25hbCBGcmVlbWFpbCBSU0EgMTk5OS45LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCz aVqX1NAWC3q1xV3pIZwjcs0STEv3fs/H+8pyJPRCUqxXleN7YXoXhOf9cjk4lLTq7WWnkgZeveBl 9hm7lHl2TD65aHB1hBz0EXQAvAUsTwkDFzHM9EHUcsamXeKIRLCLLsRN8fDWhT5s85WUeJF+QOmc 0Y0VV47Cc+Uw3kb1TwIDAQABozcwNTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFHJJ wnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GBAGvGWekx+um27LED2N9ycv6RYEjq xlXde/BnjsZhcOdtwqU32J23FyhWBYvdXHVvxpGQxmxmcRPQEHxrkW+G4CE2LcHX6rIJrc8tbcaD Upv7u/6ch538t+l0kuRcl678fqzKDW9yemcsa3P1hvmd9QBu9B0Hzp2egmMp75MJflXeMIIDLTCC ApagAwIBAgIBADANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rl cm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEo MCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3Rl IFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0 aGF3dGUuY29tMB4XDTk2MDEwMTAwMDAwMFoXDTIwMTIzMTIzNTk1OVowgdExCzAJBgNVBAYTAlpB MRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhh d3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24x JDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA1GnX 1LCUZFtx6UfYDFG26nKRsIRefS0Nj3sS34UldSh0OkIsYyeflXtL734Zhx2G6qPduc6WZBrCFG5E rHzmj+hND3EfQDimAKOHePb5lIZererAXnbr2RSjXW56fAylS1V/Bhkpf56aJtVquzgkCGqYx7Ha o5iR/Xnb5VrEHLkCAwEAAaMTMBEwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOBgQDH 7JJ+Tvj1lqVnYiqk8E0RYNBvjWBYYawmu1I1XAjPMPuoSpaKH2JCI4wXD/S6ZJwXrEcp352YXtJs YHFcoqzceePnbgBHH7UNKOgCneSa/RP0ptl8sfjcXyMmCZGAc9AUG95DqYMl8uacLxXK/qarigd1 iwzdUYRr5PjRzneigTGCAgAwggH8AgEBMIGcMIGUMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2Vz dGVybiBDYXBlMRQwEgYDVQQHEwtEdXJiYW52aWxsZTEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQL ExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDE5 OTkuOS4xNgIDAcPaMAkGBSsOAwIaBQCggbowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq hkiG9w0BCQUxDxcNMDAwMTMwMTg0NzAyWjAjBgkqhkiG9w0BCQQxFgQUiKTtn/ICys8ea1sTKo1R hj3fnQcwWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZI hvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0wDQYJKoZIhvcNAQEBBQAE gYATFwN2q3VIpVaKsI3ipV9uSuooDgwSBathWiY/Y6uQmgG0sPvHp8b2+S0ELc7frABNQB5rry30 hYXenf54L7OAv3FhJGu7Ck3jbz/+vN8MbxoVNZAmNB72faNS2bTnZWJd5eS369eDwz0R67X4VQdn s4cDNipEBC+BtXhTkO7UwQAAAAAAAA== ------=_NextPart_000_000C_01BF6B52.65870120--

Subject: (usr-tc) TCM - Hardware Reset Command
From: mft <tsaim@mft.com>
Date: 2000-01-30 20:31:16

Hi All, TCH - quad, digital and analog card w/ Netserver and MMC In the TCM GUI -> Configure -> Action/Command Select "Hardware" and "Hardware Reset" for Command to Excute. Question: If I do "Execute" from the above, will that action delete all the existing Netserver card's setup information. ? My intention is to be able to Remote Reboot the TCH thru the TCM GUI, but not reset the TCH to its manufacture default state. Thanks in adv for any help that you may post here. Sincerely yours Meng tsaim@mft.com

Subject: RE: (usr-tc) Booting a user
From: Stainforth, Matthew <matthews@staff.brunnet.net>
Date: 2000-01-30 20:33:20

on a hiper it's "disconnect user username" and it's case sensitive. To see who's on, it's "list connections". TO see what IP address they have, do "list ip networks". > -----Original Message----- > From: Steve Sherwick [SMTP:hostmaster@minnmicro.com] > Sent: Sunday, January 30, 2000 7:35 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Booting a user > > Hi there, > > I have couple business users running demand dial accounts that are > problematic to me. > They don't seem to get their systems programmed to demand dial. Since > they are running "right to resell" accounts that I'm suppossed to be able > to > resell in the evenings I wanna boot them when they get anal. > > The knowlege base says I can login and type show session <user> and > get > a S number for their session. You're supposed to then do a reset of that s > number. I'm afraid the generic Neserver instructions don't match this > Hiper > monstor I have as it doesn't report an S number at all, It reports the > slot/port. > > Reset doesn't seem to know what to do with it.... > > So how does one boot a user on this beast > > Thanks, > > Steve > > Minnetonka Micro - Superior Communications Services Since 1984 >

Subject: Re: (usr-tc) Booting a user
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-30 22:18:50

Thus spake Steve Sherwick > Yes!! > Thank you!!! Now for a little PERL code to automate it. Might I suggest SNMP for this? Check out CPAN for the SNMP module...it works quite well...and SNMP is *considerably* less error prone for this sort of thing (having been designed to be built into programs as opposed to telnet being designed for human "consumption"). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) default settings for DTR
From: eric@dol.net
Date: 2000-01-30 23:50:25

I am using quad modems 6.1.6 and netservers 3.7.4 In trying to reduce the number of customers being disconnected after connecting I noticed the "DTR Recognition Time" was set to 5 whereas the default setting in the help screen said the default should be 20. What effect does this variable have on the connection and is 20 indeed a better number to use versus 5. BTW when you request the default value, 5 comes up contrary to to help which say 20 is default. thanks eric

Subject: (usr-tc) Padding/Fiber/Proximity to CO
From: eric@dol.net
Date: 2000-01-30 23:55:24

We just moved to a new location with a fiber feed for our PRIs. We are located right across the street from the phone company, Hell Atlantic. We are getting increases in our disconnects and in connection failures but most appear to be generated from customers who are served from the same co as us. I thought I read in postings a while ago that being too close to the co and on fiber that the lines would be too "hot" and would need to be toned down with padding to make then connections better. Is there something that the phone company needs to do? It is very hard trying to find anyone with clues at BA. Would lowering the transmitter level variable from -11 to -13 help or should it be raised to say -10? thanks eric

Subject: Re: (usr-tc) Padding/Fiber/Proximity to CO
From: Aaron Nabil <nabil@spiritone.com>
Date: 2000-01-31 00:49:13

On Sun, 30 Jan 2000 eric@dol.net wrote: > We just moved to a new location with a fiber feed for our PRIs. > We are located right across the street from the phone company, > Hell Atlantic. We are getting increases in our disconnects and > in connection failures but most appear to be generated from customers > who are served from the same co as us. I thought I read in postings > a while ago that being too close to the co and on fiber that the > lines would be too "hot" and would need to be toned down with > padding to make then connections better. No. > Is there something that > the phone company needs to do? It is very hard trying to find anyone > with clues at BA. > > Would lowering the transmitter level variable from -11 to -13 help > or should it be raised to say -10? No and no. -- Aaron Nabil

Subject: RE: (usr-tc) Max for DSP cards on TC
From: System Administrator <sysadmin@nebi.com>
Date: 2000-01-31 09:15:39

I think the reasoning on adding a second harc isn't due so much to performance as it is to reliablility. Imagine the customer feedback if you had 8 T1's not running right due to a hardware failure on a single HiperArc. Two weeks after I got my second HiperArc, the first one died - needless to say I was glad for that second one... __________________________________ Justin Ellison System Administrator InternetUSA sysadmin@nebi.com http://nebi.com 800-603-3502 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Cheryl Johnson Sent: Monday, January 31, 2000 9:00 AM I have a TC chassis currently running seven channelized T1s. I have read the maximum for 1 HARC is 10 DSP. Now, in the past we have tried running 10+ DSP cards with 1 HARC and the chassis did not perform as well as a chassis that not fully loaded. (This is from records, I wasn't actually working with the TC when this happened). Is there any issues I should know about before trying to run a TC chassis with 8+ DSP cards? -Cheryl Johnson SEI Data Network Services, Inc. A Division of SEI Communications

Subject: RE: (usr-tc) Max for DSP cards on TC
From: System Administrator <sysadmin@nebi.com>
Date: 2000-01-31 09:41:35

Das, How did you get dynamic assignment to work? Is it reliable after a certain version of code? When I tried it, I pulled all my hair out; finally I decided I could telnet in and manually switch ownership to get it to work and save time in the long run.... __________________________________ Justin Ellison System Administrator InternetUSA sysadmin@nebi.com http://nebi.com 800-603-3502 > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of D A Substanley > Sent: Monday, January 31, 2000 9:30 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Max for DSP cards on TC > > > Too true. I just had a chassis die over the weekend with one HARC running > 10 DSP cards. Needless to say, the customers were nonplussed. I ordered > a backup HARC the next day. > The other thing nice about running two HARCs in one chassis is being able > to do load balancing and dynamic assignment. (Takeover if one HARC fails) > > das > > the System Administrator (sysadmin@nebi.com) spake: > > > I think the reasoning on adding a second harc isn't due so much to > > performance as it is to reliablility. Imagine the customer > feedback if you > > had 8 T1's not running right due to a hardware failure on a > single HiperArc. > > Two weeks after I got my second HiperArc, the first one died - > needless to > > say I was glad for that second one... > > > > __________________________________ > > Justin Ellison > > System Administrator > > InternetUSA > > sysadmin@nebi.com > > http://nebi.com > > 800-603-3502 > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Cheryl Johnson > > Sent: Monday, January 31, 2000 9:00 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Max for DSP cards on TC > > > > > > I have a TC chassis currently running seven channelized T1s. I > have read the > > maximum for 1 HARC is 10 DSP. Now, in the past we have tried > running 10+ DSP > > cards with 1 HARC and the chassis did not perform as well as a > chassis that > > not fully loaded. (This is from records, I wasn't actually > working with the > > TC when this happened). Is there any issues I should know about before > > trying to run a TC chassis with 8+ DSP cards? > > > > -Cheryl Johnson > > SEI Data Network Services, Inc. > > A Division of SEI Communications > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > ______________________________________________ > Alex Substanley Exodus Communications K.K. > Engineering Department > Das Man TEL: 81-3-5334-1700 > Systems Engineer FAX: 81-3-5334-1711 > ______________________________________________ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Max for DSP cards on TC
From: Cheryl Johnson <netadmin@seidata.com>
Date: 2000-01-31 10:00:04

This is a multi-part message in MIME format. ------=_NextPart_000_0058_01BF6BD1.F262C780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a TC chassis currently running seven channelized T1s. I have read = the maximum for 1 HARC is 10 DSP. Now, in the past we have tried running = 10+ DSP cards with 1 HARC and the chassis did not perform as well as a = chassis that not fully loaded. (This is from records, I wasn't actually = working with the TC when this happened). Is there any issues I should = know about before trying to run a TC chassis with 8+ DSP cards?=20 -Cheryl Johnson SEI Data Network Services, Inc. A Division of SEI Communications ------=_NextPart_000_0058_01BF6BD1.F262C780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Diso-8859-1" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2314.1000" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>I have a TC chassis currently running = seven=20 channelized T1s. I have read the maximum for 1 HARC is 10 DSP. Now, in = the past=20 we have tried running 10+ DSP cards with 1 HARC and the chassis did not = perform=20 as well as a chassis that not fully loaded. (This is from records, I = wasn't=20 actually working with the TC when this happened). Is there any issues I = should=20 know about before trying to run a TC chassis with 8+ DSP cards? = </FONT></DIV> <DIV> </DIV> <DIV><FONT face=3DArial size=3D2>-Cheryl Johnson</FONT></DIV> <DIV><FONT face=3DArial size=3D2>SEI Data Network Services, = Inc.</FONT></DIV> <DIV><FONT face=3DArial size=3D2><EM>A Division of SEI=20 Communications</EM></FONT></DIV></BODY></HTML> ------=_NextPart_000_0058_01BF6BD1.F262C780--

Subject: Re: (usr-tc) Connect Speed issues
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-31 10:02:58

I'm very disappointed. I asked onthis list for feedback concerning the use of Ascend or Lucent as a method to resolve difficult connect issues, and the response was 4:1 against, coming from people who had tried and saw worse results. Now there are those claiming not only will it resolve the problem, but the connections are better accross the board? Why are any of us running 3Com then? Where were these folks two weeks ago? Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Sunday, January 30, 2000 5:41 PM > Why make 3com more money though? If they will not fix the issues don't send > more money their way by giving customers 3com client modems... which even > then don't always fix the problem. We see Ascend connect better with 3com > all the time than 3com to 3com. > > Don't get me wrong I want 3com to be the best however we are losing faith > fast... > > > Ed > > ----- Original Message ----- > From: "Mark E. Levy" <mark@fsi.net> > To: <usr-tc@lists.xmission.com> > Sent: Sunday, January 30, 2000 6:37 PM > Subject: Re: (usr-tc) Connect Speed issues > > > I second the 3Com compatibility issue problem. > > In rare cases, I've sold (not given) customers with chronic connect problems > a > USR modem. I'll sell it below cost (about $100) provided that they pay for > a > year of service in advance. That way, I'm reasonably assured that they're > not > going to take my modem and bug out anyway. > > It's cheaper in the long run to give away a few modems than to buy, say, an > Ascend box (and it's corresponding PRI or CT1). It can't be part of my > existing trunk group, so I would need to populate it with more than just the > troublesome customers in order to make it financially worthwhile. > > Paul Farber wrote: > > > 3Com has long had interoperability issues. > > > > Giving away modems is not good fort he bottom line. You may want to get > > an ascend rack and have 'troublesome' modems call that box. > > > > Paul Farber > > Farber Technology > > farber@admin.f-tech.net > > Ph 570-628-5303 > > Fax 570-628-5545 > > > > On Sun, 30 Jan 2000, Jeff Binkley wrote: > > > > > > > > > > > > > > Folks, > > > > > > I know this issue has been belabored numerous times but I thought I'd > > > kick the dead horse one more time. Recently we have had 3 customers > > > with HSP modems either leave or threaten to leave due to them being able > > > to connect to other ISPs at higher speeds. As a last resort on two of > > > them we replaced their modems with 3Com modems and they stayed. Here is > > > what we saw: > > > > > > HSP 3Com > > > > > > Cust 1 26400 37333 > > > Cust 2 29333 41666 > > > > > > > > > In both cases all that was changed is the modem. As expected the > > > connections got more stable too (i.e. less disconnects). In the case of > > > the third customer he won't replace his modem but swears he gets 40K > > > connections with other ISPs. I tend to believe him and we will probably > > > lose him. In all cases when we looked at the analog stats, all we saw > > > was a slight rolloff at 3750 but everything else looked good. With the > > > HSP and other el cheapo' modems now shipping as standard issue on the > > > low end machines, including the dreaded E-Machines, I suspect this > > > problem is going to get worse not better unless 3Com can help us here. > > > I am running the latest Quad code and 2.0.51 DSP code. > > > > > > > > > Jeff > > > > > > CMPQwk 1.42-21 9999 > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > --------------------------------------------------------------------- > Mark E. Levy, President > FSINet, Inc. > 800-827-6085 x202 > 847-753-6832 fax > www.fsi.net > mark@fsi.net > --------------------------------------------------------------------- > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Booting a user
From: Kevin Benton <s1kevin@tims.net>
Date: 2000-01-31 10:45:11

On Sun, 30 Jan 2000, Steve Sherwick wrote: > I have couple business users running demand dial accounts that are > problematic to me. > They don't seem to get their systems programmed to demand dial. Since > they are running "right to resell" accounts that I'm suppossed to be able to > resell in the evenings I wanna boot them when they get anal. > > The knowlege base says I can login and type show session <user> and get > a S number for their session. You're supposed to then do a reset of that s > number. I'm afraid the generic Neserver instructions don't match this Hiper > monstor I have as it doesn't report an S number at all, It reports the > slot/port. > > Reset doesn't seem to know what to do with it.... > > So how does one boot a user on this beast On the HiPer ARC, disconnect user (username). On the NetServer... show sessions reset <port> Netserver example... (find the session for the user in question and take down the S number on the left such as... S11 doggish dig01-60.i40.sot Netwrk In ESTABLISHED 26 0 S11 is the port number, so reset that port... reset S11 Kevin Benton E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: (usr-tc) ARC amnesia
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-31 13:17:42

Hi, I was paged out of bed last night by an arc card that stopped responding to pings... I went into tcm to have a look, and all was green, but going to the config screen showed that the card had no IP address anymore. Doing a hard reset brought it back, and it's working fine. Has anyone else seen this? Just a fluke, or an issue with the 4.3.32-1 code? Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) ARC amnesia
From: Richard Stuplich <dick@dwave.net>
Date: 2000-01-31 13:49:37

I have seen this. I posted a question about this with no answer (yet). This is the default route taking off on you I would bet. I was dealing with this for a long time and found that the HiperARC doesn't deal with the radius properly (as far as I can tell). This will break the default route: mmanuf Password = "UNIX" User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 207.0.68.214, Framed-Netmask = 255.255.255.255, Framed-Route = "207.0.68.213 207.0.68.214 1" Framed-Compression = Van-Jacobsen-TCP-IP, Idle-Timeout = 0, Framed-MTU = 576 Where this will simply not work at all: mmanuf Password = "UNIX" User-Service-Type = Framed-User, Framed-Protocol = PPP, Framed-Address = 207.0.68.214, Framed-Netmask = 255.255.255.255, Framed-Route = "207.0.68.213/32 207.0.68.214 1" Framed-Compression = Van-Jacobsen-TCP-IP, Idle-Timeout = 0, Framed-MTU = 576 Note: The first and 2nd work fine on Livingston/Lucent devices. In both above examples it does not work (route the 2nd IP address over the dialup). In the first case it breaks the rack be claminig the default route and in the 2nd it only does the promary IP address. Check your radius users file for "Framed-Route" lines. These may be causing this. Note: This is the 3rd rev of the code that still does this. Charles Sprickman wrote: > Hi, > > I was paged out of bed last night by an arc card that stopped responding > to pings... I went into tcm to have a look, and all was green, but going > to the config screen showed that the card had no IP address > anymore. Doing a hard reset brought it back, and it's working fine. Has > anyone else seen this? Just a fluke, or an issue with the 4.3.32-1 code? > > Thanks, > > Charles > > -- > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) ARC amnesia
From: Mark Thornton <mark@corridor.net>
Date: 2000-01-31 13:51:37

I seem to recall that 3Com stated that the routes introduced by raduis are not handled correctly by the source address verification feature. I believe the release note indicated if you turn on source address verification for the entire chasis (we did), you can only route by the ip address and subnet assigned to the port in radius, not additional routes added via radius, or static in the Arc. Could this be the problem? Mark Thornton San Marcos Internet, Inc. 512-393-5300 ----- Original Message ----- Sent: Monday, January 31, 2000 1:57 PM > Thus spake Richard Stuplich > >I have seen this. I posted a question about this with no answer (yet). This > >is the default route taking off on you I would bet. I was dealing with this > >for a long time and found that the HiperARC doesn't deal with the radius > >properly (as far as I can tell). > > >This will break the default route: > > >mmanuf Password = "UNIX" > > User-Service-Type = Framed-User, > > Framed-Protocol = PPP, > > Framed-Address = 207.0.68.214, > > Framed-Netmask = 255.255.255.255, > > Framed-Route = "207.0.68.213 207.0.68.214 1" > ^^^^ > There is no indication of the netmask to use...from RFC2138: > > For IP routes, it SHOULD contain a destination prefix in dotted > quad form optionally followed by a slash and a decimal length > specifier stating how many high order bits of the prefix should be > used. That is followed by a space, a gateway address in dotted > quad form, a space, and one or more metrics separated by spaces. > For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length > specifier may be omitted in which case it should default to 8 bits > for class A prefixes, 16 bits for class B prefixes, and 24 bits > for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". > > This means (assuming the Arc follows this correctly...I haven't checked) > that you're setting the route as "207.0.68.0"(!) as a class C or /24 > route to the user's IP address...not what you want I think. > > >Where this will simply not work at all: > > >mmanuf Password = "UNIX" > > User-Service-Type = Framed-User, > > Framed-Protocol = PPP, > > Framed-Address = 207.0.68.214, > > Framed-Netmask = 255.255.255.255, > > Framed-Route = "207.0.68.213/32 207.0.68.214 1" > > Framed-Compression = Van-Jacobsen-TCP-IP, > > Idle-Timeout = 0, > > Framed-MTU = 576 > > Hrmm...this *should* work...in theory at least...why this isn't working > for you I'm not sure (again...I haven't thoroughly tested the Arc's > routing behavior). > > Keep in mind that some of this may be dependant on how your customer is > using this extra IP... > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Quad modem x2 tx level
From: Greg Coffey <greg@coffey.com>
Date: 2000-01-31 13:59:22

So what db level do you recommend that the quads be set to assuming we're in the US? What about the dsp's? At 08:54 PM 1/31/00 +0000, you wrote: >Hi Dan, > >There are slight differences in setting between modems from different country >settings, as our modems must comply with the different country specification >settings set by each Telco , ATI7 tells you your country code setting. >Country like US/Canada , Japan, Finland, Sweden, UK, Norway, South Africa, >Italy, New Zealand, Czech / Slovkia, Belgium, Denmark, Austria, France, >Germany, >Austria , Ireland , Spain, Portugal and Malaysia all have very slight >difference >in values and limits, what you are seeing is more likely differences in modem >country settings , we also have a country code setting that covers >International >ITU-T spic. > >By the way -10 dB is a stronger signal than -12 dB > >Hope it helps > >Ray W > > > > > >Dan Borlovan <danb@dnttm.ro> on 30/01/2000 09:22:41 > >Please respond to usr-tc@lists.xmission.com > >Sent by: Dan Borlovan <danb@dnttm.ro> > > >To: usr-tc@lists.xmission.com >cc: (Ray Whelan/IE/3Com) >Subject: (usr-tc) Quad modem x2 tx level > > > > > >Hello, > >In order to try improve user x2 connect speeds, I tried to raise the x2 >transmit level on quad modem cards. The problem is I have two quad modem >models (analog/digital vs. digital only) and the first don't let me go >higher than -12dB, while the other ones happily accepted -10dB (this is as >far as I may go from the telco point of view) > >Now the only difference between modems is the analog capability (referring >to the possibility of getting signal from nic or pritdm) and the country >code. > >All modems are setup as digital, taking signal via pritdm from e1 card. > >Is there anything I can do about this one? > >Dan >-- >Dan Borlovan <danb@dnttm.ro> >System Administrator, Network Operation Center >Dynamic Network Technologies - Timisoara, Romania >Telefon: +40-56-204967 FAX: +40-56-220201 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. Thanks, Greg Coffey <gcoffey@vcn.com> Visionary Communications V 307-234-5443 F 307-234-5446 100 N. Center Suite #100, Casper, WY 82601 www.vcn.com

Subject: (usr-tc) which Radius to use?
From: Nate Smith <euro@citipage.com>
Date: 2000-01-31 14:33:39

Hi, I'm trying to move Radius server that we are using now to a new server but I'm having some problems getting the current radius to run on the new server. So I was thinking of just reinstalling but the old network admin is no longer around and I can't figure out what version of radius we're running one the other box. All I get when I try to find out is: ./radiusd -v ./radiusd: RADIUS version 1.16.1 97/12/16 sun I would really like to use a radius that could check multiple logins. If anyone could point me in the right direction in which radius to use (on Sun Solaris 2.6) and where to get it I'd be much appreciative. Thanks, Nate

Subject: Re: (usr-tc) ARC amnesia
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-31 14:57:43

Thus spake Richard Stuplich >I have seen this. I posted a question about this with no answer (yet). This >is the default route taking off on you I would bet. I was dealing with this >for a long time and found that the HiperARC doesn't deal with the radius >properly (as far as I can tell). >This will break the default route: >mmanuf Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 207.0.68.214, > Framed-Netmask = 255.255.255.255, > Framed-Route = "207.0.68.213 207.0.68.214 1" ^^^^ There is no indication of the netmask to use...from RFC2138: For IP routes, it SHOULD contain a destination prefix in dotted quad form optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix should be used. That is followed by a space, a gateway address in dotted quad form, a space, and one or more metrics separated by spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length specifier may be omitted in which case it should default to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". This means (assuming the Arc follows this correctly...I haven't checked) that you're setting the route as "207.0.68.0"(!) as a class C or /24 route to the user's IP address...not what you want I think. >Where this will simply not work at all: >mmanuf Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 207.0.68.214, > Framed-Netmask = 255.255.255.255, > Framed-Route = "207.0.68.213/32 207.0.68.214 1" > Framed-Compression = Van-Jacobsen-TCP-IP, > Idle-Timeout = 0, > Framed-MTU = 576 Hrmm...this *should* work...in theory at least...why this isn't working for you I'm not sure (again...I haven't thoroughly tested the Arc's routing behavior). Keep in mind that some of this may be dependant on how your customer is using this extra IP... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) ARC amnesia
From: Jeff Mcadams <jeffm@iglou.com>
Date: 2000-01-31 15:10:36

Thus spake Mark Thornton >I seem to recall that 3Com stated that the routes introduced by raduis >are not handled correctly by the source address verification feature. I >believe the release note indicated if you turn on source address >verification for the entire chasis (we did), you can only route by the >ip address and subnet assigned to the port in radius, not additional >routes added via radius, or static in the Arc. Could this be the >problem? Certainly could be...need to find out if Richard has source address verification enabled. :) What say ye, Richard? ;) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) ARC amnesia
From: Charles Sprickman <spork@inch.com>
Date: 2000-01-31 15:21:50

I think I have something different. It lost all IP settings, at the least, not just the default route. We also don't have any customers with routed connections... Thanks though, Charles On Mon, 31 Jan 2000, Richard Stuplich wrote: > I have seen this. I posted a question about this with no answer (yet). This > is the default route taking off on you I would bet. I was dealing with this > for a long time and found that the HiperARC doesn't deal with the radius > properly (as far as I can tell). > > This will break the default route: > > mmanuf Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 207.0.68.214, > Framed-Netmask = 255.255.255.255, > Framed-Route = "207.0.68.213 207.0.68.214 1" > Framed-Compression = Van-Jacobsen-TCP-IP, > Idle-Timeout = 0, > Framed-MTU = 576 > > Where this will simply not work at all: > > mmanuf Password = "UNIX" > User-Service-Type = Framed-User, > Framed-Protocol = PPP, > Framed-Address = 207.0.68.214, > Framed-Netmask = 255.255.255.255, > Framed-Route = "207.0.68.213/32 207.0.68.214 1" > Framed-Compression = Van-Jacobsen-TCP-IP, > Idle-Timeout = 0, > Framed-MTU = 576 > > Note: The first and 2nd work fine on Livingston/Lucent devices. In both > above examples it does not work (route the 2nd IP address over the dialup). > In the first case it breaks the rack be claminig the default route and in the > 2nd it only does the promary IP address. > > Check your radius users file for "Framed-Route" lines. These may be causing > this. > > Note: This is the 3rd rev of the code that still does this. > > Charles Sprickman wrote: > > > Hi, > > > > I was paged out of bed last night by an arc card that stopped responding > > to pings... I went into tcm to have a look, and all was green, but going > > to the config screen showed that the card had no IP address > > anymore. Doing a hard reset brought it back, and it's working fine. Has > > anyone else seen this? Just a fluke, or an issue with the 4.3.32-1 code? > > > > Thanks, > > > > Charles > > > > -- > > =-----------------= = > > | Charles Sprickman Internet Channel | > > | INCH System Administration Team (212)243-5200 | > > | spork@inch.com access@inch.com | > > = =----------------= > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) WTB: 2- NMC v90 cards
From: Steve Rivera <sales@wrca.net>
Date: 2000-01-31 15:48:54

Looking to buy today. 2- USR NMC v90/x2 enabled management card sets. (NAC/NIC) Also looking for Netserver PRI cards .................................................... WR Communication Associates Worldwide Provider of Network Hardware Since 1981. I'm always available for your call...732-433-5890 Steve Rivera - sales@wrca.net v-732-833-2111 Office http://www.ISP-NetworkHardware.com or http://www.wrca.net ---ACCESS/TRANSMISSION SPECIALIST--- Cisco, Ascend, Livingston, USR, Microcom, Computone, Kentrox, Adtran...and more

Subject: (usr-tc) 2.0.51
From: Brian Becker <brian@semo.net>
Date: 2000-01-31 16:28:20

We are considering upgrading our dsp's from 2.0.81 to 2.0.51. Our Arcs are running 4.1.59. I saw someone posting about 28.8 connects being a problem with 2.0.51. Anyone care to give me an update? We hate the hung modem issue, but at least we are now prepared/able to handle it. I'm wondering how big the scope of the problem is with regards to 28.8k modems...or any other problem you might have run into. Thanks, Brian Brian Becker President, Poplar Bluff Internet http://www.semo.net TotallyFabricated.com Software http://www.TotallyFabricated.com Home of JerusalemPerspective.com http://www.JerusalemPerspective.com Personal Page http://Tonionio.com / http://BenjaminBecker.com

Subject: Re: (usr-tc) which Radius to use?
From: Michael Jon Vigodda <vigodda@lks.net>
Date: 2000-01-31 17:00:16

Sorry for not responing sooner, Dave, but we're going to have to give a pass on these units. If you still have in 30 days, we may be in a position to purchase then, but for the moment, it's just a little too soon for us. Thanks & Regards, Michael Jon Vigodda ----- Original Message ----- Sent: Monday, January 31, 2000 1:33 PM > > Hi, I'm trying to move Radius server that we are using now to a new server > but I'm having some problems getting the current radius to run on the new > server. So I was thinking of just reinstalling but the old network admin > is no longer around and I can't figure out what version of radius we're > running one the other box. All I get when I try to find out is: > > ./radiusd -v > ./radiusd: RADIUS version 1.16.1 97/12/16 > sun > > I would really like to use a radius that could check multiple logins. If > anyone could point me in the right direction in which radius to use (on Sun > Solaris 2.6) and where to get it I'd be much appreciative. > > > Thanks, > > Nate > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) 2.0.51
From: System Administrator <sysadmin@nebi.com>
Date: 2000-01-31 17:02:50

I upgraded all of my local POP's DSP's last week, haven't heard any customer complaints thus far... __________________________________ Justin Ellison System Administrator InternetUSA sysadmin@nebi.com http://nebi.com 800-603-3502 > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian Becker > Sent: Monday, January 31, 2000 4:28 PM > To: Usr-Tc ListServe (E-mail) > Subject: (usr-tc) 2.0.51 > > > We are considering upgrading our dsp's from 2.0.81 to 2.0.51. Our Arcs are > running 4.1.59. > > I saw someone posting about 28.8 connects being a problem with 2.0.51. > Anyone care to give me an update? We hate the hung modem issue, > but at least > we are now prepared/able to handle it. I'm wondering how big the scope of > the problem is with regards to 28.8k modems...or any other > problem you might > have run into. > > Thanks, > Brian > > Brian Becker > President, Poplar Bluff Internet > http://www.semo.net > TotallyFabricated.com Software > http://www.TotallyFabricated.com > Home of JerusalemPerspective.com > http://www.JerusalemPerspective.com > Personal Page > http://Tonionio.com / http://BenjaminBecker.com > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) ARC amnesia
From: Richard Stuplich <dick@dwave.net>
Date: 2000-01-31 19:51:51

HiPer>> show ip sec set IP SECURITY SETTINGS Drop All Fragoffset1: ENABLED Drop TCP Fragoffset1: ENABLED Disallow All Header Options: DISABLED Disallow Source Route Options: DISABLED Do I need to change enything here. We try to change as little as possible on these units. Safer that way we have found. Jeff Mcadams wrote: > Thus spake Mark Thornton > >I seem to recall that 3Com stated that the routes introduced by raduis > >are not handled correctly by the source address verification feature. I > >believe the release note indicated if you turn on source address > >verification for the entire chasis (we did), you can only route by the > >ip address and subnet assigned to the port in radius, not additional > >routes added via radius, or static in the Arc. Could this be the > >problem? > > Certainly could be...need to find out if Richard has source address > verification enabled. :) What say ye, Richard? ;) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Quad modem x2 tx level
From: Ray Whelan <ray_whelan@eur.3com.com>
Date: 2000-01-31 20:54:26

Hi Dan, There are slight differences in setting between modems from different country settings, as our modems must comply with the different country specification settings set by each Telco , ATI7 tells you your country code setting. Country like US/Canada , Japan, Finland, Sweden, UK, Norway, South Africa, Italy, New Zealand, Czech / Slovkia, Belgium, Denmark, Austria, France, Germany, Austria , Ireland , Spain, Portugal and Malaysia all have very slight difference in values and limits, what you are seeing is more likely differences in modem country settings , we also have a country code setting that covers International ITU-T spic. By the way -10 dB is a stronger signal than -12 dB Hope it helps Ray W Dan Borlovan <danb@dnttm.ro> on 30/01/2000 09:22:41 Please respond to usr-tc@lists.xmission.com Sent by: Dan Borlovan <danb@dnttm.ro> cc: (Ray Whelan/IE/3Com) Hello, In order to try improve user x2 connect speeds, I tried to raise the x2 transmit level on quad modem cards. The problem is I have two quad modem models (analog/digital vs. digital only) and the first don't let me go higher than -12dB, while the other ones happily accepted -10dB (this is as far as I may go from the telco point of view) Now the only difference between modems is the analog capability (referring to the possibility of getting signal from nic or pritdm) and the country code. All modems are setup as digital, taking signal via pritdm from e1 card. Is there anything I can do about this one? Dan -- Dan Borlovan <danb@dnttm.ro> System Administrator, Network Operation Center Dynamic Network Technologies - Timisoara, Romania Telefon: +40-56-204967 FAX: +40-56-220201 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) which Radius to use?
From: Mike Andrews <mandrews@bit0.com>
Date: 2000-01-31 21:51:53

You have Livingston Radius 1.16, which is really really old and has security problems. Get Cistron Radius from http://www.freeradius.org and you'll be fine. It can check multiple logins too. (We don't use that feature, we have something else that does it, but I hear good things...) Mike Andrews (MA12) * mandrews@dcr.net * http://www.bit0.com/ VP, sysadmin, & network guy, Digital Crescent Inc, Frankfort KY Internet services for Frankfort, Lawrenceburg, Owenton, Shelbyville "Don't sweat the petty things, and don't pet the sweaty things." On Mon, 31 Jan 2000, Nate Smith wrote: > > Hi, I'm trying to move Radius server that we are using now to a new server > but I'm having some problems getting the current radius to run on the new > server. So I was thinking of just reinstalling but the old network admin > is no longer around and I can't figure out what version of radius we're > running one the other box. All I get when I try to find out is: > > ./radiusd -v > ./radiusd: RADIUS version 1.16.1 97/12/16 > sun > > I would really like to use a radius that could check multiple logins. If > anyone could point me in the right direction in which radius to use (on Sun > Solaris 2.6) and where to get it I'd be much appreciative. > > > Thanks, > > Nate > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Quirky CHAP on 2.0.51
From: Scot Desort <scot@njaccess.net>
Date: 2000-01-31 22:11:46

Have a few DSP's upgraded to 2.0.51. Just noticed a quirk in CHAP authentication. After LCP is done, and PPP authentication begins, the auth packets do not make it to the Radius server. I have made several test calls, logging both radius info on my Vircom radius server, and PPP packets on the TC. The radius server does not receive any incoming packet. The TC shows the following: Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM bc 93 87 df PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 CALLBACK 06 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REJ CALLBACK 06 Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REJ PROTO_COMP AC_COMP MPP_MRRU 05 ea Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM bc 93 87 df Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_NAK AUTH_TYPE c2 23 81 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df Outgoing PPP Data on interface: slot:4/mod:17 CHAP CHALLENGE 10 a9 8a 81 83 ad dc b9 06 13 f2 bc ad 63 d4 76 28 48 69 50 65 72 Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 8b cf 11 8b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REJ PROTO_COMP AC_COMP MPP_MRRU 05 ea Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 8b cf 11 8b Outgoing PPP Data on interface: slot:4/mod:17 CHAP CHALLENGE 10 50 b8 b1 f5 4d a4 9a d0 e1 c9 af ef 3e 1d 1c 82 48 69 50 65 72 Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_NAK AUTH_TYPE c2 23 05 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM 8b cf 11 8b And the process continues until I cancel the connection attempt. It *will* however sometimes authenticate just fine using CHAP. It always authenticates using PAP. This test call is ISDN. I am about to try the same series of tests using analog dialup. Anyone else seen this??? -- Scot

Subject: Re: (usr-tc) Max for DSP cards on TC
From: D A Substanley <das@gol.com>
Date: 2000-02-01 00:30:27

Too true. I just had a chassis die over the weekend with one HARC running 10 DSP cards. Needless to say, the customers were nonplussed. I ordered a backup HARC the next day. The other thing nice about running two HARCs in one chassis is being able to do load balancing and dynamic assignment. (Takeover if one HARC fails) das the System Administrator (sysadmin@nebi.com) spake: > I think the reasoning on adding a second harc isn't due so much to > performance as it is to reliablility. Imagine the customer feedback if you > had 8 T1's not running right due to a hardware failure on a single HiperArc. > Two weeks after I got my second HiperArc, the first one died - needless to > say I was glad for that second one... > > __________________________________ > Justin Ellison > System Administrator > InternetUSA > sysadmin@nebi.com > http://nebi.com > 800-603-3502 > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Cheryl Johnson > Sent: Monday, January 31, 2000 9:00 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Max for DSP cards on TC > > > I have a TC chassis currently running seven channelized T1s. I have read the > maximum for 1 HARC is 10 DSP. Now, in the past we have tried running 10+ DSP > cards with 1 HARC and the chassis did not perform as well as a chassis that > not fully loaded. (This is from records, I wasn't actually working with the > TC when this happened). Is there any issues I should know about before > trying to run a TC chassis with 8+ DSP cards? > > -Cheryl Johnson > SEI Data Network Services, Inc. > A Division of SEI Communications > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) Max for DSP cards on TC
From: D A Substanley <das@gol.com>
Date: 2000-02-01 00:46:44

To be honest, I've been too chicken to bring the one harc down to test it. I have it in a remote pop, and it hasn't crashed since I set it up. But I've been given no reason to suspect that it doesn't work. What have you experienced? Have there been other bad experiences with this feature? das System Administrator (sysadmin@nebi.com) spake: > Das, > > How did you get dynamic assignment to work? Is it reliable after a certain > version of code? When I tried it, I pulled all my hair out; finally I > decided I could telnet in and manually switch ownership to get it to work > and save time in the long run.... > > __________________________________ > Justin Ellison > System Administrator > InternetUSA > sysadmin@nebi.com > http://nebi.com > 800-603-3502 > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of D A Substanley > > Sent: Monday, January 31, 2000 9:30 AM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Max for DSP cards on TC > > > > > > Too true. I just had a chassis die over the weekend with one HARC running > > 10 DSP cards. Needless to say, the customers were nonplussed. I ordered > > a backup HARC the next day. > > The other thing nice about running two HARCs in one chassis is being able > > to do load balancing and dynamic assignment. (Takeover if one HARC fails) > > > > das > > > > the System Administrator (sysadmin@nebi.com) spake: > > > > > I think the reasoning on adding a second harc isn't due so much to > > > performance as it is to reliablility. Imagine the customer > > feedback if you > > > had 8 T1's not running right due to a hardware failure on a > > single HiperArc. > > > Two weeks after I got my second HiperArc, the first one died - > > needless to > > > say I was glad for that second one... > > > > > > __________________________________ > > > Justin Ellison > > > System Administrator > > > InternetUSA > > > sysadmin@nebi.com > > > http://nebi.com > > > 800-603-3502 > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Cheryl Johnson > > > Sent: Monday, January 31, 2000 9:00 AM > > > To: usr-tc@lists.xmission.com > > > Subject: (usr-tc) Max for DSP cards on TC > > > > > > > > > I have a TC chassis currently running seven channelized T1s. I > > have read the > > > maximum for 1 HARC is 10 DSP. Now, in the past we have tried > > running 10+ DSP > > > cards with 1 HARC and the chassis did not perform as well as a > > chassis that > > > not fully loaded. (This is from records, I wasn't actually > > working with the > > > TC when this happened). Is there any issues I should know about before > > > trying to run a TC chassis with 8+ DSP cards? > > > > > > -Cheryl Johnson > > > SEI Data Network Services, Inc. > > > A Division of SEI Communications > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > -- > > ______________________________________________ > > Alex Substanley Exodus Communications K.K. > > Engineering Department > > Das Man TEL: 81-3-5334-1700 > > Systems Engineer FAX: 81-3-5334-1711 > > ______________________________________________ > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: Re: (usr-tc) which Radius to use?
From: Brian Gordon <administrator@westelcom.com>
Date: 2000-02-01 01:16:00

I am looking at Steel Belted Radius by Funk for NT, anyone else out there using this. What you think? It seems feature rich. Brian ----- Original Message ----- Sent: Monday, January 31, 2000 10:54 PM Nate We're using Merit RADIUS on Solaris 2.6. Depending on what options you need you can either get it for free, or pay a donation to Merit networks. It supports limiting multiple logins etc. www.merit.net We're quite happy with the features and reliability. Campbell >>> euro@citipage.com 02/01/00 08:33 >>> Hi, I'm trying to move Radius server that we are using now to a new server but I'm having some problems getting the current radius to run on the new server. So I was thinking of just reinstalling but the old network admin is no longer around and I can't figure out what version of radius we're running one the other box. All I get when I try to find out is: ./radiusd -v ./radiusd: RADIUS version 1.16.1 97/12/16 sun I would really like to use a radius that could check multiple logins. If anyone could point me in the right direction in which radius to use (on Sun Solaris 2.6) and where to get it I'd be much appreciative. Thanks, Nate - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) ARC amnesia
From: D A Substanley <das@gol.com>
Date: 2000-02-01 10:12:36

Yes, I had one the other day that was sporadically allowing users to connect then not. I tried logging in, and it had forgotten the password. Hardware reset, thankfully, brought it out of its fugue. das Charles Sprickman (spork@inch.com) spake: > Hi, > > I was paged out of bed last night by an arc card that stopped responding > to pings... I went into tcm to have a look, and all was green, but going > to the config screen showed that the card had no IP address > anymore. Doing a hard reset brought it back, and it's working fine. Has > anyone else seen this? Just a fluke, or an issue with the 4.3.32-1 code? > > Thanks, > > Charles > > -- > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ______________________________________________ Alex Substanley Exodus Communications K.K. Engineering Department Das Man TEL: 81-3-5334-1700 Systems Engineer FAX: 81-3-5334-1711 ______________________________________________

Subject: RE: (usr-tc) Quirky CHAP on 2.0.51
From: Ian Quinn <ianq@interconnect.co.nz>
Date: 2000-02-01 16:50:35

It doesn't look like a CHAP problem - more a LCP negotiation problem. After the HARC sends it's CHAP Challenge, it receives another LCP Request from the remote end, effectively restarting the LCP phase. It's not obvious what's wrong from this end since during the initial set of LCP negotion, there seems to be an LCP Request-Acknowledge eventually negotiated in each direction so both ends should think the LCP state is open and be happy to move on to authenticate. 1. LCP Negotiated Remote Client -> HARC Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 2. LCP Negotiated HARC -> Remote Client Outgoing PPP Data on interface: slot:4/mod:17 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df Incoming PPP Data on interface: slot:4/mod:17 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c2 23 05 MAGIC_NUM bc 93 87 df I'd get a trace from the remote device and see if it receives the outgoing LCP Acknowledge from the HARC. Maybe it's corrupt, lost or just late for some reason forcing the remote client to resend it's LCP config request. The remote end definately seems to be pushing the HARC back into negotiating LCP after the HARC thinks it's open and has moved on to authenticate. Also not sure what AUTH_TYPE c2 23 81 is? c2 23 05 is CHAP, c2 23 80 is MS-CHAP (I think)... Hope this helps (and that I didn't misread this!). Regards Ian > -----Original Message----- > From: Scot Desort [SMTP:scot@njaccess.net] > Sent: Tuesday, February 01, 2000 4:12 PM > To: usr list > Subject: (usr-tc) Quirky CHAP on 2.0.51 > > Have a few DSP's upgraded to 2.0.51. Just noticed a quirk in CHAP > authentication. After LCP is done, and PPP authentication begins, the auth > packets do not make it to the Radius server. I have made several test > calls, > logging both radius info on my Vircom radius server, and PPP packets on > the > TC. The radius server does not receive any incoming packet. The TC shows > the > following: > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM bc 93 87 df > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 > CALLBACK 06 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REJ CALLBACK 06 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REJ PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM bc 93 87 df > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_NAK AUTH_TYPE c2 23 81 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c2 23 05 > MAGIC_NUM bc 93 87 df > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c2 23 05 > MAGIC_NUM bc 93 87 df > > Outgoing PPP Data on interface: slot:4/mod:17 > CHAP CHALLENGE 10 a9 8a 81 83 ad dc b9 > 06 13 f2 bc ad 63 d4 76 > 28 48 69 50 65 72 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 8b cf 11 8b > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REJ PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 8b cf 11 8b > > Outgoing PPP Data on interface: slot:4/mod:17 > CHAP CHALLENGE 10 50 b8 b1 f5 4d a4 9a > d0 e1 c9 af ef 3e 1d 1c > 82 48 69 50 65 72 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MAGIC_NUM 0c 2c 41 f2 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_ACK MAGIC_NUM 0c 2c 41 f2 > > Incoming PPP Data on interface: slot:4/mod:17 > LCP CFG_NAK AUTH_TYPE c2 23 05 > > Outgoing PPP Data on interface: slot:4/mod:17 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c2 23 05 > MAGIC_NUM 8b cf 11 8b > > > And the process continues until I cancel the connection attempt. > > It *will* however sometimes authenticate just fine using CHAP. It always > authenticates using PAP. This test call is ISDN. I am about to try the > same > series of tests using analog dialup. > > Anyone else seen this??? > > -- > Scot > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) which Radius to use?
From: Campbell Simpson <campbell.simpson@telecom.co.nz>
Date: 2000-02-01 16:54:42

Nate We're using Merit RADIUS on Solaris 2.6. Depending on what options you = need you can either get it for free, or pay a donation to Merit networks. = It supports limiting multiple logins etc. www.merit.net We're quite happy with the features and reliability. Campbell=20 >>> euro@citipage.com 02/01/00 08:33 >>> Hi, I'm trying to move Radius server that we are using now to a new server but I'm having some problems getting the current radius to run on the new server. So I was thinking of just reinstalling but the old network admin is no longer around and I can't figure out what version of radius we're running one the other box. All I get when I try to find out is: ./radiusd -v ./radiusd: RADIUS version 1.16.1 97/12/16 sun I would really like to use a radius that could check multiple logins. If anyone could point me in the right direction in which radius to use (on = Sun Solaris 2.6) and where to get it I'd be much appreciative. Thanks, Nate - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) radius attribute 0x988b (39051)
From: Jared Mauch <jared@puck.nether.net>
Date: 2000-12-23 14:03:02

Does someone know what this attribute is? Name, and type (integer, string, etc..) would be very helpful. Also, does USR have a difinitive radius attribute dictonary that they distribute? I can't find one on totalservice or lying around either. Thanks. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE |

Subject: Re: (usr-tc) PCSDL, is there some sort of trick to this?
From: Tom Collins <tom_collins@mw.3com.com>
Date: 2000-12-24 23:52:33

Are you issuing this command within the same directory as the .nac and .sdl files? the application pcsdl and the .nac & .sdl files need to be in the same folder. Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> on 12/21/99 10:21:34 AM Please respond to usr-tc@lists.xmission.com Sent by: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> cc: usr-tc@lists.xmission.com (Tom Collins/MW/US/3Com) On Wed, 22 Dec 1999, das wrote: > I've read all of the documentation. I've now got some remote NMCs that > have become unreachable via TCM. I figure that I need to go there and > reflash them via PCSDL. I've never had to do this before, so I did my > homework. This is what I'm typing: > > pcsdl -p1 -r9600 -vsd5.4.1 -vna5.2.2 -nsdnm -nnanm > > This should be all you need correct? It keeps giving me the following > error message: > > Error: No such file or directory. This error refers to the sdl and the nac file. What it says here is that you do not have a either a sdl file named nm050401.sdl or you do not have a nm05050202.nac file. Check the file names krish > > So, I tried using the -d flag to specify C:\usr_sdl . But, that didn't > seem to have any affect. > > Any ideas? I don't want to have to go all the way out there tomorrow > without any way to bring these cards up. > > TIA, > > das > > -- > ____________________________________________ > Alex Substanley Global OnLine Japan > Engineering Department > Das Man TEL: 81-3-5334-1700 > Systems Engineer FAX: 81-3-5334-1711 > The Highest Quality Service, Bar None > ____________________________________________ > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Messages