March 1999

Thus spake Ricky Beam >>Basically, because 3Com refuses to port and support HiPerOS on the >>NETServer hardware, our only choice is to buy HiPer Arc cards to replace >>all of our NETServer cards. This amounts to 3Com screwing us over >>because we have been customers of theirs long enough to have a large >>number of NETServer cards. >You cannot blame a company for dropping support for clearly out dated >hardware. The Netservers are 10 year old technology -- 486s. Why would >any company devote large amounts of resources to keeping old shit out there >when they _really_ don't want that junk to still be out there? I can still buy Cisco 2500's, that's older hardware technology than the NETServers by a generation or two. The hardware technology isn't the problem. If I were demanding VoIP on quads and NETServer's, then you'd have a point, but 46 ports of PPP or rlogin? There's no reason to discontinue support of this hardware for that functionality. I'm certainly willing to forgo VoIP and other more advanced technologies if I stay on quads and NETServer's...that's only reasonable. >Did you go around screaming when Microsoft dropped support for several other >platforms? I don't pay a great deal of attention to what MSFT does, but to my knowledge, they didn't drop support of a product that they sold as recently as 6 months ago. >>We were told (I *believe* by Tom, though I don't remember this >>explicitely) that 3Com's idea is that any and all upgrade deals should >>be "revenue positive." Meaning that 3Com isn't willing to upgrade our >>NETServer's to HiPer Arcs because they won't make any money on it. >>Again, this goes back to the Bait and Switch argument I made above. >No, it goes back to a business that has to make money. What you are arguing >for is a free upgrade path. Wrong. What I'm arguing for is a fix for MPIP brokenness. From what it seems, the only path that 3Com has left for that fix is a hardware upgrade, but that's their choice, not mine. If they got me a fix for MPIP on the NETServers, I'd be a happy camper, but that's not gonna happen. >That's like going to Dell and arguing that you >want a free upgrade from a PPro to a PII machine. If the PPro couldn't be made to perform as advertised and the "fix" for that was to get a PII machine, then yeah, I'd think that's appropriate. If the "fix" were able to be accomplished via a software upgrade, more power to them. >3Com is dropping support >for the netserver - period. As of 2/26/1999, 3Com no longer services >netservers. OK, that's a stupid decision, but that's their decision to make. My point being, they sold me a product that doesn't perform as they promised it would (MPIP is broken), and then they're trying to charge me again for the fix (whatever that fix may be). That's Bait and Switch, and that's illegal, period. >Companies move forward with new technologies. They cannot continue to support >the old stuff for ever I'd hope they could support it for 6 months though. >-- if they try to then they end up with MacOS... And >you cannot expect them to out-right give you the new wiz-bang hardware for >free. Hey, if that's what they're saying the "fix" for their brokenness is, then you're darn right I can expect them to do that. >[deals...] >In this respect, I think 3Com is trying to be reasonable here. Do the math. >After all is said and done, the cost of the new ARC is around 2k$ depending >on your particular discount with 3Com or dealer. We could have upgraded >our entire dialup network for somewhere around 100k$. That's an order >of magnitude less than it will cost to replace it with someone else's >hardware. And when you add in personel and training... switching your >dialup hardware is major expense and pain in the ass. (We've done it once >and about to do it again.) Trying, but failing miserably. I don't care how reasonable the cost of these bundles are, its still Bait and Switch, or paying for a fix for something that should have worked in the first place. I agree that switching to new dial-up hardware is expensive, but we are considering it, as are you. Why are you considering it? Because 3Com has treated you like dirt? Because they haven't delivered what they promised? That's all I'm saying. >>Again, we're having to pay more money because 3Com is unwilling to make >>the situation right when they failed to deliver the capabilities they >>promised. >And what did they fail to deliver? MPIP works. It just doesn't work >very well. No, it doesn't work. Having to reboot a system every 3 hours to provide even *minimal* functionality is not what I call working. Yeah, in my first response to Phil I said it works ok, sort of (or actually affirmed his statement to that effect), but for real use in a real dial-up network, with more than about 300 ports...its not reliable enough to really sell it. >> Customers such as us that have >>had USR/3Com gear for years have to pay more money to keep our equipment >>up to date and to work around bugs that 3Com was unable to fix, and >>their poor planning in not having an upgrade path available for the >>older equipment. >What you appear to be expecting is a free migration path... >eg. 286 -> 386 -> 486 -> Pentium -> PPro -> PII -> PIII No, again, I'm expecting a fix for my bug that I've had a ticket open on since April. If they can do that without me having to get new hardware...*wonderful*. That would even be better than free replacement, because even with free replacement, there is still cost involved in my time and energy of going to our POPs and doing that actual work to do the replacement. Or if this equipment was bought even as much as 2 years ago, I could even understand that. We bought NETServer's (already in the channel I believe) as late as 3 months ago though. >It costs money to support stuff. I assume you charge your customers. >Do you give your customers a free technological upgrade path? Well...where its reasonable to do so, yeah, we do. We charge the same for ISDN that we do for modem dialup. There are other costs involved to the customer, but we don't charge any differently. >> We have a large number of NETServer cards, and the >>only three options that we have are to throw that investment into the >>trash, try to sell these things used which throws most of our investment >>into the trash, or send them back to 3Com for a $3200 rebate on new >>purchases, which still throws a significant investment into the trash. >No, it's an investment to keep the existing investment worth something. >The money sunk into the netserver hardware years ago is gradually dwindling >to nothing. It's the same with your aging desktop computers; how much did >you pay for a 486dx2-66 "power house" a few years ago and what's it worth >today? I'm still using my 486-33 at home. The software works, doesn't have any killer bugs (won't say there aren't any, but none that affect me), and does the job I need of it. If the NETServers were the same, you would hear no complaints from me. As it is though, they're broken, and seeing that they were being sold by 3Com as recently as 6 months ago, I don't think its unreasonable to expect better support of them in some way. Like I said...I don't really care *how* its done...just as long as it *is* done. >Don't whine about your investment becoming worthless. It's not worthless >to you simply because of the amount of time and money spent in building it >and the same that it will take to replace it. Even if you completely >replaced all of the 3Com hardware, the same thing will happen on down the >road. >Would Cisco upgrade a 2500 series router to a 2600 series router for free? Is Cisco still releasing new software and fixing bugs in 2500 routers? Yes...for free even, they're still fully supported. If Cisco sold me a 2500, and I found a killer bug in it 6 months later, then yes, I would expect *something* to be done...whether thats a software upgrade, or if Cisco was unable to do that, a hardware swap-out to something that did work (doesn't even have to be newer as far as I'm concerned, just so long as it does what I need) I don't really care, but *something* should be done. >The answer is "hell no". It's next to impossible to get any measurable >discount out of Cisco -- talk about revenue anal people... We get a *heck* of a lot bigger discount for our Cisco equipment than we do for our 3Com equipment. >> it may mean swapping >>out NETServers for HiPer Arcs at some smaller ratio and throwing in some >>DSP's to make up for the port density problems. >True, you don't need a hiperARC to drive 48 modems. I'd expect some sort >of deal to increase the density of ports on the hiperARC. But, in some >places, DSP hardware makes no sense. Yeah, like I said...if that's cheaper/easier for them to do...I don't have any problem with that. If we have to pay for the upgrades, the cheapest route for us is the buy 1 Arc, and 1 DSP, trade in a NETServer bundle. But, like I said earlier, I really don't think I should have to pay for a fix for MPIP here. >> I really don't care >>*how* 3Com does this, all I know is that I need to get HiPer Arcs on my >>network in place of NETServers, and I really don't think I should have >>to pay to do it since the only reason I have to do this is because 3Com >>couldn't deliver on their promise. >Apparently you *do* care... No, I don't care *how* its done...just that it *is* done. >>3Com needs to start treating their loyal customers like the assets that >>we are, rather than just prospective future customers. If someone asks >I would just like to interject a distinction between USR and 3Com... >Most (if not all) of the current problems can be traced back to everything >being run by 3Com. It takes time for the dust to settle. And it takes time >for USR customers to get used to dealing with 3Com instead of USR. OK, regardless of where the problem traces back to...I'm having to deal with 3Com now. >>me what I think about 3Com, I tell them that we use TC's, then I tell >>them that if they can at all avoid it, not to make the same mistake we >>did. I tell them that 3Com is an absolute *nightmare* to work with >>corporately because they don't care about their current customers at >>all. All 3Com seems to care about is where their next source of revenue >>is going to be. >Well, 3Com corp. aside, USR makes some damn good dialup hardware. Lucent >is about the only ones I know of that rival the USR toys. (and cisco ain't >even on the map.) Yup, I generally tell people that...but then I tell them that if I had to make the choice over again, I'd buy Cisco. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Once upon a time Ricky Beam shaped the electrons to say... >That magic DSP hardware is Telebit MicaModem hardware. Telebit still sells >the "micablazer" line of products that use the same DSP technology. Pick up Telebit is dead. ITK absorbed them and the old products were on the way out, not Digi bought up ITK and there is basically nothing left. The NetBlazer name is being used for NT based software and hardware solutions. The MICABlazer appears to be dead. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Bob Purdon was heard to say: >> Hmm, 8 Edge Pro's (running linux or freebsd) in one 5U rack... > >Been there too... When I priced the Edgeserver (not the Pro), they quoted >me around $20k for the base model. No way! So, I didn't say it was cheap... just dense. We just need to find out who's selling the cards to 3Com :-) (Or have them built yourself -- the midplane connector is documented in the ARC docs.) --Ricky

Once upon a time Ricky Beam shaped the electrons to say... >_damn_ good NAS -- who else has ever been able to get a 386dx40 to run >48 115.2k serial ports without a problem? Well, the PM-2eR-30 only has a 386-33, early revs were 386-25. :-) That's the most ports on an async PM. The PM-3 is a 486-66. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Allen Marsalis was heard to say: >>I'm gonna start pushing them for VoIP on the ARC next. :-) > >that would be cool.. we have had dozens of PPC's clocking wasted cycles >for a year now.. perhaps 3COM could get with distributed.net and crack >RSA keys in the mean time.... :) Heh, funny that you should mention that I'm one of the "coders" for d.net. Of course, you will notice alot of those clocks being used by OSPF... it's taking about 4% of the CPU here, but that's alpha code that has a few problems 3Com is clearing up. --Ricky

MegaZone was heard to say: >Once upon a time Ricky Beam shaped the electrons to say... >>That magic DSP hardware is Telebit MicaModem hardware. Telebit still sells >>the "micablazer" line of products that use the same DSP technology. Pick up > >Telebit is dead. ITK absorbed them and the old products were on the way >out, not Digi bought up ITK and there is basically nothing left. The >NetBlazer name is being used for NT based software and hardware solutions. >The MICABlazer appears to be dead. Telebit/ITK, whatever :-) I just noticed the Digi thing. I guess the netblazer fire has gone out of the universe. And the netblazer was a _damn_ good NAS -- who else has ever been able to get a 386dx40 to run 48 115.2k serial ports without a problem? --Ricky

> > Correct... the AS51 card is a 2511 on a card. > > Which brings to mind an interesting use for a TCH... 16 2511's in a rack :-) > (Or course, you could do the same thing with the Edge server cards...) > > Hmm, 8 Edge Pro's (running linux or freebsd) in one 5U rack... > > --Ricky Or.... One could be really ambitious and port Linux to the HiperArc. Then you could have 16 603e in 5U of space. (IMO, HiperARC should make a decent server: 200mhz 603e, 8mb of flash (local disk) 128MB ram, Dual Fast-Ethernet Serial Console) What more do you really need? -Luke

On Sun, 28 Feb 1999, Mike Andrews wrote: > Great, just what I needed. Now why would a Quad modem get a DSP Interrupt > Timeout when trying to answer a call... Where are you see thins? Is this on a ati6 screen on the modem? or something in the syslog? krish > > > Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me > getting beaten by the police, put down the video camera and come help me!" >

We have a quad modem (fw ver 5.10) that will only connect at 2400 BPS. Whenever I check the Default DTE data rate setting in TCM, it is set to 2400 BPS. I can reset it to something else (e.g., 38 KBPS), but after any modem connects to it, it is set back to 2400. I tried savign config to NVRAM and restoring, restoring from Defaults, but no matter what I do the first modem that hits it connects at 2400 BPS and the Default DTE date rate is reset back to 2400 BPS. Does anyone have any suggections, or is this a bad port on the quad? Thanks, Jim

% The AS5100 card is a 2511 on a card, right? I've been toying around with % the idea of finding a used one just to use in place of a 2511 for a remote % pop (not actually run modems off it, but hook the async ports to the NMC, % DSP, and Dual PRI serial ports...) How much flash/dram do they have? If % it's got enough flash and it's really 2500 based, you could still get IOS % 11.3 or 12.0 on it... yeah, 16mb ram, 16mb flash. you can run 12.0 on it. great stuff, 1 sync serial, console, aux, and ethernet per card. works better than anything i've found. give 'em a shot, once you have a good configuration it's wonderful. |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (800)-209-0223 emerg |o|

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of MegaZone |Sent: Sunday, February 28, 1999 5:02 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Preferences in RADIUS servers | | |Once upon a time Jeff Mcadams shaped the electrons to say... |>Oh man...I'm not even sure what to say about this... |>BTW, the spelling is "subtle" | |You know their forums are 3Com owners only. I was rejected. :-) | |Maybe I shouldn't have sold that old NetServer I had collecting dust. |This summer perhaps I'll buy some dead 3Com/USR gear at the MIT flea |and then insist they let me in as an owner. ;-) | These forums are open. Maybe you tried to subscribe to an internal forum. To Subscribe/Unsubscribe to/from the 3Com Carrier User-Forum - http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+forumlink To access the 3Com Knowledgebase - http://knowledgebase.3com.com To access 3Com Carrier documentation - http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+docs To view 3Com Carrier Service Offerings - http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+service

Hi Mike, I'll get back to you about remotely accessing the HDM console. Regarding channel testing, refer to Appendix C of the Quad Modem doc set. It is entitled Modem Testing. There you should find the information you need. All the best, /Chris 3Com Corp. >From usr-tc I've seen some hints in ARC documentation/release notes that say there's a way to connect to an HDM console through the ARC somehow (presumably over the packet bus)... but I can't find the exact syntax anywhere. This would save me a few serial ports... I'm also trying to figure out how to connect to a particular Quad (or DSP) to feed it AT commands. I have a channel on a Quad I suspect is dead and I'm trying to poke at it a bit to see if it's really dead... Someone want to point me at the relevant chunk of documentation? Maybe "search" in Acrobat just doesn't work well, but I'm having trouble finding it. (Call me blind.) Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

Hi Mike, I'll get back to you about remotely accessing the HDM console. Regarding channel testing, refer to Appendix C of the Quad Modem doc set. It is entitled Modem Testing. There you should find the information you need. All the best, /Chris 3Com Corp. >From usr-tc I've seen some hints in ARC documentation/release notes that say there's a way to connect to an HDM console through the ARC somehow (presumably over the packet bus)... but I can't find the exact syntax anywhere. This would save me a few serial ports... I'm also trying to figure out how to connect to a particular Quad (or DSP) to feed it AT commands. I have a channel on a Quad I suspect is dead and I'm trying to poke at it a bit to see if it's really dead... Someone want to point me at the relevant chunk of documentation? Maybe "search" in Acrobat just doesn't work well, but I'm having trouble finding it. (Call me blind.) Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

I never even opened up the cd ... =) ... got any web links? -----Original Message----- >On Sun, 28 Feb 1999, Jamie Orzechowski wrote: > >|Just wondering if anyone can point me to a reference for ARC filters (and >|netserver) ... I just need some syntax to add blocks for some TCP/UDP ports > > You have all the information in the Total Control CD PDF files. > >- Marcelo > >|--------------------------------------------------- >|Have a Great Day! >| >|Jamie Orzechowski >|RipNET System Admin >| >|Tel.: 613-342-3946 ext 293 >|Tel.: 800-267-4434 ext 293 >|Page.: 613-341-0883 >|EMail.: mhz@ripnet.com >|Web.: http://www.ripnet.com >|Personal.: http://www.moonchilli.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. >| > >- Marcelo > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 to all who replied and have helped with my usr software problem. Tony

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of |beckerr@softrends.com |Sent: Monday, March 01, 1999 11:39 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) HARC Idle q.... | | |Hello, | We are about to upgrade our NETserver to a HiperARC, and I |know that Idle times are not directly available via SNMP anymore |on the HiperARC... my question is this- does the HiperARC actually |take note of the standard RADIUS attribute "Idle-Session-Timeout"? |I know the NETserver doesnt; the only way to get Idles knocked off |on that is to be running the USR RADIUS package + the TC management |on an NT box; and the software polls for idles, and knocks them off, |not the TC box itself. If the HiperARC doesn't support the RADIUS |Idle attribute, then I assume that the only way to get users out is |to use telnet and check for them? I can't imagine everyone is doing |that.... | | 1) Idle timeout works on the netserver with the RADIUS Attribute. (assuming your not running 2 year old code) 2) So doe the HARC. -M

How do you set the default IDLE timout on a HiperARC? We have no default user on the HiperARC now. What, exactly, is the way to get it to have a default IDLE timeout? At 12:45 PM 3/1/99 -0500, you wrote: >Thus spake beckerr@softrends.com >> We are about to upgrade our NETserver to a HiperARC, and I >>know that Idle times are not directly available via SNMP anymore >>on the HiperARC... my question is this- does the HiperARC actually >>take note of the standard RADIUS attribute "Idle-Session-Timeout"? >>I know the NETserver doesnt; the only way to get Idles knocked off >>on that is to be running the USR RADIUS package + the TC management >>on an NT box; and the software polls for idles, and knocks them off, >>not the TC box itself. > >Uhm, that's not correct. Our NETServer's handle Idle-Timeout (in case >our dictionary files don't match, its attribute 28) with no problems >whatsoever. I *believe* HiPer Arcs handle this just as easily, just >there is no user-interface way of checking what the current idle-time on >a port is. >-- >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. > > Richard B. Stuplich DataWave, Not just faster, Better. President, DataWave Technologies 17 T1 circuits and growing strong. DataWave, Wausau's first local ISP to have a direct connection to the midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90. The only area ISP to have redundant T1 NAP connections, All modem compatibility and a staff dedicated exclusively to providing Internet Service to this area. This E-Mail Copyright 1999 Richard Stuplich, see http://dw.net/cr/

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Stuplich |Sent: Monday, March 01, 1999 12:01 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) HARC Idle q.... | | |How do you set the default IDLE timout on a HiperARC? | |We have no default user on the HiperARC now. What, exactly, is the way to |get it to have a default IDLE timeout? Since you can't delete the DEFAULT user on the HARC, you have one. This is where you set the default idle timeout. The settings made on the default user are applied to all dial-in users if not otherwise specified by RADIUS. This will also apply to all local users created after the change of the default user. Its basically a template. -M

Hi All, I am using S&A 6.0.8 with TC HyperDSP. Every time someone tries to authenticate, The high bit of every character in the password in the users table is turned on. It seems to do it before it authenticates because it refuses the connection. The setup program says not to use a secret for accounting or it will encrypt the password. I made sure that the secret was deleted from both the radius and the TC box. Can someone shed some light on this problem? Carl Jagerski Network Administrator, Forward Communications carll@forcomm.net 412-378-4490 Fax: 412-375-0156

Hello, We are about to upgrade our NETserver to a HiperARC, and I know that Idle times are not directly available via SNMP anymore on the HiperARC... my question is this- does the HiperARC actually take note of the standard RADIUS attribute "Idle-Session-Timeout"? I know the NETserver doesnt; the only way to get Idles knocked off on that is to be running the USR RADIUS package + the TC management on an NT box; and the software polls for idles, and knocks them off, not the TC box itself. If the HiperARC doesn't support the RADIUS Idle attribute, then I assume that the only way to get users out is to use telnet and check for them? I can't imagine everyone is doing that.... --Ross beckerr@softrends.com

Thus spake beckerr@softrends.com > We are about to upgrade our NETserver to a HiperARC, and I >know that Idle times are not directly available via SNMP anymore >on the HiperARC... my question is this- does the HiperARC actually >take note of the standard RADIUS attribute "Idle-Session-Timeout"? >I know the NETserver doesnt; the only way to get Idles knocked off >on that is to be running the USR RADIUS package + the TC management >on an NT box; and the software polls for idles, and knocks them off, >not the TC box itself. Uhm, that's not correct. Our NETServer's handle Idle-Timeout (in case our dictionary files don't match, its attribute 28) with no problems whatsoever. I *believe* HiPer Arcs handle this just as easily, just there is no user-interface way of checking what the current idle-time on a port is. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Sun, 28 Feb 1999, Jamie Orzechowski wrote: |Just wondering if anyone can point me to a reference for ARC filters (and |netserver) ... I just need some syntax to add blocks for some TCP/UDP ports You have all the information in the Total Control CD PDF files. - Marcelo |--------------------------------------------------- |Have a Great Day! | |Jamie Orzechowski |RipNET System Admin | |Tel.: 613-342-3946 ext 293 |Tel.: 800-267-4434 ext 293 |Page.: 613-341-0883 |EMail.: mhz@ripnet.com |Web.: http://www.ripnet.com |Personal.: http://www.moonchilli.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. | - Marcelo

Earlier, I emailed the group about a Quad Modem stuck in 2400 BPS mode. This problem was pretty obvious due to the low connect speed. If the speed had been higher, say 14.4 or 19.2 KBPS, we might not have detected it. I emailed this list and disabled the modem. Since there are always two extra ports in a 12 quad chassis, I was not overly concerned. BUT WAIT....THERE'S MORE..... I have spent this morning looking through several of our other chasssis in different physical locations and it appears that the problem is more widespread for us than a single port stuck at 2400 BPS. In one chassis, I have three cards, each with one port locked in at an upper speed of 19,200 BPS. In another chassis, I have two cards that each have a port locked to a max speed of 19,200 BPS. Just as in the case of the 2400 BPS modem, I cannot find any way to change these permanently. The first modem that connects changes the default DTE data rate back to 19200. On a side note, can anyone explain to me why the Default DTE data rate is so important? Anyway here is the real kicker, in yet another chassis, a single quad card had three ports locked at 19,200 and another at 14,200. So after trying everything else, I tried to reflash the card to 5.10/5.9. Now the card is DEAD. Since it is a Digital Quad Modem, there is not a console port to try and SDL any new code, so I am SOL. I had to drive out to the site and replace the card! ARGH. Anyone have any suggestions? Surely, a problem this widespread through a small ISP like ours is occuring undetected across hundreds of other ISPs. I would suggest people with Quad modem cards who are getting complaints of intermittent, low connect speeds, check their ports for this problem. Just 'Select All" ports => Programmed Settings => DTE Interface Settings and check the Default DTE data rate. It appears that the normal default number is 38 kbps. If you see, 19,200, 14,400 or 2,400, you might want to check and see how that port is connecting. Regards, Jim Johnson

On Fri, 26 Feb 1999, Jeff Mcadams wrote: > I can still buy Cisco 2500's, that's older hardware technology than the > NETServers by a generation or two. Cisco has EOL'd the 4000 and 4500's. There is no upgrade path. What are owners of that technology to do? -Dan

Once upon a time beckerr@softrends.com shaped the electrons to say... >on the HiperARC... my question is this- does the HiperARC actually >take note of the standard RADIUS attribute "Idle-Session-Timeout"? That's Idle-Timeout and Session-Timeout, two different things. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Jim Johnson <jim@perigee.net> writes: > On a side note, can anyone explain to me why the > Default DTE data rate is so important? Normally the DTE rate can act as an overall rate limiter to the connection depending on the type of connection being negotiated. Normally this only applies to modems with an actual DTE, but I've seen most releases of the quad code look at this value even when connected on the packet bus. > Since it is a Digital Quad Modem, there is not a > console port to try and SDL any new code, so I am SOL. I had to drive > out to the site and replace the card! ARGH. You don't need a console port for SDL - that's what the NMC is for :-) > Anyone have any suggestions? Surely, a problem this widespread through > a small ISP like ours is occuring undetected across hundreds of other > ISPs. It sounds to me like you may have had some corruption during a code upgrade. I suggest the following process during any upgrade: * Download the new code. * Restore all modems to factory defaults (we restore to the hardware flow control configuration via the NMC - equivalent to AT&F1) * Reprogram any settings you change from the defaults. * Save the modem to NVRAM. In this case, I'd suggest doing the restore/program/save cycle on all of your modems and see if anything changes. While forward upgrades in code are always supposed to maintain settings, it doesn't always work that way - particularly when new releases add new settings and/or start using internal locations that may not have been cleared properly. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

On Mon, 1 Mar 1999, Jim Johnson wrote: > I would suggest people with Quad modem cards who are getting complaints > of intermittent, low connect speeds, check their ports for this > problem. Just 'Select All" ports => Programmed Settings => DTE > Interface Settings and check the Default DTE data rate. It appears that > the normal default number is 38 kbps. If you see, 19,200, 14,400 or > 2,400, you might want to check and see how that port is connecting. I'm pretty sure that rate is only for use with a serial port. If you're using a Netserver or Hiper ARC, that setting is ingnored. Many of my quad modems are set to 19.2 or slower, and they all connect at high speeds. A few weeks ago, I wrote up a war dialer script aimed at my modem pool. It logged the connect speeds, and every single modem connected at 49333 over 5 hours or so the dialer ran. Brian

Once upon a time Dan Hollis shaped the electrons to say... >On Fri, 26 Feb 1999, Jeff Mcadams wrote: >> I can still buy Cisco 2500's, that's older hardware technology than the >> NETServers by a generation or two. >Cisco has EOL'd the 4000 and 4500's. There is no upgrade path. >What are owners of that technology to do? Apples and oranges. They announced it well in advance. They provide maintanence releases of software. In other words they didn't sell a product as *new* with broken features, and then fail to provide any fixes - and instead tell those who bought the old gear to buy new gear. Why is it hard to see the difference? No one has yet presented an equivalent example - except perhaps MS and OS/2. And I wouldn't want to be compared to MS for customer service. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

I think all relavante documentation a freely distributed on http://totalservice.usr.com. Try to look for HARC User Guide under 'Latest Code', find 'harc41user.pdf (~4Mb)' and download it. On Mon, 1 Mar 1999, Jamie Orzechowski wrote: > > I never even opened up the cd ... =) ... got any web links? > > -----Original Message----- > From: Marcelo Souza <mpsouza@centroin.com.br> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Monday, March 01, 1999 10:49 AM > Subject: Re: (usr-tc) Filter docs > > > >On Sun, 28 Feb 1999, Jamie Orzechowski wrote: > > > >|Just wondering if anyone can point me to a reference for ARC filters (and > >|netserver) ... I just need some syntax to add blocks for some TCP/UDP > ports > > > > You have all the information in the Total Control CD PDF files. > > > >- Marcelo > > Jose Roberto Bulcao - RioLink Internet Tel : (021) 577-8899 e-mail : bulcao@rio.com.br

On Mon, 1 Mar 1999, Richard Stuplich wrote: > The analogy isn't relevant. To 'stick' us with the USR/3COM crap and say > "everyone EOLs products" is irresponsible. I smell a class action law suit. Ahh, the good old american pastime -- sue! Litigate! Doesnt it just give you warm fuzzies. Living up to the american stereotype. -Dan

Once upon a time Dan Hollis shaped the electrons to say... >On Mon, 1 Mar 1999, Richard Stuplich wrote: >> The analogy isn't relevant. To 'stick' us with the USR/3COM crap and say >> "everyone EOLs products" is irresponsible. I smell a class action law suit. >Ahh, the good old american pastime -- sue! Litigate! Doesnt it just give >you warm fuzzies. Living up to the american stereotype. Yes, damn right! While there are way to many bullshit lawsuits, just because there are so many crappy ones does not mean that you should not file one when there is a good reason. That is why the courts are there. 3Com loves to use the courts to their advantage if they can, I see nothing wrong with shafted customers using the courts to obtain satisfaction - if 3Com won't do it themselves. And it does not appear that they are going to provide a solution to the flaws in their product. They sold a defective product and are refusing to fix it, and are in fact trying to use it to sell more product as the 'fix'. Grabbing a jar or Vaseline and taking it quietly will just allow them to continue to do the same thing again and again. Aside from the immediate shafting, it is also a bad business practice that should be strongly discouraged. It is looking like the courts may be the only way to get 3Com to cough up a fix. People shout 'sue' quite a bit, usually I blast them for being crazy. Like the folks who think suing over less than perfect PCM modem connects is a good idea - that's stupid. But in this case I'm surprised it hasn't happened yet. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Carl Jagerski was heard to say: >Hi All, > I am using S&A 6.0.8 with TC HyperDSP. Every time someone tries >to authenticate, The high bit of every character in the password in the >users table is turned on. It seems to do it before it authenticates >because it refuses the connection. >The setup program says not to use a secret for accounting or it will >encrypt the password. I made sure that the secret was deleted >from both the radius and the TC box. Look through the RADIUS server script (radserv.scp)... there are a few sections of code in there that "encrypts" secrets and passwords in the database -- some encryption, eh? I removed the stupid waste of CPU time... (you do know you can rewrite that script.) --Ricky

Does anyone know where to find the numbered messages that are connected to the X2 status when monitoring? I have a user who is getting a low connect rate and the X2 status is ChannelNoSymbolRate (13). John Mies

On Mon, 1 Mar 1999, MegaZone wrote: > People shout 'sue' quite a bit, usually I blast them for being crazy. > Like the folks who think suing over less than perfect PCM modem connects > is a good idea - that's stupid. But in this case I'm surprised it hasn't > happened yet. Actually the person I would most like to sue is the idiot engineer who dreamed up the plague that is now 'analogue 56k'. If that wasnt a hyper-extended promise then I dont know what is. 56k is the single biggest headache in ISP history. Ever. Period. Actually you can include all the marketing teams who trumpeted 56k like the second coming. -Dan

Jeff, Do you have any other advice for connecting GeoBook users? I just changed to 4.1.59-5 of the HiperARC software, but my one GeoBook owner still cannot stay connected. She gets connected and my radius software claims she authenticates successfully, but she then gets dropped right away. The latest attempt saw seven successful authentications in a row for the same call. She still didn't stay connected. I am running a mix of 12 quads (5.9.9) and 1 DSP (1.2.60). Thanks, Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley > Sent: Thursday, February 25, 1999 10:59 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) geo-book connect > > > -> Greetings, > -> I am having trouble connecting a client who is using a > Brother Geo-Book. > -> I'm using a TC chassis with HiPer ARC and DSP. No trouble with > Anyone before > -> this. The Brother folks say I need to assign IP and mask and > gateway but I > -> work with a pool. > -> Anyone have a suggestion? > > Talk to Krish. he and I worked on this and you must have 4.1.64 > of HiPerArc > code or higher. > > Jeff Binkley > ASA Network 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. >

Is this how it is done? set user default IDLE_TIMEOUT nnn Is the 'nnn' in minutes or seconds?

David Bolen wrote: > > Jim Johnson <jim@perigee.net> writes: > > > On a side note, can anyone explain to me why the > > Default DTE data rate is so important? > > Normally the DTE rate can act as an overall rate limiter to the > connection depending on the type of connection being negotiated. > Normally this only applies to modems with an actual DTE, but I've seen > most releases of the quad code look at this value even when connected > on the packet bus. > > > Since it is a Digital Quad Modem, there is not a > > console port to try and SDL any new code, so I am SOL. I had to drive > > out to the site and replace the card! ARGH. > > You don't need a console port for SDL - that's what the NMC is for :-) Unfortunately, the NMC can't talk to the card once it has erased its flash memory and then aborted a download. This happened once before to a digital (not an Analog/Digital) quad and the only solution was to return the card to USR. > > > Anyone have any suggestions? Surely, a problem this widespread through > > a small ISP like ours is occuring undetected across hundreds of other > > ISPs. > > It sounds to me like you may have had some corruption during a code > upgrade. I suggest the following process during any upgrade: > > * Download the new code. > * Restore all modems to factory defaults (we restore to the hardware > flow control configuration via the NMC - equivalent to AT&F1) > * Reprogram any settings you change from the defaults. > * Save the modem to NVRAM. I am going to replace the seven quad cards with sticky 'DTE default rates' and put them in a spare chassis and see what, if any, luck I have in trying to reconfigure or reflash the code (i.e., destroy them.) before I send them back to USR for replacement. > > In this case, I'd suggest doing the restore/program/save cycle on all > of your modems and see if anything changes. > > While forward upgrades in code are always supposed to maintain > settings, it doesn't always work that way - particularly when new > releases add new settings and/or start using internal locations that > may not have been cleared properly. Normally, We do a save to NVRAM, Restore from Defaults, Restore fom NVRAM after we upgrade any firmware. I don't know of any other procedure to flush out the old code. I guess no one else is aware of having intermittent slow connections due to faulty quads in their hubs. Personally, I find it a little scary that a quad card can sit there in a such a state without any indication of a problem..... -JJ

On Mon, 1 Mar 1999, Ricky Beam wrote: > Dan Hollis was heard to say: > >Actually the person I would most like to sue is the idiot engineer who > >dreamed up the plague that is now 'analogue 56k'. If that wasnt a > >hyper-extended promise then I dont know what is. 56k is the single biggest > >headache in ISP history. Ever. Period. > (It's engineer_s_.) Heh, the theory is sound! And it works perfectly in > the lab -- and in the field if you break a few laws in the US. There is always a mastermind behind the scheme, no matter how one might try to obscure and hide it behind layers of management. Even in committee, someone is always the first to speak up with a proposal even if the rest just go along with it. I want to know who that person is. The single person responsible for masterminding "analogue 56k". There is a person out there, somewhere. Perhaps hiding (for good reason :-) -Dan

Thus spake Jim Johnson >David Bolen wrote: >> You don't need a console port for SDL - that's what the NMC is for :-) >Unfortunately, the NMC can't talk to the card once it has erased its >flash memory and then aborted a download. Oh, nonsense...I've done this many times. It takes a rare situation indeed to make a card not take code. The NMC can still throw code on a flash-erased quad with no problem. Try a hardware reset on the slot, give it a minute or two, then try the download again. >This happened once before to >a digital (not an Analog/Digital) quad and the only solution was to >return the card to USR. Someone at USR gave you a load of hooey there. >I guess no one else is aware of having intermittent slow connections due >to faulty quads in their hubs. Personally, I find it a little scary that >a quad card can sit there in a such a state without any indication of a >problem..... That's because its not a problem...its a configuration option. Now, if the configuration option really isn't sticking when you set it, save it, and everything, then *that* might be a problem, but I seriously doubt that the card is bad and/or needs to be returned to USR. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jim Johnson <jim@perigee.net> writes: > Unfortunately, the NMC can't talk to the card once it has erased its > flash memory and then aborted a download. This happened once before to > a digital (not an Analog/Digital) quad and the only solution was to > return the card to USR. It is possible to get a card in that state (although if you keep at least one NIC around you can just use PCSDL after getting the card returned to a central site of yours), but it's not easy. I've aborted many a quad download in all sorts of states and generally restarting the download is fine. I think you can get in trouble if the NMC resets before it is retried, but I'd have to run some tests to be sure. > Normally, We do a save to NVRAM, Restore from Defaults, Restore fom > NVRAM after we upgrade any firmware. I don't know of any other > procedure to flush out the old code. This is sort of a strange procedure. Assuming we're talking about following a code upgrade, first, the initial save is going to save a potentially bad state (post-upgrade) to NVRAM. Then, even though you restore from defaults, you then restore from NVRAM which you previously saved, so your net result is no change. In effect, if there was a problem with some internal setting, the above procedure explicitly preserves that problem :-) The point I was suggesting was that sometimes various internal status or configuration information is in a bad state following a code upgrade. Restoring to factory defaults resets all internal information (so even if the newer code used previously unused settings, restoring under control of that newer code flushes those out), which you can then adjust and save to NVRAM. That's why it's important that the first thing you do post-download is restoring from factory defaults. This resets the internal state for all known information (to the currently running code). Only save to NVRAM _after_ restoring, or else you may preserve the bad information. > I guess no one else is aware of having intermittent slow connections due > to faulty quads in their hubs. Personally, I find it a little scary that > a quad card can sit there in a such a state without any indication of a > problem..... I've definitely seen quad cards with this 2400bps behavior, but only after an upgrade where I didn't follow the restore from factory defaults behavior. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

I'd bet they will use Cisco 4000 and 4500's, happily, for many years to come because they don't have horrible flaws in the hardware and code like ALL the x2 racks I have ever used. The analogy isn't relevant. To 'stick' us with the USR/3COM crap and say "everyone EOLs products" is irresponsible. I smell a class action law suit. My USR and 3COM equipment has NEVER performed as advertised! Anyone suing 3COM, sign me up! At 01:09 PM 3/1/99 -0800, you wrote: >On Fri, 26 Feb 1999, Jeff Mcadams wrote: >> I can still buy Cisco 2500's, that's older hardware technology than the >> NETServers by a generation or two. > >Cisco has EOL'd the 4000 and 4500's. There is no upgrade path. >What are owners of that technology to do? > >-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. > > Richard B. Stuplich DataWave, Not just faster, Better. President, DataWave Technologies 17 T1 circuits and growing strong. DataWave, Wausau's first local ISP to have a direct connection to the midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90. The only area ISP to have redundant T1 NAP connections, All modem compatibility and a staff dedicated exclusively to providing Internet Service to this area. This E-Mail Copyright 1999 Richard Stuplich, see http://dw.net/cr/

David Bolen wrote: > > Jim Johnson <jim@perigee.net> writes: > > > Unfortunately, the NMC can't talk to the card once it has erased its > > flash memory and then aborted a download. This happened once before to > > a digital (not an Analog/Digital) quad and the only solution was to > > return the card to USR. > > It is possible to get a card in that state (although if you keep at > least one NIC around you can just use PCSDL after getting the card > returned to a central site of yours), but it's not easy. I've aborted > many a quad download in all sorts of states and generally restarting > the download is fine. I think you can get in trouble if the NMC > resets before it is retried, but I'd have to run some tests to be sure. > > > Normally, We do a save to NVRAM, Restore from Defaults, Restore fom > > NVRAM after we upgrade any firmware. I don't know of any other > > procedure to flush out the old code. > > This is sort of a strange procedure. Assuming we're talking about > following a code upgrade, first, the initial save is going to save a > potentially bad state (post-upgrade) to NVRAM. Then, even though you > restore from defaults, you then restore from NVRAM which you > previously saved, so your net result is no change. In effect, if > there was a problem with some internal setting, the above procedure > explicitly preserves that problem :-) I realize it seems strange, but according to the USR guy who gave me the procedure, it clears out the problem associated with the way their firmware changes it size from release to release and leaves code fragments in memory. The 'Restore from Defaults' flushes things out and then you can reload you settings again from NVRAM. Believe it or not, this procedure has 'cured' a lot of strange behavior for us over the years. > > The point I was suggesting was that sometimes various internal status > or configuration information is in a bad state following a code > upgrade. Restoring to factory defaults resets all internal > information (so even if the newer code used previously unused > settings, restoring under control of that newer code flushes those > out), which you can then adjust and save to NVRAM. > > That's why it's important that the first thing you do post-download is > restoring from factory defaults. This resets the internal state for > all known information (to the currently running code). Only save to > NVRAM _after_ restoring, or else you may preserve the bad information. You could do it that way, but I have never had to. In this case, these modems have not been upgraded for close to a year. They have also been working fine for that long. > > I guess no one else is aware of having intermittent slow connections due > > to faulty quads in their hubs. Personally, I find it a little scary that > > a quad card can sit there in a such a state without any indication of a > > problem..... > > I've definitely seen quad cards with this 2400bps behavior, but only > after an upgrade where I didn't follow the restore from factory > defaults behavior. Hmmm. Lucky you had such a simple fix. Jim

Jeff Mcadams <jeffm@iglou.com> writes: > I don't pay a great deal of attention to what MSFT does, but to my > knowledge, they didn't drop support of a product that they sold as > recently as 6 months ago. Can't resist a quick Microsoft bash... Can you say OS/2? Went from full (not to mention a high profile product) to no support in a heck of a lot less than 6 months... They were selling $2000-$3000 developer kits up until the day before they announced they were dumping it. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Jeff Mcadams wrote: > > Thus spake Jim Johnson > >David Bolen wrote: > >> You don't need a console port for SDL - that's what the NMC is for :-) > > >Unfortunately, the NMC can't talk to the card once it has erased its > >flash memory and then aborted a download. > > Oh, nonsense...I've done this many times. It takes a rare situation > indeed to make a card not take code. The NMC can still throw code on a > flash-erased quad with no problem. Try a hardware reset on the slot, > give it a minute or two, then try the download again. Well, I did a hardware reset and it still would not play with the NMC. I also pulled the card out and reseated it and it would not cooperate. I have it here at the main office and it is being as recalcitrant as ever. > > >This happened once before to > >a digital (not an Analog/Digital) quad and the only solution was to > >return the card to USR. > > Someone at USR gave you a load of hooey there. > > >I guess no one else is aware of having intermittent slow connections due > >to faulty quads in their hubs. Personally, I find it a little scary that > >a quad card can sit there in a such a state without any indication of a > >problem..... > > That's because its not a problem...its a configuration option. Now, if > the configuration option really isn't sticking when you set it, save it, > and everything, then *that* might be a problem, but I seriously doubt > that the card is bad and/or needs to be returned to USR. > -- > 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.

On Fri, Feb 26, 1999 at 03:18:48PM -0500, Jeff Mcadams wrote: > > >What you appear to be expecting is a free migration path... > >eg. 286 -> 386 -> 486 -> Pentium -> PPro -> PII -> PIII > > No, again, I'm expecting a fix for my bug that I've had a ticket open on > since April. If they can do that without me having to get new > hardware...*wonderful*. That would even be better than free > replacement, because even with free replacement, there is still cost > involved in my time and energy of going to our POPs and doing that > actual work to do the replacement. Or if this equipment was bought even > as much as 2 years ago, I could even understand that. We bought > NETServer's (already in the channel I believe) as late as 3 months ago > though. Recall the intel "Pentium FDIV bug"- intel shipped a bunch of chips which were broken. Once it was discovered, intel initially said it would only affect a _very_ few people. People started raising holy terror, and intel agreed to replace the chips at no cost, to anyone who would send them their chip. A hardware fix, at no cost to the consumer. 3Com, bless their hearts, isn't even willing to provide no-cost software fixes. --Ross beckerr@softrends.com

Jim Johnson <jim@perigee.net> writes: > Well, I did a hardware reset and it still would not play with the NMC. > I also pulled the card out and reseated it and it would not cooperate. Just to check, by "play" you mean accept a download right? Once the card has no code, it won't respond to any normal operations except for the download. Also, if you're finding that the NMC doesn't identify the card properly, then you may get stopped by the type check the NMC does unless you force the download by setting the force parameter in the command table (I'm not sure if you can do this via TCM or not). > I have it here at the main office and it is being as recalcitrant as > ever. It's always possible that there is something else wrong too - since you've got it local, stick a NIC on it (presuming you have at least one NIC from some analog or dual card somewhere - if you don't, it might be a good thing to get to keep around for the future) and see if even PCSDL will work - you may find there's something else going on. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Jim Johnson <jim@perigee.net> writes: > I realize it seems strange, but according to the USR guy who gave me the > procedure, it clears out the problem associated with the way their > firmware changes it size from release to release and leaves code > fragments in memory. But it still doesn't make sense, and it wouldn't be the first time some bad info got out. Once running with the new code the in-memory map is the new map, and that's what gets written to the flash. Restoring may change the in-memory copy, but the later restoration from NVRAM would overwrite that again. I suppose this might clean up some values that implicitly go to flash (similar to how AT&Z stuff works), but... > Believe it or not, > this procedure has 'cured' a lot of strange behavior for us over the > years. Well, I'm hardly one to speak against something that has worked for you. You might give a shot at my procedure for some of your problem modems just for the heck of it though - can't really hurt, could it? -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

David Bolen wrote: > > Jim Johnson <jim@perigee.net> writes: > > > Well, I did a hardware reset and it still would not play with the NMC. > > I also pulled the card out and reseated it and it would not cooperate. > > Just to check, by "play" you mean accept a download right? Once the > card has no code, it won't respond to any normal operations except for > the download. Also, if you're finding that the NMC doesn't identify > the card properly, then you may get stopped by the type check the NMC > does unless you force the download by setting the force parameter in > the command table (I'm not sure if you can do this via TCM or not). > > > I have it here at the main office and it is being as recalcitrant as > > ever. > > It's always possible that there is something else wrong too - since > you've got it local, stick a NIC on it (presuming you have at least > one NIC from some analog or dual card somewhere - if you don't, it > might be a good thing to get to keep around for the future) and see if > even PCSDL will work - you may find there's something else going on. > Can you use a NIC on the back of the chassis on the digital quad modem? That would be a useful NIC to keep around if it would work. Jim

Jim Johnson <jim@perigee.net> writes: > Can you use a NIC on the back of the chassis on the digital quad modem? > That would be a useful NIC to keep around if it would work. Yep - any of the quad NICs (either RS232 only or RS232/RJ11) will work with any variant of quad cards, although only analog cards can use the RJ11 ports if present. All of the quad cards understand how to use a NIC for their serial DTE port (unless overridden by a packet bus connection formed from a card such as the NETServer). The "analog" versus "digital" difference in the cards is what they can do with their "line side" interface. An analog card can only use the RJ11 ports on a NIC, whereas a digital card can only use the TDM bus to a circuit card such as the dual T1/PRI cards. A dual quad card can do both. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Thus spake Dan Hollis >On Fri, 26 Feb 1999, Jeff Mcadams wrote: >> I can still buy Cisco 2500's, that's older hardware technology than the >> NETServers by a generation or two. >Cisco has EOL'd the 4000 and 4500's. There is no upgrade path. >What are owners of that technology to do? A quote from Cisco's web page concerning the EOL'ing of the 4000 and 4500 (note, they aren't EOL'ing the 4500-M, only the 4500, 4000 and 4000-M): Because Cisco is committed to upholding its investment protection guarantee, many EOL products can be upgraded or traded in for newer products. And, since these products have a large commonality with the non-EOL'ed products in the family (4500-M and 4700-M) many of the new NP's will work in the EOL'ed boxes, as well as new versions of IOS will still work in at least the 4500 (same processor as the 4500-M and 4700-M). In short, Cisco is *very* good about providing upgrade paths for EOL'ed products, and even still providing bug fixes (though non-supported). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Mon, 1 Mar 1999, Tatai SV Krishnan wrote: > On Sun, 28 Feb 1999, Mike Andrews wrote: > > > Great, just what I needed. Now why would a Quad modem get a DSP Interrupt > > Timeout when trying to answer a call... > > Where are you see thins? Is this on a ati6 screen on the modem? or > something in the syslog? ATI6, under "failure to connect reason". I think I get a DTE Ring No Answer snmp trap around the same time -- I'm not sure because I changed that Dual PRI card to fixed assignment and routed calls around the dud modem. I put it back online today though so we'll see if it's cleared itself or not. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

Mike Andrews <mandrews@termfrost.org> writes: > On Sun, 28 Feb 1999, Mike Andrews wrote: > > > Great, just what I needed. Now why would a Quad modem get a DSP Interrupt > > Timeout when trying to answer a call... (...) > ATI6, under "failure to connect reason". I think I get a DTE Ring No > Answer snmp trap around the same time -- I'm not sure because I changed > that Dual PRI card to fixed assignment and routed calls around the dud > modem. I put it back online today though so we'll see if it's cleared > itself or not. An occasional DSP interrupt timeout can just be a software problem, potentially if the code got into a bad state - for which a slot reset (not just a modem reset) should clean things up. However, it could also be an indication of a failing DSP chip (failing to generate a programmed interrupt), in which case it will probably be the failure cause for the majority of calls handled by that modem, and you'll want to replace the hardware. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Jim Johnson was heard to say: >I realize it seems strange, but according to the USR guy who gave me the >procedure, it clears out the problem associated with the way their >firmware changes it size from release to release and leaves code >fragments in memory. The 'Restore from Defaults' flushes things out and >then you can reload you settings again from NVRAM. Believe it or not, >this procedure has 'cured' a lot of strange behavior for us over the >years. You should do this because the flash upgrade proceedure does not always translate the NVRAM setting correctly from version to version, esp. for downgrades and skipped version upgrades, etc. I cannot really blame them as that's a fairly complex problem to be able to translate any NVRAM config to any other NVRAM config. --Ricky

At 01:53 PM 3/1/99 -0800, Dan Hollis wrote: >On Mon, 1 Mar 1999, Richard Stuplich wrote: >> The analogy isn't relevant. To 'stick' us with the USR/3COM crap and say >> "everyone EOLs products" is irresponsible. I smell a class action law suit. > >Ahh, the good old american pastime -- sue! Litigate! Doesnt it just give >you warm fuzzies. Living up to the american stereotype. really it's the most expensive and least productive solution IMHO.. especially on the short term, where most of the damage is caused, and good help is needed the most.. But it you want ultimate justice and don't care how long it takes or how much it costs, then sue away... it's just my ego and principles can't afford that.. and my customers can't wait.. It also doesn't hurt to think smart and hussle a little.. I saw this coming a year ago and dumps that crap fast.. and at a good price.. probably couldn't give away a netserver nowadays unless someone wanted it for the trade-up program... Now there is another idea for you Jeff! Find another isp as pissed as you are and buy his netservers and trade up.. sell the resulting hdms if you don't want/need them and you have a lifetime supply of arcs for (nearly) free... That's lots easier than sueing or even writing letters to 3com management IMHO.. anyway, just trying to help.. I'd like for all TC users to be as happy as we are.. (not that we are THAT happy mind you).. :) Allen > >-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. > >

Ricky Beam <jfbeam@enterprise.interpath.net> writes: > You should do this because the flash upgrade proceedure does not always > translate the NVRAM setting correctly from version to version, esp. for > downgrades and skipped version upgrades, etc. I cannot really blame them > as that's a fairly complex problem to be able to translate any NVRAM config > to any other NVRAM config. While some paths may be problematic (specifically downgrading, since code X can't be expected to know what code Y is doing), I sort of disagree in the general case, and certainly in the upgrade case. Future code should always be able to migrate older configs, since they'll know exactly what was there. Proper design and identification of the parameter storage can make this very doable. Heck, proper parameterization of configuration information should make any code changes adjust transparently, with a downgrade case simply ignoring or clearing unknown (new features no longer supported) configuration info. Not to mention that in the quad case, I don't believe I've seen cases other than augmenting existing configuration information for upgrades - e.g., register ## always remains the same, with new features being added as new registers, or by using previously reserved bits in existing registers. I do know that the stated goal is to permit an upgrade completely transparently, it's just that they don't always hit the goal. Not too much of a biggie given the workaround but I do think that not being able to at least handle an upgrade path is a bug. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Bob Purdon was heard to say: >> Cisco has EOL'd the 4000 and 4500's. There is no upgrade path. >> What are owners of that technology to do? > >Keep their gear. Cisco still provide IOS for those boxes, and still >actively support them (as far as I'm aware anyway). For now anyway. Cisco may eventually stop generating IOS for it, but I somehow doubt it unless IOS sees some major changes in coming years. >I'd be happy for 3COM to do the same. So would I and most of the Netserver owners. 48port TC hardware is good for lots of places. 3Com seems to be going after the top end of the dialup spectrum. Placing a 200Mhz 603e in a chassis to run 48 or even 96 ports seems a little like overkill. If they wrote nice, clean, efficient code for the 486dx4-100 netservers, the 10 year old technology could last another 10 years. (I still have a 13-year-old Ford Tempo :-)) --Ricky

Dan Hollis was heard to say: >Actually the person I would most like to sue is the idiot engineer who >dreamed up the plague that is now 'analogue 56k'. If that wasnt a >hyper-extended promise then I dont know what is. 56k is the single biggest >headache in ISP history. Ever. Period. (It's engineer_s_.) Heh, the theory is sound! And it works perfectly in the lab -- and in the field if you break a few laws in the US. >Actually you can include all the marketing teams who trumpeted 56k like >the second coming. I just adds something to it, tho' doesn't it. --Ricky

> Correct... the AS51 card is a 2511 on a card. We looked at using them at remote POP's - we already use conventional Cisco 2511's there. The asyncs for remtoe console access, and the sync for frame-relay. In the TCH, of course you get remote bootability (without a remote power switching thingy), dual power, and smaller footprint :-) > Which brings to mind an interesting use for a TCH... 16 2511's in a rack :-) > (Or course, you could do the same thing with the Edge server cards...) Think of all the ether connections :-( Still, 16 2511's in 5U plus a 1U switch or hub, is still fairly dense... > Hmm, 8 Edge Pro's (running linux or freebsd) in one 5U rack... Been there too... When I priced the Edgeserver (not the Pro), they quoted me around $20k for the base model. No way! Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> >me around $20k for the base model. No way! > > So, I didn't say it was cheap... just dense. Over here, density isn't everything :-) I could build a full size functionally equivalent PC for $3-$4k, and use the other $16-$17k to pay extra rent, power, etc. It's a neat solution (the Edgeserver), but I can't justify it :-) Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> Mike Andrews <mandrews@termfrost.org> writes: > > > On Sun, 28 Feb 1999, Mike Andrews wrote: > > > > > Great, just what I needed. Now why would a Quad modem get a DSP Interrupt > > > Timeout when trying to answer a call... > (...) > > ATI6, under "failure to connect reason". I think I get a DTE Ring No > > Answer snmp trap around the same time -- I'm not sure because I changed > > that Dual PRI card to fixed assignment and routed calls around the dud > > modem. I put it back online today though so we'll see if it's cleared > > itself or not. > > An occasional DSP interrupt timeout can just be a software problem, > potentially if the code got into a bad state - for which a slot reset > (not just a modem reset) should clean things up. > I agree. > However, it could also be an indication of a failing DSP chip > (failing to generate a programmed interrupt), in which case it will > probably be the failure cause for the majority of calls handled by > that modem, and you'll want to replace the hardware. > One of the indications that you can see is if this particular port has any failures on the hiper arc side. If you see the interface is down then that would be a indication krish > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ > \-----------------------------------------------------------------------/ >

Wayne, This is a different problem. I'd see if krish will work with you on a debug trace. I am going to work with him on the webramp problem tomorrow. When did this start ? Was she working before or new ? Jeff Binkley ASA Network Computing u>Jeff, u>Do you have any other advice for connecting GeoBook users? I just u>changed to 4.1.59-5 of the HiperARC software, but my one GeoBook owner u>still cannot stay connected. She gets connected and my radius software u>claims she authenticates successfully, but she then gets dropped right u>away. The latest attempt saw seven successful authentications in a u>row for the same call. She still didn't stay connected. u>I am running a mix of 12 quads (5.9.9) and 1 DSP (1.2.60). u>Thanks, u>Wayne Barber u>Coastal Telco Services u>> -----Original Message----- u>> From: owner-usr-tc@lists.xmission.com u>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley u>> Sent: Thursday, February 25, 1999 10:59 PM u>> To: usr-tc@lists.xmission.com u>> Subject: (usr-tc) geo-book connect u>> u>> u>> -> Greetings, u>> -> I am having trouble connecting a client who is using a u>> Brother Geo-Book. u>> -> I'm using a TC chassis with HiPer ARC and DSP. No trouble with u>> Anyone before u>> -> this. The Brother folks say I need to assign IP and mask and u>> gateway but I u>> -> work with a pool. u>> -> Anyone have a suggestion? u>> u>> Talk to Krish. he and I worked on this and you must have 4.1.64 u>> of HiPerArc u>> code or higher. u>> u>> Jeff Binkley u>> ASA Network Computing u>> u>> - u>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u>> with "unsubscribe usr-tc" in the body of the message. u>> For information on digests or retrieving files and old messages u>> send "help" to the same address. Do not use quotes in your u>message. > u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. u> CMPQwk 1.42-21 9999

On Mon, 1 Mar 1999, Dan Hollis wrote: > On Mon, 1 Mar 1999, Ricky Beam wrote: > > Dan Hollis was heard to say: > > >Actually the person I would most like to sue is the idiot engineer who > > >dreamed up the plague that is now 'analogue 56k'. If that wasnt a > > >hyper-extended promise then I dont know what is. 56k is the single biggest > > >headache in ISP history. Ever. Period. > > (It's engineer_s_.) Heh, the theory is sound! And it works perfectly in > > the lab -- and in the field if you break a few laws in the US. > > There is always a mastermind behind the scheme, no matter how one might > try to obscure and hide it behind layers of management. Even in committee, > someone is always the first to speak up with a proposal even if the rest > just go along with it. > > I want to know who that person is. The single person responsible for > masterminding "analogue 56k". There is a person out there, somewhere. > Perhaps hiding (for good reason :-) "Brent Townshend" is the name you're looking for. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

On Mon, 1 Mar 1999, Jeff Binkley wrote: > > > > Wayne, > > This is a different problem. I'd see if krish will work with you on a > debug trace. I am going to work with him on the webramp problem > tomorrow. When did this start ? Was she working before or new ? This could be a chap/pap problem on the geo. Take a mon ppp and end it to me. krish > > Jeff Binkley > ASA Network Computing > > > u>Jeff, > > u>Do you have any other advice for connecting GeoBook users? I just > u>changed to 4.1.59-5 of the HiperARC software, but my one GeoBook owner > u>still cannot stay connected. She gets connected and my radius software > u>claims she authenticates successfully, but she then gets dropped right > u>away. The latest attempt saw seven successful authentications in a > u>row for the same call. She still didn't stay connected. > > u>I am running a mix of 12 quads (5.9.9) and 1 DSP (1.2.60). > > u>Thanks, > u>Wayne Barber > u>Coastal Telco Services > > u>> -----Original Message----- > u>> From: owner-usr-tc@lists.xmission.com > u>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley > u>> Sent: Thursday, February 25, 1999 10:59 PM > u>> To: usr-tc@lists.xmission.com > u>> Subject: (usr-tc) geo-book connect > u>> > u>> > u>> -> Greetings, > u>> -> I am having trouble connecting a client who is using a > u>> Brother Geo-Book. > u>> -> I'm using a TC chassis with HiPer ARC and DSP. No trouble with > u>> Anyone before > u>> -> this. The Brother folks say I need to assign IP and mask and > u>> gateway but I > u>> -> work with a pool. > u>> -> Anyone have a suggestion? > u>> > u>> Talk to Krish. he and I worked on this and you must have 4.1.64 > u>> of HiPerArc > u>> code or higher. > u>> > u>> Jeff Binkley > u>> ASA Network Computing > u>> > u>> - > u>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > u>> with "unsubscribe usr-tc" in the body of the message. > u>> For information on digests or retrieving files and old messages > u>> send "help" to the same address. Do not use quotes in your > u>message. > > > > u>- > u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > u> with "unsubscribe usr-tc" in the body of the message. > u> For information on digests or retrieving files and old messages send > u> "help" to the same address. Do not use quotes in your message. > > u> > > 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. >

So I was looking for some weed one day and I inquired as to what was available to my favorite drug dealer. He said he had some and it was really really top-notch stuff. Then I asked around and found out a much more interesting story. It seems that the weed he had wasn't really that good. And the reason for that was that he was developing his own super-weed...the stuff he had at the moment was just some crap he bought down in the projects. The idea was to sell that stuff to meet the demand while he worked on his own stuff. I didn't buy any, but a lot of my friends did. I figured that I'd just wait for the super-weed...and if I couldn't wait, well, I could always go down to the projects myself and grab some from the source. And wait I did, and my dealer came out with the super-weed. It had some serious drawbacks. First, it is a little harsh for the uninitiated; only an experienced smoker has any real hope of realizing the full potential of the high. Second, my dealer also wants me to pay a significant percentage of the price every year so I can occasionally call and get him to help me smoke it...I still don't know what that's all about. And third, I also have to realize that with this new super-weed, I'm suddenly not his target market anymore. He's got mob families who are getting really interested and hungry for this stuff. Even if I bought a few hundred pounds of his stuff, I'd still not be a drop in the bucket compared to the new potential revenue stream... and the new target market doesn't bellyache about the yearly "support" extortion either, they've been around and are used to that as a form of business and don't mind paying it...indeed, they expect to pay it. So I do realize that my dealer doesn't care about me anymore. But it's SUPER-WEED. It KICKS ASS. With some of it, I could have a competitive edge over the other guy in town. Given that I can handle the harshness, and the 'help you smoke it' extortion can be reasonably worked around by doing a couple of things differently, I chose to go with the super-weed. And I'm lovin' it. The only problem I have is that now, whenever I go to a party, everyone is grumping and bellyaching about how our dealer "forgot" about us, the people he knew on the street. The ones who foolishly bought the crap he was selling while he was developing his super-weed are even whining about how he should give them some super-weed for free. (what have *they* been smoking???) While I can identify with the problem, and I don't apologize for the dealer...I do indeed think the way he's acting of late sucks pretty badly...I also understand that business is business, and I'm only responsible for my own. If I had bought the crap, I'd accept the fact that *I* screwed up. Putting the blame on the dealer is a cop-out. *Anyone* who had properly researched their purchase would have been able to see what was going to happen in the relatively near future; complaining about it now amounts to little more than outright whining. Yeah, yeah, I know that back then, the dealer said that the crappy weed was the greatest stuff since the discovery of the mushroom, but one would have to be a total fool to believe everything a dealer says without checking it out... ...wouldn't they? [NOTE TO THE HUMOR-IMPAIRED: The above message is satire, and was written with the intention of making my point in the ongoing discussion by using humorous analogy. If you don't find it humorous, please accept my apology. It was, however, officially deemed to be at least slightly humorous in the opinion of several test subjects. Your mileage may vary. Whatever you feel, be certain to realize that I'm not condoning the smoking of illegal drugs, neither am I a consumer of them (the price/performace on em didn't look good after I got out of college and had to pay for things with my own money).] [NOTE TO THE NITPICKER-ENHANCED: Yes, I realize that referring to a certain venerable system from another dealer as 'crap from the projects' is stretching the analogy....we all know it's not that bad. But it fit, okay?] [NOTE TO PEOPLE LIKE MYSELF WHO WISH THIS LIST WAS MORE TECH TALK ABOUT TC SYSTEMS AND LESS POLITICAL BITCHING: Y'know, I was thinking that you could rig another telephone number to point to the head of your hunt group. Then, you could rig your HDSP modem to configure itself differently based on the called number. Easy enough so far, right? The twist is that one of the configurations is an extremely optimized configuration, so that people with the newest code and the fancy modems can feel the power. The other config is one that has all the fancy stuff off...like the compression that freaks out all the winmodems and the like...a work-with-anything config. Then you just put it in your setup info....'if you have trouble accessing with the first number, try with the second yaddayadda'. I haven't tried this yet, but it is apparently simple enough on the surface. WDYT?] Lon Stockton MoonStar

On Tue, 2 Mar 1999, Jeff Mcadams wrote: > Thus spake Lon R. Stockton, Jr. > >So I was looking for some weed one day and I inquired as to what was > >available to my favorite drug dealer. He said he had some and it was > >really really top-notch stuff. > > [snip] > > >But it's SUPER-WEED. It KICKS ASS. With some of it, I could have a > >competitive edge over the other guy in town. > > Here's the problem with your analogy. I don't *need*, the "super-weed." > The crappy weed from the projects should get me all the high I need and > want, and paid for! Look, I think you are all missing the real issue, which is, when working on 3Com/USR Total Control chassis, *any* kind of drugs are good to have. > -- > 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)

Thus spake Lon R. Stockton, Jr. >So I was looking for some weed one day and I inquired as to what was >available to my favorite drug dealer. He said he had some and it was >really really top-notch stuff. [snip] >But it's SUPER-WEED. It KICKS ASS. With some of it, I could have a >competitive edge over the other guy in town. Here's the problem with your analogy. I don't *need*, the "super-weed." The crappy weed from the projects should get me all the high I need and want, and paid for! So, to extend your analogy here. I paid for a high that 10 pounds of weed from the projects should give me. I'm not getting that high, so I went back to the dealer to fix it. He said he can't do anything with that weed anymore (his dealer in the projects got busted), but if I pay him even more money to get some of the super-weed, I should be able to get the high that the 10 pounds of weed from the projects should have given me in the first place and that I already paid for! >The only problem I have is that now, whenever I go to a party, everyone >is grumping and bellyaching about how our dealer "forgot" about us, >the people he knew on the street. The ones who foolishly bought the >crap he was selling while he was developing his super-weed are even >whining about how he should give them some super-weed for free. (what >have *they* been smoking???) The dealer can either come up with a way that I can get the high that I already paid for from the weed he already sold me, or he can give me some of the super-weed to make up for the deficiencies of the weed from the projects. That's even accounting that the weed came from the projects and that its going to not be as good weed as the super-weed anyway, but the weed from the projects didn't even live up to what it was supposed to do as weed from the projects! [snip] >If I had bought the crap, I'd accept the fact >that *I* screwed up. Whoa...and this is the crux of where you're bad analogy comes from. The customer didn't screw up here. The dealer most definitely did! The weed is definitely defective, even for weed from the projects. The dealer's handling of the situation was appalling, and all I want is the high that I originally paid for and *still* haven't gotten and the dealer still seems to be making excuses for. >Putting the blame on the dealer is a cop-out. Wrong...the dealer screwed up big time. Again, all I want is the functionality I paid for, nothing more. I don't *need* an upgrade to HiPer Arcs, the NETServers as a hardware product work just fine, its the software that's broken and its the software that I really want fixed. If 3Com doesn't want to give me some of the "super-weed", then they can give me a software fix...oh, but they screwed that up too. Again, *I JUST WANT THE FUNCTIONALITY THAT I'VE ALREADY PAID FOR!* I DON'T NEED AN UPGRADE! >*Anyone* who had properly researched their purchase would have been >able to see what was going to happen in the relatively near future; First off...we've been purchasing NETServers for 2 to 3 years now...before the HiPer equipment was ever a glimmer in 3Com's eye, so that argument falls flat on its face. Second, the HiPer Arc did not do what we needed until version 4.1.59-2, so purchasing HiPer Arcs instead was not an option, even when they were available. >complaining about it now amounts to little more than outright whining. No, complaining about it now is an attempt to get 3Com to do the right thing, since they seem really hesitant to ever do that. >If you don't find it humorous, please accept my apology. I did find it rather humorous...though horribly flawed as an analogy. >[NOTE TO PEOPLE LIKE MYSELF WHO WISH THIS LIST WAS MORE TECH TALK >ABOUT TC SYSTEMS AND LESS POLITICAL BITCHING: Y'know, I was thinking >that you could rig another telephone number to point to the head >of your hunt group. Then, you could rig your HDSP modem to configure >itself differently based on the called number. Easy enough so far, >right? The twist is that one of the configurations is an extremely >optimized configuration, so that people with the newest code and >the fancy modems can feel the power. The other config is one that >has all the fancy stuff off...like the compression that freaks out >all the winmodems and the like...a work-with-anything config. Then >you just put it in your setup info....'if you have trouble accessing >with the first number, try with the second yaddayadda'. I haven't >tried this yet, but it is apparently simple enough on the surface. >WDYT?] Hrmm...interesting thought...I know the Arc can "authenticate" based on DNIS, so it could change the behavior of the port that way, though that doesn't take care of modem connect problems because the modems have already connected, or failed to connect by the time the Arc sees the DNIS I believe. I'm unaware of any way to have the modem on the DSP reconfigure on the fly based on DNIS at this point, though I'm not extremely knowledgeable about them yet. That would be pretty cool to do, but I think it would require some changes in the DSP's to do it (I would be happy to learn that I'm wrong). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

This is good stuff gentlemen..... >Thus spake Lon R. Stockton, Jr. >So I was looking for some weed one day and I inquired as to what was >available to my favorite drug dealer. He said he had some and it was >really really top-notch stuff. >[snip] >But it's SUPER-WEED. It KICKS ASS. With some of it, I could have a >competitive edge over the other guy in town. >Here's the problem with your analogy. I don't *need*, the "super-weed." >The crappy weed from the projects should get me all the high I need and >want, and paid for! >So, to extend your analogy here. I paid for a high that 10 pounds of >weed from the projects should give me. I'm not getting that high, so I >went back to the dealer to fix it. He said he can't do anything with >that weed anymore (his dealer in the projects got busted), but if I pay {SUPER-SNIP} Well If I got "lame" weed that was passed off as "SUPER" weed from a dealer I would: 1. Rip the dealer off for the amount he cost me or hold him at gun point for my money back then...Shoot the dealer or NARC on him 2. Find a new dealer (as the first one is in jail or dead) I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting note Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com support the netserver? William Behrens

Hi Mike, FYI 3Com plans to support the HiPer DSP remote console (command line interface) with Total Control system release 3.6. Sometime in the next four months you should hear more about this. Chris Ashcraft 3Com Corp. Chris Ashcraft/MW/US/3Com 03/01/99 10:39 AM cc: Hi Mike, I'll get back to you about remotely accessing the HDM console. Regarding channel testing, refer to Appendix C of the Quad Modem doc set. It is entitled Modem Testing. There you should find the information you need. All the best, /Chris 3Com Corp. >From usr-tc I've seen some hints in ARC documentation/release notes that say there's a way to connect to an HDM console through the ARC somehow (presumably over the packet bus)... but I can't find the exact syntax anywhere. This would save me a few serial ports... I'm also trying to figure out how to connect to a particular Quad (or DSP) to feed it AT commands. I have a channel on a Quad I suspect is dead and I'm trying to poke at it a bit to see if it's really dead... Someone want to point me at the relevant chunk of documentation? Maybe "search" in Acrobat just doesn't work well, but I'm having trouble finding it. (Call me blind.) Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

> > You don't need a console port for SDL - that's what the NMC is for :-) > > Unfortunately, the NMC can't talk to the card once it has erased its > flash memory and then aborted a download. I beg to differ... I have one quad here that's dicky. I had trouble getting the PRI to stop sending it calls, so I started a download, aborted, and left it in a non-operational state. A week or two later I wanted to try something, so I jumped into TCM and flashed away... > Normally, We do a save to NVRAM, Restore from Defaults, Restore fom > NVRAM after we upgrade any firmware. That's probably the problem - you're saving the old values, doing a reset, and then putting the old values over the top. In effect, you've done nothing. What we do is flash the card, reset to hardware flow control defaults, make any local changes, and save to NVRAM. Works for us. > I guess no one else is aware of having intermittent slow connections > due to faulty quads in their hubs. Personally, I find it a little > scary that a quad card can sit there in a such a state without any > indication of a problem..... Never seen it here in production. I've seen it once when I forgot to reset a card to factory defaults after an upgrade though. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> > I can still buy Cisco 2500's, that's older hardware technology than the > > NETServers by a generation or two. > > Cisco has EOL'd the 4000 and 4500's. There is no upgrade path. > What are owners of that technology to do? Keep their gear. Cisco still provide IOS for those boxes, and still actively support them (as far as I'm aware anyway). I'd be happy for 3COM to do the same. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

> Can you use a NIC on the back of the chassis on the digital quad modem? Yes. > That would be a useful NIC to keep around if it would work. Definitely. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

I just worked with her again and it turns out she had the wrong settings for the mail server. Once we fixed that, she appears to be working fine. Thanks for the help Krish and Jeff. I still haven't seen the GeoBook, other than on the web page, but I did talk with a techsupport person at Brother and the GeoBook is just a DOS machine with text-only web browsing. I wonder if it's just Minuet? Wayne Barber Coastal Telco Services

Is there a mailing list archive for this list? -Steve ---- "Knowing others is wisdom, knowing your self is Enlightenment." -- Lao-Tzu

"Behrens, William" wrote: > > I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting note > Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com > support the netserver? >From what I've read, 3Com does not have access to the code that runs on the netserver anylonger. Why this is, I have not seen posted other than the license ran out. Were they told it would cost some unrealistic number to relicense it, or are they just being cheap because now they have their own code? Bitching and moaning will not help if the owners of the code are unwilling to relicense it. What's the real story? -Ron GLISnet, Inc +1 810/939.9885

Yes the Netserver code was licensed from Livingston (lucent). 3com's position is the hardware in the netserver class NAS is legacy due to the release of the HARC class NAS. Therefore they will no longer support the NAS (in general) due to the inability to support the software and the release of the new HARC. Features that do not work as advertised will not be fixed. The standard reply is if you want "x" feature to work correctly then buy a HARC. That's basically a load of shit. Supporting a particular platform for its lifespan is a cost of doing business. If they (3com) had not been selling netserver class NAS's for a couple of years I could maybe see the support drying up, but they were selling this box (thru distributors) up in till the end of this last year. That's not the customers problem, again a cost of doing business. Fix the distributor pipeline (i.e. don't fill it with product you know you won't support). For the most part people are pissed off due to 3com's desire for its customers to pay for its poor business practices and lack of foresight. If you purchased an automobile with an engine that was manufactured by a 3rd party and 3 months later the OEM said "sorry we don't support your automobile anymore because the engine is old, but you can buy this NEW automobile to fix your problem" would you be pissed ? You bet your ass you would. You would get an attorney and have a heyday with the auto maker in question. There is an implied warranty. If you can prove the manufacturer was not doing business with you in good faith at the time of purchase then he would be held accountable for his actions in a court of law. These people who are "whining and moaning" have a legetament gripe. They feel they have been screwed. Buying a NAS is not like buying a computer or OS as an earlier poster had suggested. PC's don't cost 10K+ (at least not desktops). I am not whining as my Netserver's are working for me and I don't need the support for some of the software features, but this act buy 3com of not supporting there customers in a "good faith" manner has made me think of "fork lifting" my NAS's back to Lucent and PM4's. William Behrens >"Behrens, William" wrote: >> I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting note >> Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com >> support the netserver? >From what I've read, 3Com does not have access to the code that runs on the >netserver anylonger. Why this is, I have not seen posted other than the >license ran out. Were they told it would cost some unrealistic number to >relicense it, or are they just being cheap because now they have their own >code? >Bitching and moaning will not help if the owners of the code are unwilling >to relicense it. What's the real story? >-Ron >GLISnet, Inc >+1 810/939.9885

On Tue, 2 Mar 1999, Jeff Mcadams wrote: > Thus spake Lon R. Stockton, Jr. [snip] > >If I had bought the crap, I'd accept the fact > >that *I* screwed up. > > Whoa...and this is the crux of where you're bad analogy comes from. The > customer didn't screw up here. The dealer most definitely did! The > weed is definitely defective, even for weed from the projects. The > dealer's handling of the situation was appalling, and all I want is the > high that I originally paid for and *still* haven't gotten and the > dealer still seems to be making excuses for. Actually I think the analogy works... What Lon is saying is that 3com sales and marketing is about as honest and good-intentioned as your average street dealer. Street sense should tell you to go to Amsterdam and buy a nice PM4 or 5300 at the RAS bar there and stay away from the twitching street corner 3Com reps. And the 3Com drug of choice is most likely something dirty like inhaling Glade air freshener, not weed. I wonder when data over voice will appear in the US market? Around the same time as OSPF? Charles

Just wondering if everyone has heard about 3com's latest bundle. You can purchase the Double play bundle which is two DSP cards for 8,995.00 and also trade in 48 Quads for 2 extra DSP's for no extra money. The price above is from my vendor. I just thought this was a attractive offer and thought I would share it with everyone. Thanks Paul JR. Original Message ----- Sent: Tuesday, March 02, 1999 10:30 AM > > Yes the Netserver code was licensed from Livingston (lucent). 3com's >position is the hardware in the netserver class NAS is legacy due to the >release of the HARC class NAS. Therefore they will no longer support the NAS >(in general) due to the inability to support the software and the release of >the new HARC. Features that do not work as advertised will not be fixed. The >standard reply is if you want "x" feature to work correctly then buy a HARC. >That's basically a load of shit. > > Supporting a particular platform for its lifespan is a cost of doing >business. If they (3com) had not been selling netserver class NAS's for a >couple of years I could maybe see the support drying up, but they were >selling this box (thru distributors) up in till the end of this last year. >That's not the customers problem, again a cost of doing business. Fix the >distributor pipeline (i.e. don't fill it with product you know you won't >support). > > For the most part people are pissed off due to 3com's desire for its >customers to pay for its poor business practices and lack of foresight. If >you purchased an automobile with an engine that was manufactured by a 3rd >party and 3 months later the OEM said "sorry we don't support your >automobile anymore because the engine is old, but you can buy this NEW >automobile to fix your problem" would you be pissed ? You bet your ass you >would. You would get an attorney and have a heyday with the auto maker in >question. There is an implied warranty. If you can prove the manufacturer >was not doing business with you in good faith at the time of purchase then >he would be held accountable for his actions in a court of law. > > These people who are "whining and moaning" have a legetament gripe. >They feel they have been screwed. Buying a NAS is not like buying a computer >or OS as an earlier poster had suggested. PC's don't cost 10K+ (at least not >desktops). I am not whining as my Netserver's are working for me and I don't >need the support for some of the software features, but this act buy 3com of >not supporting there customers in a "good faith" manner has made me think of >"fork lifting" my NAS's back to Lucent and PM4's. > >William Behrens > >>"Behrens, William" wrote: > > >>> I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting note >>> Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com >>> support the netserver? > >>From what I've read, 3Com does not have access to the code that runs on the >>netserver anylonger. Why this is, I have not seen posted other than the >>license ran out. Were they told it would cost some unrealistic number to >>relicense it, or are they just being cheap because now they have their own >>code? > >>Bitching and moaning will not help if the owners of the code are unwilling >>to relicense it. What's the real story? > >>-Ron >>GLISnet, Inc >>+1 810/939.9885 > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Charles Sprickman >On Tue, 2 Mar 1999, Jeff Mcadams wrote: >> Thus spake Lon R. Stockton, Jr. >[snip] >> >If I had bought the crap, I'd accept the fact >> >that *I* screwed up. >> Whoa...and this is the crux of where you're bad analogy comes from. The >> customer didn't screw up here. The dealer most definitely did! The >> weed is definitely defective, even for weed from the projects. The >> dealer's handling of the situation was appalling, and all I want is the >> high that I originally paid for and *still* haven't gotten and the >> dealer still seems to be making excuses for. >Actually I think the analogy works... What Lon is saying is that 3com >sales and marketing is about as honest and good-intentioned as your >average street dealer. Marketing maybe...not sales...at least not my sales rep. I think its the higher ups that make decisions such as what is being discussed that is the problem, not the lower folks that actually go out and talk to the customers. >I wonder when data over voice will appear in the US market? Around the >same time as OSPF? That would be nice actually since OSPF is nearly here (no joking there) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I name 3Com as having 'the "most connectable" client and server modems' in the latest update to the Interoperability page.... New Pages & Recent updates at the 56k=v.Unreliable site http://808hi.com/56k/ [mirrored at http://808news.com/56k] What's a 56k-compatible line? - http://808hi.com/56k/56kline.htm V.90 Interoperability status - http://808hi.com/56k/x2-interop.htm Modems & Call Waiting - http://808hi.com/56k/callwait.htm RBS & 56k update - http://808hi.com/56k/rbs2.htm Inexpensive, Decent 56k modems - http://808hi.com/56k/buy56k.htm Useful Links - http://808hi.com/56k/links.htm How to Flashback 3Com/USR modems - http://808hi.com/56k/flashback.htm 56k TROUBLESHOOTING- http://808hi.com/56k/r-rnut-x2-3.htm Check Your Throughput - http://808hi.com/56k/x2-thru.htm Limiting Your Connect Speed - http://808hi.com/56k/x2-linklimit.htm Who Manufactured Your Modem? - http://808hi.com/56k/whomadeit.htm 3Com Diagnostic Screens - http://808hi.com/56k/diag3com.htm If you get 115.2k connects - http://808hi.com/56k/x2-inf1.htm LUCENT LT Winmodem / latest driver/firmware http://808hi.com/56k/x2-lucent.htm NEWS & UPDATES - http://808hi.com/56k/news.htm LATEST UPDATES - http://808hi.com/56k/latest.htm Why 56k=v.Unreliable - http://808hi.com/56k/why56kis.htm From the guestbook - http://808hi.com/56k/guestbook.htm "AWESOME site...." "Your page on limiting connection speed put me on the right track..." "When you are totally frustrated this is a great place to go see that you aren't alone!!!" "Excellent page. I am the administrator for a regional cable/dialup ISP and this is one of the most informative pages on 56k I have ever read. I have gleaned much more useful information from your pages in 30 minutes than I have ever received from 3Com (and that's having direct access to one of their SE's). Thanks!" Aloha, Richard

we are setting up platypus and i was looking for any info on the port numbers to put for both the older netserver and hiper arc chassis's matthew

Thus spake Paul Jr. >Just wondering if everyone has heard about 3com's latest bundle. You can >purchase the Double play bundle which is two DSP cards for 8,995.00 and also >trade in 48 Quads for 2 extra DSP's for no extra money. >The price above is from my vendor. Oh good...this is out now. :) This bundle was thought up in an effort to increase port densities directly as a result of our situation. The bundle was created in an effort to increase port density and thus require the purchasing of fewer HiPer Arcs to do the upgrade. Someone apparently didn't do their math though because this isn't even *close* to being cost effective to do this. This bundle is good if 1) you have Arc's running 48 or 96 ports of modems currently, then doing this would probably be cost effective by letting the Arc then run 144 ports thus giving you another 48 ports without having to buy another Arc; of if 2) you're just trying to increase port density for its own sake. This bundle is definitely *not* cost effective for trying to do the upgrade to HiPer Arcs from NETServers compared to just using the (now discontinued) 1 Arc + 1 DSP in exchange for a NETServer bundle. >I just thought this was a attractive offer and thought I would share it with >everyone. It is good if you're looking to increase the total number of ports you have, definitely. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Anybody know what this is? If so, where did you find it. I've searched all of the HARC and RADIUS server docs I can find, o no avail... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

Thanks to everyone who responded with the answer. Special thanks to those who told me where to find it. It turns out *not* to be in the HiPerARC reference manual or addendum that are in the Document Library area of the 3com website. It *is* in the harc41user.pdf version of the User's manual distributed with the HiPerARC code itself. Future thanks to the 3com webmaster who, I'm sure, will add this document to the Document Library ASAP... :-) Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

Bob Purdon wrote: > > > From what I've read, 3Com does not have access to the code that runs > > on the netserver anylonger. Why this is, I have not seen posted other > > than the license ran out. Were they told it would cost some > > unrealistic number to relicense it, or are they just being cheap > > because now they have their own code? > > What's stopping them porting their new code to the NETserver - just like > Cisco build the 2501 IOS from the same code base (I believe) as the higher > end routers? > > They can't be bothered? They won't sell as many of their shiny new Arc's? > I dunno... Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486 DX2/66, there may be performance issues on running the HARC code on the Netserver. How much RAM did the Netservers have, 8MB? Sometimes it's not easy to take something designed for one platform and move it to another. Do you want to pay Cisco prices for 3Com equipment? There is a reason why Cisco equipment in general costs 40% more than anyone elses. Do you commonly ask BMW to drop in a Volkswagen engine into your car because you already have the engine or to fix a stalling problem? -Ron GLISnet, Inc. +1 810/939.9885

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dave Martin |Sent: Tuesday, March 02, 1999 3:46 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) USR RADIUS attribute 38978 (x9842) | | |Anybody know what this is? If so, where did you find it. I've searched |all of the HARC and RADIUS server docs I can find, o no avail... USR_VSA Modem-Training-Time 0x9842 integer -M

I'm, trying to find out if there are any security issues I should be worrying about on my Hiper Access Router card. What is the latest system version (most stable?) -Steve ---- "Knowing others is wisdom, knowing your self is Enlightenment." -- Lao-Tzu

Dave, Attribute 0x9842 is a VSA and stands for Modem Training Time. It is the delay in seconds between the time when a call arrives and is actually connected. Details about it can be found in Hiper ARc user manual ( Appendix E). Regards Sanjay Agarwal On Tue, 2 Mar 1999, Dave Martin wrote: > Anybody know what this is? If so, where did you find it. I've searched > all of the HARC and RADIUS server docs I can find, o no avail... > > ------------------------------------------------------------------------ > Dave Martin Netcetera, Inc. dpm@netcetera.com > "Infinity Welcomes Careful Drivers" > ------------------------------------------------------------------------ > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

0x9842 is modem training time -- Matt Dave Martin <dpm@netcetera.com> on 03/02/99 03:46:25 PM Please respond to usr-tc@lists.xmission.com cc: (Matt Harper/MW/US/3Com) Anybody know what this is? If so, where did you find it. I've searched all of the HARC and RADIUS server docs I can find, o no avail... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers" - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Tue, 2 Mar 1999, Ronald E. Kushner wrote: > Bob Purdon wrote: > > > > > From what I've read, 3Com does not have access to the code that runs > > > on the netserver anylonger. Why this is, I have not seen posted other > > > than the license ran out. Were they told it would cost some > > > unrealistic number to relicense it, or are they just being cheap > > > because now they have their own code? > > > > What's stopping them porting their new code to the NETserver - just like > > Cisco build the 2501 IOS from the same code base (I believe) as the higher > > end routers? > > > > They can't be bothered? They won't sell as many of their shiny new Arc's? > > I dunno... > > Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486 > DX2/66, there may be performance issues on running the HARC code on the > Netserver. 486/100 I thought... but still, that's the best argument I've heard so far for not doing it. However... they HAVE ported it to the NETserver/8 and NETserver/16 line, and the USR Viper DSL. All of those run on 486's. They don't have to deal with a packet bus, however, or with more than 16 ports... maybe it doesn't scale up to 96 ports well. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

Modem-Training-Time 0x9842 integer this is a vsa krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Tue, 2 Mar 1999, Dave Martin wrote: > Anybody know what this is? If so, where did you find it. I've searched > all of the HARC and RADIUS server docs I can find, o no avail... > > ------------------------------------------------------------------------ > Dave Martin Netcetera, Inc. dpm@netcetera.com > "Infinity Welcomes Careful Drivers" > ------------------------------------------------------------------------ > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I am told by tech support here, that certain versions of DUN/Windows don't work with our equipment, and when they see this problem, they have the customer download DUN 1.3 and fix the problem. We are about to take on a customer base from an ISP we bought, of about 2500 customers. Tech support is worried that alot of these customers have older dialers and will not work. My question is, if the user has DUN 1.0, 1.2, 1.3, 95a, 95b, whatever, are their any issues known between native DUN/95 and 4.1.59-1? Is their a more stable arc code that I should be on as far as compatibility? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Thus spake Ronald E. Kushner >Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486 >DX2/66, there may be performance issues on running the HARC code on the >Netserver. Of course, none of this changes the whole core of the issue. That being that 3Com is trying to make me pay for hardware in order to get a software fix. >How much RAM did the Netservers have, 8MB? I think the earliest ones came with 4 MB, but could be easily (SIMM swap out) be upgraded to at least 16. Later ones came with at least 16 already on board. >Sometimes it's not easy to take something designed for one platform and move >it to another. Do you want to pay Cisco prices for 3Com equipment? There is >a reason why Cisco equipment in general costs 40% more than anyone elses. Heh...so you're saying that 3Com had a total lack of foresight basically. That's all I'm really saying...and that they're trying to make *me* pay because *they* screwed up. >Do you commonly ask BMW to drop in a Volkswagen engine into your car because >you already have the engine or to fix a stalling problem? No, but if BMW has to replace that engine with a new engine of their own to fix a stalling problem (particularly under warranty!) I would darn sure expect them to do that. Again...here's what it comes down to. I bought NETServers and want to get cross-chassis bundling working, and 3Com is telling me I have to buy new hardware to do that. You *CANNOT* argue that the NETServer hardware is incapable of handling cross-chassis bundling. Therefore, 3Com is guilty of Bait and Switch tactics here. I just don't see how it can be argued any other way. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Mike Andrews >On Tue, 2 Mar 1999, Ronald E. Kushner wrote: >> Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486 >> DX2/66, there may be performance issues on running the HARC code on the >> Netserver. >486/100 I thought... but still, that's the best argument I've heard so >far for not doing it. However... they HAVE ported it to the NETserver/8 >and NETserver/16 line, and the USR Viper DSL. All of those run on 486's. >They don't have to deal with a packet bus, however, or with more than 16 >ports... maybe it doesn't scale up to 96 ports well. Yeah, that's the best argument yet...but that's not saying much. The arguments put forth so far have been pathetic at best. Of course...when has something not scaling to its design criteria stopped 3Com from putting it out? They put out the NETServer to handle 96 ports and it didn't handle it. Besides...I don't need it to support 96 ports, I just need 48. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

"Ronald E. Kushner" <ron@glis.net> writes: > Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486 > DX2/66, there may be performance issues on running the HARC code on the > Netserver. Yeah, except that the first platform for this code base was the 486 based NETServer 16 product. There was a long thread on this a while back (should be in the archives) and let's just say there isn't any good technical reason not to support the NETServer with the same code base. But the business decision is behind us now. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

(Sorry if anyone gets annoyed by this, but I couldn't resist. The screwdriver really bugs me sometimes :) Is anyone else having trouble with their 3Com screwdriver? When I enable the flat-head attachment, I have a lot of trouble getting it to work. It keeps wanting to fall out off the handle. I don't understand it... I have an older USR screwdriver, and it works great. It also isn't compatable with all flat-head screws. I have a Dofasco 1/4" flat-head screw, and the damn screwdriver keeps slipping out of the groove, forcing me to reseat it. I can only get a couple of turns on it before it falls out of the groove. I don't expect Dofasco can do anything, since all they have to do is provide a groove for the screwdriver to fit in. But then, I have heard of others with this problem, so I wonder if maybe the flat-head-screwdriver standard needs more development. Either way, 3Com claims it works, and I expect it to perform as advertised. I called 3Com tech support on these matters, and they suggested I tighten the screw holding the attachment to the handle. I told them I've tightened it as far as it will go and it still won't stay on. After making sure I'm turning the screw the right way, and getting me to reseat it several times, he asks for the IP and SNMP community of the screwdriver. I try to explain to him that my screwdriver is not routed on the Internet, and he responds that he can't really help me until he can bring up the TCM on it. As far as the Dofacso interoperatability issue, he says that the screwdriver is pretty straight forward, and thus if I have picked the right attachment, it should work. Must be Dofasco's fault. I called Dofasco, and they thought it was absurd that it was suggested they were the source of the problem. After testing with another screwdriver (a one-piece unit), I didn't have as much trouble as before. I'm pretty fed up. It's really tempting to go up to a nice Snap-On, but they're really pricey. But I think I'll stick it out a bit longer. There might be an engineering release.

On Tue, 2 Mar 1999, Mark Starr wrote: > Hello, > What is/does the setting for T1 Tone Type (S47.1) in the call control > options for the modems of > a hiper card do? The two choices are mfTones and dtmfTones? When you provision a T1, it has a tone type, this can either be dtmf or mf. Brian > Thanks, > Mark > > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

Thus spake Bob Purdon >> but still, that's the best argument I've heard so far for not doing >> it. >Didn't they state originally that they were going to do it? Yes. >> However... they HAVE ported it to the NETserver/8 and NETserver/16 >> line, and the USR Viper DSL. All of those run on 486's. They don't >> have to deal with a packet bus, however, or with more than 16 ports... >I don't know how the packet bus is designed, but I'd have expected it tp >be pretty efficient, having being purpose designed. Perhaps more >efficient that normal serial comms... Well, being a packet bus...you can basically think of it as a very high speed ethernet. Ethernet is a packet bus type of technology really...at least in concept. I can't imagine that it would cause much load on the NETServer at all...I would assume (maybe I should learn better than to assume with 3Com) that the pbus interface is done almost completely in hardware, as it would really be a waste to do it completely in software. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hello, What is/does the setting for T1 Tone Type (S47.1) in the call control options for the modems of a hiper card do? The two choices are mfTones and dtmfTones? Thanks, Mark To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Tue, 2 Mar 1999, Mark Starr wrote: > > > Hello, > > What is/does the setting for T1 Tone Type (S47.1) in the call control > > options for the modems of > > a hiper card do? The two choices are mfTones and dtmfTones? > > When you provision a T1, it has a tone type, this can either be dtmf or > mf. > > Brian > > I'm using PRI lines from Ameritech for this. Any idea on which they might be? Mark

"Mark Starr" <squid@greenapple.com> writes: > I'm using PRI lines from Ameritech for this. Any idea on which they might > be? Not applicable. The tone type configuration is used for channelized T1 circuits (ground start, loop start, E&M) for which the transmission of information such as DNIS arrives in-band over the same DS0 as the call, in advance of the start of the actual call data. In such a case, information is transmitted via one of the two types of tones. For a PRI span, ISDN signaling is used over the D channel (common channel or out of band) independent of the actual call path, and the information is not transmitted via tones on the call path itself. So for that configuration, the parameter is ignored. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

> From what I've read, 3Com does not have access to the code that runs > on the netserver anylonger. Why this is, I have not seen posted other > than the license ran out. Were they told it would cost some > unrealistic number to relicense it, or are they just being cheap > because now they have their own code? What's stopping them porting their new code to the NETserver - just like Cisco build the 2501 IOS from the same code base (I believe) as the higher end routers? They can't be bothered? They won't sell as many of their shiny new Arc's? I dunno... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

This is a multi-part message in MIME format. ------=_NextPart_000_0003_01BE6553.0CE24940 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > Attribute 0x9842 is a VSA and stands for Modem Training Time. It is the > delay in seconds between the time when a call arrives and is actually > connected. > > Details about it can be found in Hiper ARc user manual ( Appendix E). Is there any support for this on the NETserver? It would be very useful for some Radius accounting work I'm doing at the moment. thanks, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/ ------=_NextPart_000_0003_01BE6553.0CE24940 Content-Type: text/x-vcard; name="Ray Bellis.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Ray Bellis.vcf" BEGIN:VCARD VERSION:2.1 N:Bellis;Ray;; FN:Ray Bellis ORG:Oxford CommUnity Internet plc; TITLE:Technical Director TEL;WORK;VOICE:+44 (1865) 856000 TEL;WORK;FAX:+44 (1865) 856001 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Windsor House=3D0D=3D0A12 High = Street;Kidlington;Oxfordshire;OX5 2PJ;United Ki=3D ngdom LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Windsor House=3D0D=3D0A12 High = Street=3D0D=3D0AKidlington, Oxfordshire OX5 2PJ=3D0D=3D =3D0AUnited Kingdom URL: URL:http://www.community.co.uk/ EMAIL;PREF;INTERNET:rpb@community.net.uk EMAIL;INTERNET:rpb@community.net.uk EMAIL;INTERNET:rpb@community.co.uk REV:19990205T105103Z END:VCARD ------=_NextPart_000_0003_01BE6553.0CE24940--

Upgraded to this code 2 weeks ago and except for one problem it seems to work rather well for us. The problem is that we are hearing an increasing amount of complaints about sudden and unwanted disconnects. I don't have more info than that right now but I've started to. In the mean time anyone else had this problem? If so, any quick ways to fix this aside from going back to 1.2.68 which had its' own set of problems. These DSP's are running channelized T1, not PRI Terry Kennedy Olypen, Inc.

> 486/100 I thought... Ours are 486/100, with 20mb RAM. > but still, that's the best argument I've heard so far for not doing > it. Didn't they state originally that they were going to do it? > However... they HAVE ported it to the NETserver/8 and NETserver/16 > line, and the USR Viper DSL. All of those run on 486's. They don't > have to deal with a packet bus, however, or with more than 16 ports... I don't know how the packet bus is designed, but I'd have expected it tp be pretty efficient, having being purpose designed. Perhaps more efficient that normal serial comms... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Mike, Thanks for the reply--- But, I feel stupid -- How do you do that ? I have looked at the line data compression which are set to autoenable, but cannot find V.42bis any where. What am I missing? I thought that it would be in the signal converter options but I can't find it there either. I found v.42 in the call control options but only for 12- 24 and 9600, also no bis, just v.42- Modem error control settings maybe - v.42/mnp (v.42 disableV.42enablemnp)? -----Original Message----- >Turn v.42bis compression off on your DSPs -- that cured it for us. > >I still haven't heard a definitive answer as to whether there's really a >v.42bis bug in the latest DSP code. It sure seems like there is. Even >Couriers get dropped spontaneously with it turned on... > > >Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY >mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me >getting beaten by the police, put down the video camera and come help me!" > >On Wed, 3 Mar 1999, Terry Kennedy wrote: > >> Upgraded to this code 2 weeks ago and except for one problem >> it seems to work rather well for us. The problem is that we are >> hearing an increasing amount of complaints about sudden and >> unwanted disconnects. I don't have more info than that right now >> but I've started to. In the mean time anyone else had this problem? >> If so, any quick ways to fix this aside from going back to 1.2.68 which >> had its' own set of problems. These DSP's are running channelized >> T1, not PRI >> >> Terry Kennedy >> Olypen, 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. >

I checked the info on the list and found no mention of any problem posting items for sale on this list. I'm sure I'll be corrected if I'm wrong and I apologize in advance if that's the case but here goes. I noticed a couple people posting requesting to buy DSP cards. I have a number of 3465 Double ups available for $8335 US delivered. Single cards are $4200 each. These are brand new, full warranty, from a certified 3COM (USRobotics) VAR. We want to move these quickly so we will beat any quote for new cards by 5%. I also have a number or ARC Cards for $2000 each. Custom configs are also no problem, AC, DC, 70, 130 AMP, 1 or 2 ARC's 1-14 DSP's, edgeserver, any combination. As for my offer for free support, I have a number of Total Control trained engineers on staff, including myself, and I offer free technical support to Dynavar customers and even Non-Dynavar customers to show that we can add value to you future purchases. We also have a full lab setup here with spares galore if anyone ever needs urgent replacement. We also offer on-site training, we just completed 2 courses each for a customer (18 students) Installation and Management, and HiPer ARC at less than 1/2 3COM's on-site cost, and within 4 weeks of request. Let me know if there is anything I can do for you. Regards, Greg Gregory F. Genge, President, Dynavar Networking, Inc. Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, 5005 Fax, http://www.dynavar.com #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible, Microcom (Compaq), Garrett, Sonic, Cobalt.

What is the latest version of TCM, and can someone tell me where I can get it? -Steve ---- "Knowing others is wisdom, knowing your self is Enlightenment." -- Lao-Tzu

Turn v.42bis compression off on your DSPs -- that cured it for us. I still haven't heard a definitive answer as to whether there's really a v.42bis bug in the latest DSP code. It sure seems like there is. Even Couriers get dropped spontaneously with it turned on... Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!" On Wed, 3 Mar 1999, Terry Kennedy wrote: > Upgraded to this code 2 weeks ago and except for one problem > it seems to work rather well for us. The problem is that we are > hearing an increasing amount of complaints about sudden and > unwanted disconnects. I don't have more info than that right now > but I've started to. In the mean time anyone else had this problem? > If so, any quick ways to fix this aside from going back to 1.2.68 which > had its' own set of problems. These DSP's are running channelized > T1, not PRI > > Terry Kennedy > Olypen, 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. >

At 01:08 PM 3/3/99 -0500, Mike Andrews <mandrews@termfrost.org> wrote: >Turn v.42bis compression off on your DSPs -- that cured it for us. How will this affect other users that aren't experiencing random drops, etc? >I still haven't heard a definitive answer as to whether there's really a >v.42bis bug in the latest DSP code. It sure seems like there is. Even >Couriers get dropped spontaneously with it turned on... Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Hi, I just finished a little perl script to poll all of our chassis. It checks whether all cards are installed, whether all interfaces are up/available, power supply status, environ. status, modem availability, and error count on the T1 lines. I just don't trust traps, so I poke the chassis instead to see that these values are OK. After I clean it up a bit (I'm very new to perl) I'd like to post/share it for comments and improvements. I'd also like to get some feedback on what else I can monitor. I'm pretty happy with what I have so far, as I think I could catch most problems before any customers might notice, but I'm sure there's more to look at. One thing I know I'm missing is the ability to catch a modem that is having difficulties connecting (basically I'd like to count connections/hour and warn if it's high), but I'm not sure how to go about that until we finish installing Radiator and start db logging of calls. Any ideas (David??) Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

If you're using TCM, highlight all your modems, go to Configure, then Programmed Settings, and it's under "Data Compression Settings" (not signal convertor or anything else)-- in fact it's the only setting in that category. Change from "autoenable" to "none". Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!" On Wed, 3 Mar 1999, Terry Kennedy wrote: > Mike, > > Thanks for the reply--- > > But, I feel stupid -- How do you do that ? I have looked at the line data > compression > which are set to autoenable, but cannot find V.42bis any where. What am I > missing? > I thought that it would be in the signal converter options but I can't find > it there either. > I found v.42 in the call control options but only for 12- 24 and 9600, also > no bis, just > v.42- Modem error control settings maybe - v.42/mnp (v.42 > disableV.42enablemnp)? > -----Original Message----- > From: Mike Andrews <mandrews@termfrost.org> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, March 03, 1999 10:17 AM > Subject: Re: (usr-tc) 1.2.59-1 > > > >Turn v.42bis compression off on your DSPs -- that cured it for us. > > > >I still haven't heard a definitive answer as to whether there's really a > >v.42bis bug in the latest DSP code. It sure seems like there is. Even > >Couriers get dropped spontaneously with it turned on... > > > > > >Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY > >mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me > >getting beaten by the police, put down the video camera and come help me!" > > > >On Wed, 3 Mar 1999, Terry Kennedy wrote: > > > >> Upgraded to this code 2 weeks ago and except for one problem > >> it seems to work rather well for us. The problem is that we are > >> hearing an increasing amount of complaints about sudden and > >> unwanted disconnects. I don't have more info than that right now > >> but I've started to. In the mean time anyone else had this problem? > >> If so, any quick ways to fix this aside from going back to 1.2.68 which > >> had its' own set of problems. These DSP's are running channelized > >> T1, not PRI > >> > >> Terry Kennedy > >> Olypen, 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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

1) What setting do you use in TCM to disable v.42bis compression? 2) Will this cause any other problems? 3) If it doesn't work well, shouldn't 3COM disable it in the default settings? 4) Is there a searchable archive of this list? Thanks, Jim K Mitchell wrote: > > At 01:08 PM 3/3/99 -0500, Mike Andrews <mandrews@termfrost.org> wrote: > >Turn v.42bis compression off on your DSPs -- that cured it for us. > > How will this affect other users that aren't experiencing random drops, etc? > > >I still haven't heard a definitive answer as to whether there's really a > >v.42bis bug in the latest DSP code. It sure seems like there is. Even > >Couriers get dropped spontaneously with it turned on... > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

On Wed, 3 Mar 1999, Jim Johnson wrote: > 1) What setting do you use in TCM to disable v.42bis compression? See previous posting; it's under data compression options... > 2) Will this cause any other problems? Slows down transfer of stuff that compresses well (text), but otherwise no impact. > 3) If it doesn't work well, shouldn't 3COM disable it in the default > settings? It seemed to work in previous versions, and still works great on Quads. > 4) Is there a searchable archive of this list? http://usr-tc.datasys.net/

Mike Andrews wrote: > > If you're using TCM, highlight all your modems, go to Configure, then > Programmed Settings, and it's under "Data Compression Settings" (not > signal convertor or anything else)-- in fact it's the only setting in that > category. Change from "autoenable" to "none". > That is the improper way to turn off V.42bis. When you reboot the card it will come back on even if you save the settings to NVRAM. You have to go into the HiPer ARC, type this in: SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0 SAVE ALL Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards after they load their NVRAM settings. -Ron GLISnet, Inc. +1 810/939.9885

On Wed, 3 Mar 1999, Ronald E. Kushner wrote: > Mike Andrews wrote: > > > > If you're using TCM, highlight all your modems, go to Configure, then > > Programmed Settings, and it's under "Data Compression Settings" (not > > signal convertor or anything else)-- in fact it's the only setting in that > > category. Change from "autoenable" to "none". > > > > That is the improper way to turn off V.42bis. When you reboot the card it > will come back on even if you save the settings to NVRAM. > > You have to go into the HiPer ARC, type this in: > > SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0 > SAVE ALL > > Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards > after they load their NVRAM settings. You've gotta be kidding me... where's that documented? The default string is just ATS0X0... how does that turn v.42bis on? If that's not it, what's the mechanism for doing it? I don't like things that go and spontaneously change my modem settings behind my back from what I've set 'em all to... Besides, doing it that way would turn it off on all the Quads I have (I have some racks with both quads and dsp's), and v.42bis compression works fine on the Quads and I'd rather not turn it off. (In fact I'd rather not have to turn it off on ANYTHING, but there seems to be a major bug here even though nobody has acknowledged it...) Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

On Wed, 3 Mar 1999, Steve Lynn wrote: > mdmEvInConnAttemptFails > .1.3.6.1.4.1.429.1.6.10.1.1.24 > The number of times the modem has reported a inbound connect > attempt failure event. This does not include those connect attempt > failues that are reported due to no dial time and no loop current. This is interesting... I'm looking at a chassis that includes quads and DSPs, and the DSPs are reporting at least double the number of failures. Quads are averaging about 18, while the DSPs are averaging about 58... > And to catch the incoming call attempts that do not make it to > the modem you may want to use this one. > > usrinCallmodemNotAvail > .1.3.6.1.4.1.429.1.27.2.1.10 Thanks very much, this is great stuff. I'm still a bit new to snmp, but it never ceases to amaze me. Next is PHP with the snmp module for some "on-demand" stats/usernames/whatever. Keep 'em comin, Charles > Incremented every time an incoming call can not be completed due > to no idle modem available. > > > -Steve > > > Charles Sprickman wrote: > > > Hi, > > > > I just finished a little perl script to poll all of our chassis. It > > checks whether all cards are installed, whether all interfaces are > > up/available, power supply status, environ. status, modem availability, > > and error count on the T1 lines. I just don't trust traps, so I poke the > > chassis instead to see that these values are OK. > > > > After I clean it up a bit (I'm very new to perl) I'd like to post/share it > > for comments and improvements. I'd also like to get some feedback on what > > else I can monitor. I'm pretty happy with what I have so far, as I think > > I could catch most problems before any customers might notice, but I'm > > sure there's more to look at. > > > > One thing I know I'm missing is the ability to catch a modem that is > > having difficulties connecting (basically I'd like to count > > connections/hour and warn if it's high), but I'm not sure how to go about > > that until we finish installing Radiator and start db logging of calls. > > > > Any ideas (David??) > > > > 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. >

On Wed, 3 Mar 1999, Ronald E. Kushner wrote: > > > Mike Andrews wrote: > > > > If you're using TCM, highlight all your modems, go to Configure, then > > Programmed Settings, and it's under "Data Compression Settings" (not > > signal convertor or anything else)-- in fact it's the only setting in that > > category. Change from "autoenable" to "none". > > > > That is the improper way to turn off V.42bis. When you reboot the card it > will come back on even if you save the settings to NVRAM. > > You have to go into the HiPer ARC, type this in: > > SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0 > SAVE ALL hmm, so your saying that the hiper arc has a script it runs AFTER the modems are init'ed, and sets things up on the modems? How do we list all that this script does? > > Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards > after they load their NVRAM settings. > > -Ron > GLISnet, Inc. > +1 810/939.9885 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

That was real cute. :o) Thanks Paul JR. AlaWeb Network Admin. 1800-427-8896 http://www.alaweb.com/support.html ----- Original Message ----- Sent: Tuesday, March 02, 1999 3:51 PM > >(Sorry if anyone gets annoyed by this, but I couldn't resist. > The screwdriver really bugs me sometimes :) > > >Is anyone else having trouble with their 3Com screwdriver? > >When I enable the flat-head attachment, I have a lot of trouble >getting it to work. It keeps wanting to fall out off the handle. >I don't understand it... I have an older USR screwdriver, and it >works great. > >It also isn't compatable with all flat-head screws. I have a >Dofasco 1/4" flat-head screw, and the damn screwdriver keeps slipping >out of the groove, forcing me to reseat it. I can only get a couple >of turns on it before it falls out of the groove. I don't expect >Dofasco can do anything, since all they have to do is provide a >groove for the screwdriver to fit in. But then, I have heard of others >with this problem, so I wonder if maybe the flat-head-screwdriver >standard needs more development. Either way, 3Com claims it works, >and I expect it to perform as advertised. > >I called 3Com tech support on these matters, and they suggested >I tighten the screw holding the attachment to the handle. I told >them I've tightened it as far as it will go and it still won't stay >on. After making sure I'm turning the screw the right way, and >getting me to reseat it several times, he asks for the IP and SNMP >community of the screwdriver. I try to explain to him that my screwdriver >is not routed on the Internet, and he responds that he can't really help >me until he can bring up the TCM on it. > >As far as the Dofacso interoperatability issue, he says that the >screwdriver is pretty straight forward, and thus if I have picked the >right attachment, it should work. Must be Dofasco's fault. > >I called Dofasco, and they thought it was absurd that it was suggested >they were the source of the problem. After testing with another >screwdriver (a one-piece unit), I didn't have as much trouble as before. > >I'm pretty fed up. It's really tempting to go up to a nice >Snap-On, but they're really pricey. But I think I'll stick it out a >bit longer. There might be an engineering release. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Has attempts to make an MPIP server under UNIX that will support the ARC's abandoned or is their still work in this area? I think it would be real nice to have an mpipd for UNIX, rather than running it off an ARC. brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Carl Ansley |Sent: Tuesday, March 02, 1999 10:05 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Acct-Session-Time problem | | | |Hi, | |We've just moved from Netserver to HARC, so apologies in advance for a |potentially newbie question. We're seeing some strange Acct-Session-Times |being reported every now and then with radius stop packets (~1 out of |every thousand). It's a bit of a worry because we do time accounting |(i.e. charge users) based on this information. We're running 4.1.11. | ^^^^^^^^^^^^^^^^^^^^^ This is your problem. Get the 4.1.59-1 code from Totalservice. Both issues were resolved a while back.

Mike Andrews wrote: > > On Wed, 3 Mar 1999, Ronald E. Kushner wrote: > > > Mike Andrews wrote: > > > > > > If you're using TCM, highlight all your modems, go to Configure, then > > > Programmed Settings, and it's under "Data Compression Settings" (not > > > signal convertor or anything else)-- in fact it's the only setting in that > > > category. Change from "autoenable" to "none". > > > > > > > That is the improper way to turn off V.42bis. When you reboot the card it > > will come back on even if you save the settings to NVRAM. > > > > You have to go into the HiPer ARC, type this in: > > > > SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0 > > SAVE ALL > > > > Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards > > after they load their NVRAM settings. > > You've gotta be kidding me... where's that documented? The default string > is just ATS0X0... how does that turn v.42bis on? If that's not it, what's > the mechanism for doing it? I don't like things that go and spontaneously > change my modem settings behind my back from what I've set 'em all to... > > Besides, doing it that way would turn it off on all the Quads I have (I > have some racks with both quads and dsp's), and v.42bis compression works > fine on the Quads and I'd rather not turn it off. (In fact I'd rather not > have to turn it off on ANYTHING, but there seems to be a major bug here > even though nobody has acknowledged it...) V.42bis does not work fine on the Quads. It's generally the client modems that are all screwed up, alot of Rockwell modems that date as far back as V.32bis will disconnect at unknown times when talking V.42bis to the Quads. I have disabled V.42bis, as far back as 1991 when we first started seeing those rockwell junk modems in the market with buggy V.42bis code. Anyways, this ATS0=0&K0 not documented anywhere I could find. But after snooping around and making a few calls to 3Com I come to find out the HiPer ARC sends an init string to the modems when the modem card after it registers with the HARC. This init string is: ATH0S0=0S72.0=1E0Q0V0&A0&K1&L0&N0&TX0S47.5=1S2=255 Well, guess what &K1 does.... You're better off turning off V.42bis and turning on Microsoft Compression anyways. Microsoft compression has a much higher compression ratio than V.42bis. If you're running both MS and V.42bis, V.42bis is just wasting processing time to determine it can not be compressed again - this might slightly increase throughput or reduce lag. -Ron GLISnet, Inc. +1 810/939.9885

Thus spake Ronald E. Kushner >You're better off turning off V.42bis and turning on Microsoft Compression >anyways. Microsoft compression has a much higher compression ratio than >V.42bis. If you're running both MS and V.42bis, V.42bis is just wasting >processing time to determine it can not be compressed again - this might >slightly increase throughput or reduce lag. I would disagree with this statement, at least in part. Software Compression (CCP) has benefits as does v.42bis modem compression...they are not mutually exclusive, and each provides benefits and drawbacks different from the other. The main drawback of CCP is that its done by and large in software. v.42bis is done in hardware in the modem. CCP can bring an access server to its knees potentially...the NETServer I believe will only run CCP on about 12 or so lines...any further lines beyond that, the NETServer will reject CCP on to prevent overloading the processor (at least I've been told that in the past). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hi, We've just moved from Netserver to HARC, so apologies in advance for a potentially newbie question. We're seeing some strange Acct-Session-Times being reported every now and then with radius stop packets (~1 out of every thousand). It's a bit of a worry because we do time accounting (i.e. charge users) based on this information. We're running 4.1.11. example: 02/03/1999:13:02:08 User-Name = "joebloggs" NAS-IP-Address = x.x.x.x Acct-Status-Type = Stop Acct-Session-Id = "17558" Acct-Delay-Time = 0 Acct-Authentic = RADIUS Service-Type = Framed-User NAS-Port-Type = ISDN NAS-Port-Id = 1 Calling-Station-Id = "" Called-Station-Id = "0330" Framed-Protocol = PPP Framed-IP-Address = x.x.x.x Acct-Session-Time = -85082 <---- Acct-Terminate-Cause = User-Request Acct-Input-Octets = 22409 Acct-Output-Octets = 243560 Acct-Input-Packets = 1038 Acct-Output-Packets = 796 We see this on both ISDN and analogue calls. Is this a bug/feature anyone else has seen? btw another strange thing is that NAS-Port-Id is always reported as 1 on accounting packets for dialin users, but is ok on authentication packets. Probably some configuration thing, but damned if i can work out what. -- Carl Ansley (carl@caverock.com) Phone: +64 3 3664242 Cave Rock Software / Cave Rock Internet Fax: +64 3 3665478 Unit 1a, 492 Moorhouse Ave, PO Box 22488, Christchurch, New Zealand

On Tue, 2 Mar 1999, Carl Litt wrote: > Is anyone else having trouble with their 3Com screwdriver? > > When I enable the flat-head attachment, I have a lot of trouble > getting it to work. It keeps wanting to fall out off the handle. I tried calling tech support about it, but I couldn't find the thing's serial number and they refused to assist. Do you have this problem with all of the attachments, or just one? If it's all of them, I'd suspect clamp on the body...wrap with cloth and give a good squeeze with a pair of pliers to close it up a little. If it's just one, try wrapping a piece of electrical tape around the mating surface of the attachment...stretching tape as necessary to get the appropriate thickness. Of course, IANAH (I am not a handyman), so be sure to consult with one before doing any of this. > It also isn't compatable with all flat-head screws. Ensure that you are using the appropriate flat-head attachment, as there are many standards and defacto standards and even downright non-standards in the industry. Other than that, you can either wait until the Open Screwdriver Proposed Format (OSPF) is supported, or go with another vendor. Interestingly, there do exist 3rd party attachments which will properly work with the 3com screwdriver handle; perchance you have some laying around? > I can only get a couple > of turns on it before it falls out of the groove. Not to offend, but for completeness it should be stated that the above symptom could also be caused by excessive blood-alcohol content of the operator. Contact your Human Resources department to see if they have any programs which can assist. Also, if the spouse of the operator reports a similar-sounding problem, it could indicate a more pervasive situation within the operator (him|her)self. In either case, the screwdriver is not at fault. > I'm pretty fed up. It's really tempting to go up to a nice > Snap-On, but they're really pricey. Personally, I'm a fan of Sears Craftsman. In the case of screwdrivers, when the time comes that you must use it for a chisel and then find out why you shouldn't, you can always take it back and tell 'em that you're not satisfied and they'll give you another one. And if I catch the guy in the hardware department on a slow night, he'll tell me all I ever wanted to know about screwdrivers and how to use 'em... FOR FREE! Lon Stockton MoonStar

This variable is a good indicator of faulty modems. It gives a count of incoming connect fails since last reboot. mdmEvInConnAttemptFails .1.3.6.1.4.1.429.1.6.10.1.1.24 The number of times the modem has reported a inbound connect attempt failure event. This does not include those connect attempt failues that are reported due to no dial time and no loop current. And to catch the incoming call attempts that do not make it to the modem you may want to use this one. usrinCallmodemNotAvail .1.3.6.1.4.1.429.1.27.2.1.10 Incremented every time an incoming call can not be completed due to no idle modem available. -Steve Charles Sprickman wrote: > Hi, > > I just finished a little perl script to poll all of our chassis. It > checks whether all cards are installed, whether all interfaces are > up/available, power supply status, environ. status, modem availability, > and error count on the T1 lines. I just don't trust traps, so I poke the > chassis instead to see that these values are OK. > > After I clean it up a bit (I'm very new to perl) I'd like to post/share it > for comments and improvements. I'd also like to get some feedback on what > else I can monitor. I'm pretty happy with what I have so far, as I think > I could catch most problems before any customers might notice, but I'm > sure there's more to look at. > > One thing I know I'm missing is the ability to catch a modem that is > having difficulties connecting (basically I'd like to count > connections/hour and warn if it's high), but I'm not sure how to go about > that until we finish installing Radiator and start db logging of calls. > > Any ideas (David??) > > 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.

I really like the performance monitor in TCM. It displays a plethora of information about modem performance and analog statistics. That information probably would help me in tech support if I knew what half of it meant. Is there a guide or reasonable explanation of what the information displayed there means and how it can be used to troubleshoot modem issues? The information I most interested in is the Call and Analog Statistics and how to best use them to trouble shoot modem connections. Just a simple listing of what each of the headings means, normal values, abnormal, etc. would be quite helpful. I know some of these are listed in the help section but the information given is quite sparse. Thanks. Walt Walter N. Gnann ISLC, Manager 843.770.1000 843.770.1002 (fax) wgnann@islc.net http://www.islc.net http://www.beaufortonline.com http://www.beaufortcomputerclub.org

Ever since I've setup MPIP, my Netserver control server sends a [MPIP_SERVER_PING_REQ] message to syslogd. I don't see any attempt to establish a bundle service, so it is probably something I'm missing for the configuration. My Netserver cards have version 3.8.1. I've setup the control server with three clients ( including itself ). Any ideas what this could be? Thanks. | Cassandra M. Perkins | People usually get what's coming to | | Network Operations | them... unless it's been mailed. | | The Loop Internet Switch Co., LLC | -fortune |

On Wed, 3 Mar 1999, Ronald E. Kushner wrote: > > > That is the improper way to turn off V.42bis. When you reboot the card it > > > will come back on even if you save the settings to NVRAM. > > > > > > You have to go into the HiPer ARC, type this in: > > > > > > SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0 > > > SAVE ALL > > > > > > Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards > > > after they load their NVRAM settings. > > > > You've gotta be kidding me... where's that documented? The default string > > is just ATS0X0... how does that turn v.42bis on? If that's not it, what's > > the mechanism for doing it? I don't like things that go and spontaneously > > change my modem settings behind my back from what I've set 'em all to... > > > > Besides, doing it that way would turn it off on all the Quads I have (I > > have some racks with both quads and dsp's), and v.42bis compression works > > fine on the Quads and I'd rather not turn it off. (In fact I'd rather not > > have to turn it off on ANYTHING, but there seems to be a major bug here > > even though nobody has acknowledged it...) > > V.42bis does not work fine on the Quads. It's generally the client modems > that are all screwed up, alot of Rockwell modems that date as far back as > V.32bis will disconnect at unknown times when talking V.42bis to the Quads. > I have disabled V.42bis, as far back as 1991 when we first started seeing > those rockwell junk modems in the market with buggy V.42bis code. > > Anyways, this ATS0=0&K0 not documented anywhere I could find. But after > snooping around and making a few calls to 3Com I come to find out the HiPer > ARC sends an init string to the modems when the modem card after it > registers with the HARC. This init string is: > > ATH0S0=0S72.0=1E0Q0V0&A0&K1&L0&N0&TX0S47.5=1S2=255 I would *love* to know where you found this string...! I'm using a homebrew Perl script for checking modem settings (and chassis settings for that matter) -- it essentially snmpwalks the whole NMC and compares what it gets to a list of expected settings, and fixes (snmpset) anything it finds out of whack. Modem settings, DSP profiles, Dual PRI settings, whatever... Anyway, that string above explains a LOT of the weird things I've been seeing with this utility -- values spontaneously changing themselves on DSP's and such. Looks like the values that were changing are the *exact* ones set by that init string above. (Well, and some trap settings that still refuse to stick... but that's another story) Knowing this sure would have saved me a lot of grief. This string gets sent to the modem before the init_string does, then? So where do they bury this string at, can you edit it, and why don't they document it? :) I realize that v.42bis is badly broken on a lot of client modems, especially old Rockwells, and even some Sportsters... still, the DSP's running 1.2.60 and 1.2.59 hang up on modems that are known to not be buggy. (Unless Couriers are buggy and it's just coincidence that I've kept Couriers connected at v.34 for over a month straight before...?) Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

> >Y'know, I was thinking > >that you could rig another telephone number to point to the head > >of your hunt group. Then, you could rig your HDSP modem to configure > >itself differently based on the called number. Easy enough so far, > >right? The twist is that one of the configurations is an extremely > >optimized configuration, so that people with the newest code and > >the fancy modems can feel the power. The other config is one that > >has all the fancy stuff off...like the compression that freaks out > >all the winmodems and the like...a work-with-anything config. Then > >you just put it in your setup info....'if you have trouble accessing > >with the first number, try with the second yaddayadda'. I haven't > >tried this yet, but it is apparently simple enough on the surface. > >WDYT?] > > Hrmm...interesting thought...I know the Arc can "authenticate" based on > DNIS, so it could change the behavior of the port that way, though that > doesn't take care of modem connect problems because the modems have > already connected, or failed to connect by the time the Arc sees the > DNIS I believe. I'm unaware of any way to have the modem on the DSP > reconfigure on the fly based on DNIS at this point, though I'm not > extremely knowledgeable about them yet. That would be pretty cool to > do, but I think it would require some changes in the DSP's to do it (I > would be happy to learn that I'm wrong). I still haven't done it, but have looked around a little based on this and another recent thread about how the inits work. The thing I'm talking about is evidently configured on the 'DNIS Access Codes' in the HDSP templates (in TCM, select the hdsp card, then hit configure button, then pull up DNIS Access Codes....then look at help for the items). Apparently, you can actually have up to four different ones. This init would be issued to the modem prior to it accepting the call (but of course after the call hits the span). If everything works as advertised *grin*, my aforementioned idea is apparently trivial. Regarding the other thread here about init strings, the HARC does indeed issue an init string to the modems after each call...perchance this is y'all's problem. Suggestion from an old bbser: Standard procedure...put your highly researched configuration in your modem. Flash the modem's config in a stored profile, and make sure that you've set the modem to revert to stored profile when it gets an ATZ. Then set the HARC to issue a simple ATZ at the end of each call, and rid yourself of the headache of having to remember to change modem inits in HARC too. I found the configuration of HARC's modem init string and the documentation of same in a supiciously obvious place given the amount surprise everyone is showing in finding out that it exists. In HARM, click on the modem configuration tool (that's the one with a picture of a modem as an icon, and it's the first thing the window displays. Lon Stockton MoonStar

Thus spake Cassandra M. Perkins >Ever since I've setup MPIP, my Netserver control server sends a >[MPIP_SERVER_PING_REQ] message to syslogd. I don't see any attempt to >establish a bundle service, so it is probably something I'm missing for >the configuration. My Netserver cards have version 3.8.1. I've setup the >control server with three clients ( including itself ). Any ideas what >this could be? This is just the mechanism that MPIP servers use to confirm that other MPIP servers and MPIP clients are still alive. It sends these out periodically just to make sure everything is still up and running...nothing to be concerned about. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

> Is anyone else having trouble with their 3Com screwdriver? > > When I enable the flat-head attachment, I have a lot of trouble > getting it to work. It keeps wanting to fall out off the handle. > I don't understand it... I have an older USR screwdriver, and it > works great. Unfortunately 3COM no longer have access to the design for this model screwdriver, so they are unable to fix it. They have a new HiperDriver though, and for only $9995 (upgrade bundle, includes new chassis), you too can have one. I'll bet they told you that you could reliably unscrew screws with the one you've got, but as you've found, it doesn't work right. Oh, btw, that model was end-of-lifed late last year. Sorry. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Is this how it is done? set user default IDLE_TIMEOUT nnn Is the 'nnn' in minutes or seconds?

Where can you get information about this? I called 3com and they didn't know anything about the quad upgrade part. -Dale On Tue, 2 Mar 1999, Paul Jr. (AlaWeb Support) wrote: > Just wondering if everyone has heard about 3com's latest bundle. You can > purchase the Double play bundle which is two DSP cards for 8,995.00 and also > trade in 48 Quads for 2 extra DSP's for no extra money. > > The price above is from my vendor. > > I just thought this was a attractive offer and thought I would share it with > everyone. > > Thanks > Paul JR. > > > Original Message ----- > From: Behrens, William <WBehrens@Paracom.com> > To: <usr-tc@lists.xmission.com> > Sent: Tuesday, March 02, 1999 10:30 AM > Subject: RE: (usr-tc) Caveat Emptor > > > > > > Yes the Netserver code was licensed from Livingston (lucent). 3com's > >position is the hardware in the netserver class NAS is legacy due to the > >release of the HARC class NAS. Therefore they will no longer support the > NAS > >(in general) due to the inability to support the software and the release > of > >the new HARC. Features that do not work as advertised will not be fixed. > The > >standard reply is if you want "x" feature to work correctly then buy a > HARC. > >That's basically a load of shit. > > > > Supporting a particular platform for its lifespan is a cost of doing > >business. If they (3com) had not been selling netserver class NAS's for a > >couple of years I could maybe see the support drying up, but they were > >selling this box (thru distributors) up in till the end of this last year. > >That's not the customers problem, again a cost of doing business. Fix the > >distributor pipeline (i.e. don't fill it with product you know you won't > >support). > > > > For the most part people are pissed off due to 3com's desire for its > >customers to pay for its poor business practices and lack of foresight. If > >you purchased an automobile with an engine that was manufactured by a 3rd > >party and 3 months later the OEM said "sorry we don't support your > >automobile anymore because the engine is old, but you can buy this NEW > >automobile to fix your problem" would you be pissed ? You bet your ass you > >would. You would get an attorney and have a heyday with the auto maker in > >question. There is an implied warranty. If you can prove the manufacturer > >was not doing business with you in good faith at the time of purchase then > >he would be held accountable for his actions in a court of law. > > > > These people who are "whining and moaning" have a legetament gripe. > >They feel they have been screwed. Buying a NAS is not like buying a > computer > >or OS as an earlier poster had suggested. PC's don't cost 10K+ (at least > not > >desktops). I am not whining as my Netserver's are working for me and I > don't > >need the support for some of the software features, but this act buy 3com > of > >not supporting there customers in a "good faith" manner has made me think > of > >"fork lifting" my NAS's back to Lucent and PM4's. > > > >William Behrens > > > >>"Behrens, William" wrote: > > > > > >>> I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting > note > >>> Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com > >>> support the netserver? > > > >>From what I've read, 3Com does not have access to the code that runs on > the > >>netserver anylonger. Why this is, I have not seen posted other than the > >>license ran out. Were they told it would cost some unrealistic number to > >>relicense it, or are they just being cheap because now they have their own > >>code? > > > >>Bitching and moaning will not help if the owners of the code are unwilling > >>to relicense it. What's the real story? > > > >>-Ron > >>GLISnet, Inc > >>+1 810/939.9885 > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

you sure that's not 12 Quads for 2 DSP's?? 48 quads = 192 ports -----Original Message----- >Where can you get information about this? I called 3com and they didn't >know anything about the quad upgrade part. > >-Dale > >On Tue, 2 Mar 1999, Paul Jr. (AlaWeb Support) wrote: > >> Just wondering if everyone has heard about 3com's latest bundle. You can >> purchase the Double play bundle which is two DSP cards for 8,995.00 and also >> trade in 48 Quads for 2 extra DSP's for no extra money. >> >> The price above is from my vendor. >> >> I just thought this was a attractive offer and thought I would share it with >> everyone. >> >> Thanks >> Paul JR. >> >> >> Original Message ----- >> From: Behrens, William <WBehrens@Paracom.com> >> To: <usr-tc@lists.xmission.com> >> Sent: Tuesday, March 02, 1999 10:30 AM >> Subject: RE: (usr-tc) Caveat Emptor >> >> >> > >> > Yes the Netserver code was licensed from Livingston (lucent). 3com's >> >position is the hardware in the netserver class NAS is legacy due to the >> >release of the HARC class NAS. Therefore they will no longer support the >> NAS >> >(in general) due to the inability to support the software and the release >> of >> >the new HARC. Features that do not work as advertised will not be fixed. >> The >> >standard reply is if you want "x" feature to work correctly then buy a >> HARC. >> >That's basically a load of shit. >> > >> > Supporting a particular platform for its lifespan is a cost of doing >> >business. If they (3com) had not been selling netserver class NAS's for a >> >couple of years I could maybe see the support drying up, but they were >> >selling this box (thru distributors) up in till the end of this last year. >> >That's not the customers problem, again a cost of doing business. Fix the >> >distributor pipeline (i.e. don't fill it with product you know you won't >> >support). >> > >> > For the most part people are pissed off due to 3com's desire for its >> >customers to pay for its poor business practices and lack of foresight. If >> >you purchased an automobile with an engine that was manufactured by a 3rd >> >party and 3 months later the OEM said "sorry we don't support your >> >automobile anymore because the engine is old, but you can buy this NEW >> >automobile to fix your problem" would you be pissed ? You bet your ass you >> >would. You would get an attorney and have a heyday with the auto maker in >> >question. There is an implied warranty. If you can prove the manufacturer >> >was not doing business with you in good faith at the time of purchase then >> >he would be held accountable for his actions in a court of law. >> > >> > These people who are "whining and moaning" have a legetament gripe. >> >They feel they have been screwed. Buying a NAS is not like buying a >> computer >> >or OS as an earlier poster had suggested. PC's don't cost 10K+ (at least >> not >> >desktops). I am not whining as my Netserver's are working for me and I >> don't >> >need the support for some of the software features, but this act buy 3com >> of >> >not supporting there customers in a "good faith" manner has made me think >> of >> >"fork lifting" my NAS's back to Lucent and PM4's. >> > >> >William Behrens >> > >> >>"Behrens, William" wrote: >> > >> > >> >>> I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting >> note >> >>> Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com >> >>> support the netserver? >> > >> >>From what I've read, 3Com does not have access to the code that runs on >> the >> >>netserver anylonger. Why this is, I have not seen posted other than the >> >>license ran out. Were they told it would cost some unrealistic number to >> >>relicense it, or are they just being cheap because now they have their own >> >>code? >> > >> >>Bitching and moaning will not help if the owners of the code are unwilling >> >>to relicense it. What's the real story? >> > >> >>-Ron >> >>GLISnet, Inc >> >>+1 810/939.9885 >> > >> > >> >- >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> > with "unsubscribe usr-tc" in the body of the 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. > >

Can some one point me in the direction on where to get the version info on my HyperArc adn DSP cards? Also what is the latest release of the code? Is it stable? What is the most stable version at this time,what one are you guys happy with? -Steve ---- Steve Johnson Sonic.net, Inc. (707)522-1001 (33.6kbps) (707)522-1000 (Voice) mailto:support@sonic.net http://www.sonic.net ---- "Knowing others is wisdom, knowing your self is Enlightenment." -- Lao-Tzu

On Thu, 4 Mar 1999, Richard Stuplich wrote: > Is this how it is done? > > set user default IDLE_TIMEOUT nnn > > Is the 'nnn' in minutes or seconds? According to the ARC at least: HiPer-1>> set useR default idLE_TIMEOUT ? This field the number of seconds within a Range The valid range is 0-86400 Charles > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Lon R. Stockton, Jr. >> Hrmm...interesting thought...I know the Arc can "authenticate" based on >> DNIS, so it could change the behavior of the port that way, though that >> doesn't take care of modem connect problems because the modems have >> already connected, or failed to connect by the time the Arc sees the >> DNIS I believe. I'm unaware of any way to have the modem on the DSP >> reconfigure on the fly based on DNIS at this point, though I'm not >> extremely knowledgeable about them yet. That would be pretty cool to >> do, but I think it would require some changes in the DSP's to do it (I >> would be happy to learn that I'm wrong). >I still haven't done it, but have looked around a little based on this >and another recent thread about how the inits work. >The thing I'm talking about is evidently configured on the 'DNIS Access >Codes' in the HDSP templates (in TCM, select the hdsp card, then hit >configure button, then pull up DNIS Access Codes....then look at help >for the items). Apparently, you can actually have up to four different >ones. Well...that's cool...like i said, I would be happy to learn that I'm wrong, and apparently I am. :) When we actually get enough DSP's where this might be an actual help to us, I'll definitely check it out. >This init would be issued to the modem prior to it accepting the call >(but of course after the call hits the span). If everything works >as advertised *grin*, my aforementioned idea is apparently trivial. Heh...big "if" there of course. :) >I found the configuration of HARC's modem init string and the >documentation of same in a supiciously obvious place given the >amount surprise everyone is showing in finding out that it exists. Yup...even in the CLI, I noticed it without even looking for it. Didn't look and find out what the init string it was sending was, but I did notice that the Arc had the capability (and looks like it was doing so by default) to send an init string to the modem...*shrug*. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

OSPF should be part of TCS 3.5 release. I believe this is already in Beta.. George Ebert Network Consultant - Midwest 847-262-1229 Allen Marsalis <am@shreve.net> on 02/28/99 02:40:13 AM cc: dean@iglou.com , dboyer@commnet.com, Thomas Goodman/MW/US/3Com@3Com, Glenn Gibney/MW/US/3Com@3COM, George Ebert/MW/US/3Com@3Com At 12:36 PM 2/26/99 -0500, Jeff Mcadams wrote: >Primarily, I believe 3Com should ditch this "revenue positive" attitude >that they seem to have. This attitude seems to be pervasive throughout >all of 3Com. The result of this attitude is that 3Com ends up screwing >their longest and most loyal customers. Customers such as us that have >had USR/3Com gear for years have to pay more money to keep our equipment >up to date and to work around bugs that 3Com was unable to fix, and >their poor planning in not having an upgrade path available for the >older equipment. We have a large number of NETServer cards, and the >only three options that we have are to throw that investment into the >trash, try to sell these things used which throws most of our investment >into the trash, or send them back to 3Com for a $3200 rebate on new >purchases, which still throws a significant investment into the trash. > How about this idea Jeff.. Purchase the upgrade, send in your netserver for the rebate, then sell off the HDM.. Since standalone HDM's are not cheap, I bet you could the the "free" upgrade you desire albeit with a little leg work... I know I'd be happy to pay $3200 ea for HDM's.. We now have a dozen or more chassis stripped of HDM's.. I'd really like to just purchase HDM's and I'd even be willing to swap an ARC or two for HDM's.. When it comes to USR upgrades, you just have to be a little inventive and imaginative.. and a little compromising... I was able to upgrade all our netservers to arcs one year ago without too much pain, and there was NO upgrade path at all at that time.. Sure we had to hustle a little, but it sure was worth it to get rid of Quake lag, broke MPIP, etc.. I really don't care which direction the relief comes from as long as it gets there.. :) I really fought hard for that upgrade path Jeff, and I didn't even get to take advantage of it myself.. It just hurts a little to see someone less happy and yet better positioned to fix the problem than we were.. And if the energy spent banging heads with 3COM corporate types is less than that spent to really *solve the problem*, I'd be surprised.. Not that I'm against matters of principle, it's just my principles are tempered by an overall lack of time and energy I guess.. However good luck in your quest, and you really have a good rep (Tom) on your side. Tom really does care, follow though, and will "go to bat" for his customers.. <dredging up old memories> Speaking of promises though, whatever happened to OSPF? not on the netserver (I'm not completely stupid) but on the ARC? Think we might see it this year? (or have I just been out of the loop too long) It sure would be nice to use a decent interior routing protocol besides RIP... Allen

The issue of 3Com's version numbering system has come up on occasion. Mr. McAdams was right on with his note (copied here). I've just added a little more information to his answer. Thus spake Paul M. Oster > Maybe someone from 3com can spell this out in REALLY simple english for >those of us that still dont see it... I've always been confused by this >numbering, but just went by the dates... now I'm curious :) For basic releases, the third number goes up, but emergency and service releases number them down from the top. So, you'll have the regular release (using the HiPer Arc's as an example) that start with 4.1.1, 4.1.2, 4.1.3, and eventually in this series, got released as 4.1.11. ER's and SR's start with 4.1.99, 4.1.98, 4.1.97, etc. Having SR's come out in this case at 4.1.72 and 4.1.59. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456 Thanks Dave ---------------------- Forwarded by David Cartwright/MW/US/3Com on 03/04/99 02:06 PM --------------------------- Dave at 3Com <dave@totalservice.usr.com> on 03/04/99 01:53:09 PM Please respond to Dave at 3Com <dave@totalservice.usr.com> cc: (David Cartwright/MW/US/3Com) To further clarify, code releases have an XX.YY.ZZ version label. XX.YY represents the version of code. The .ZZ is unique for each code release. For regular releases the .ZZ increments, such as 4.1.1, 4.1.2, 4.1.3, and so on. For Emergency and Service Releases, the .ZZ starts at 99 and decrements as additional releases are required. If multiple releases are required for one feature/MR, then XX.YY.ZZ.CC or XX.YY.ZZ-CC is used. For example, the HiPer ARC service released posted on the Total Control web site is version number 4.1.59-1 3Com Customer Support 3Com Technician wrote: > Released code will move in ascending order however, when an ER or Service > Release comes out, such as 4.1.59, the code numbers move in descending order. > > 3Com Carrier Support > > > ME wrote in message <7bhplb$lrr$1@tempest.nsd.usr.com>... > > >I need to know if what is the newest v90 code for the HiperArc Modems. I > > >have been using the 4.1.72 and I see that on the USR site 4.1.59 is newer > > >and supposed to be built from 4.1.72???? > > >Is this correct, an older version number is newer???? > > > > > >-- > > >Bill Somers > > >InterDomain Net Services, Inc. > > > To Subscribe/Unsubscribe to/from the 3Com Carrier User-Forums - http://totalservice.3com.com/forums/ To access the 3Com Knowledgebase - http://knowledgebase.3com.com To access 3Com Carrier documentation - http://totalservice.3com.com/documents/ To view 3Com Carrier Service Offerings - http://totalservice.3com.com/services/

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bolen |Sent: Thursday, March 04, 1999 2:35 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) What is the Newest V90 Code???? | | |"David Cartwright" <David_Cartwright@mw.3com.com> writes: | |> For Emergency and Service Releases, the .ZZ starts at 99 and |> decrements as additional releases are required. If multiple |> releases are required for one feature/MR, then XX.YY.ZZ.CC or |> XX.YY.ZZ-CC is used. For example, the HiPer ARC service released |> posted on the Total Control web site is version number 4.1.59-1 | |It's not entirely clear if you're saying that publically released |versions may differ in the "CC" scheme (I was under the impression |that didn't happen), or just that the currently released version of |4.1.59 is the only one so CC is implicitly "-1", and for any given |public release there will only be one "CC" value. | |But in case there's any suggestion that, for example, a 4.1.59-x might |also make it out where x isn't "1", for my 2 cents, letting different |XX.YY.ZZ-CC releases out of the lab is ludicrous, because there is no |way (other than for example console commands) to query that version |information via standard management tools through the NMC, and thus no |way via such tools to verify what revision of code you have installed. | |I can sort of understand why internal R&D revs of code that are |anticipated to deliver an ER or SR might use that extra level of |numbering to help avoid burning the number space, but a unique number |within the XX.YY.ZZ range should always be assigned before that code |leaves the lab. The "-CC" shouldn't be necessary to disambiguate |generally available code releases. | |Either that, or the standard TC management interfaces (in particular, |SNMP via the NMC) need to be augmented to be able to return all of the |version information. | Unfortunately this is not the case.. There are multiple ERs/SRs that only differ in the CC number in circulation. And yes at this time the only way to tell is with the "_show version" console command. The management tools are not able to get this information. This should be corrected soon to allow the query of build number via SNMP since this practice will continue for future releases. -M

"David Cartwright" <David_Cartwright@mw.3com.com> writes: > For Emergency and Service Releases, the .ZZ starts at 99 and > decrements as additional releases are required. If multiple > releases are required for one feature/MR, then XX.YY.ZZ.CC or > XX.YY.ZZ-CC is used. For example, the HiPer ARC service released > posted on the Total Control web site is version number 4.1.59-1 It's not entirely clear if you're saying that publically released versions may differ in the "CC" scheme (I was under the impression that didn't happen), or just that the currently released version of 4.1.59 is the only one so CC is implicitly "-1", and for any given public release there will only be one "CC" value. But in case there's any suggestion that, for example, a 4.1.59-x might also make it out where x isn't "1", for my 2 cents, letting different XX.YY.ZZ-CC releases out of the lab is ludicrous, because there is no way (other than for example console commands) to query that version information via standard management tools through the NMC, and thus no way via such tools to verify what revision of code you have installed. I can sort of understand why internal R&D revs of code that are anticipated to deliver an ER or SR might use that extra level of numbering to help avoid burning the number space, but a unique number within the XX.YY.ZZ range should always be assigned before that code leaves the lab. The "-CC" shouldn't be necessary to disambiguate generally available code releases. Either that, or the standard TC management interfaces (in particular, SNMP via the NMC) need to be augmented to be able to return all of the version information. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Hi, Can anybody send me some sane trapd.conf for HPOV unix that can be used to parse traps coming from TC? thanks, ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

A service release of HiPerARC has been posted to the Totalservice website. It addresses the Webramp/Mac issues as well as some other ISDN TA's. Please carefully "READ THE RELEASE NOTES" so you know how to verify the HARC configuration to resolve these problems. A blind upgrade will without some configuring may NOT resolve the issues. HARC 4.1.59-6 ftp://mwronski:qwerty@totalservice.usr.com/pub/.files/ne040159_6.zip Release Notes ftp://totalservice.usr.com/pub/.docs/040159_6.pdf This code will does not require a service contract to download. Mike Wronski (mike@coredump.ae.usr.com) Rogue 3Com Network Systems Engineer / BETA Engineer PGP:http://coredump.ae.usr.com/pgp iCQ:15796141 "If at first you do succeed, try not to look astonished."

On 3 Mar 99, at 17:04, Carl Ansley <usr-tc@lists.xmission.com> wrote: > (i.e. charge users) based on this information. We're running 4.1.11. > > example: > > User-Name = "joebloggs" > Framed-Protocol = PPP > Framed-IP-Address = x.x.x.x > Acct-Session-Time = -85082 <---- > Acct-Terminate-Cause = User-Request > > We see this on both ISDN and analogue calls. Is this a bug/feature anyone > else has seen? I've seen extremely interesting acct times when you change the time of day of the ARC. It may look especially interesting when you change the time from default of its epoh to current time, and then find that some of your users have been online for 30 years or so... Or, been idle for few years ;) cute, isn't it. ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

This appears to be a done deal. See http://www.3com.com/promotions/hipertrade You have to buy a "Double Play" kit with 2 DSP's and the netserver memory upgrade, then you send in your quads (6 or 12). They send you one or two DSP's. For a growing ISP, this seems like a good deal. Randy Cosby InfoWest, Inc. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Matthew E. Pearson > Sent: Friday, March 05, 1999 8:53 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Port Density > > > Several of us have been beating up on 3com about a rational > upgrade program > from Quads to DSPs. I am told nothing is final yet but they are very near > finishing the promotion details and allowing people to use it. > > But it will be something like "buy two DSP, turn in 12 quad and > get two more > DSP free (or 1/2 price or something). To put some value on all those quad > cards most of us have kicking around. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Several of us have been beating up on 3com about a rational upgrade program from Quads to DSPs. I am told nothing is final yet but they are very near finishing the promotion details and allowing people to use it. But it will be something like "buy two DSP, turn in 12 quad and get two more DSP free (or 1/2 price or something). To put some value on all those quad cards most of us have kicking around.

Mike Wronski said once upon a time: > >A service release of HiPerARC has been posted to the Totalservice website. It >addresses the Webramp/Mac issues as well as some other ISDN TA's. Please >carefully "READ THE RELEASE NOTES" so you know how to verify the HARC >configuration to resolve these problems. A blind upgrade will without some >configuring may NOT resolve the issues. I was interested to see that MPPP now has a global switch. What is the proper Framed-Protocol to use for MPPP? I have a customer who is connecting with Linux MPPP and the second connection always gets dropped upon authentication. The global switch for MPPP is on, but this is the result. Currently, I'm using PPP for the connection, I can't appear to find the proper value for the dictionary for the ARC to recognize MPPP. As an interesting side note, this connection worked flawlessly on a Netserver.

Hello- We have an old Netserver 16 that we use for some dedicated line people for their low traffic mail servers. I need to get into the box to change the IP information. I have the password for the box and can telnet into it from any other host on the internet. However in order to change the ip info I would like to have the console available. I can't get the console to let me in and I'm at wit's end on it. Below is the config for s0. If I try to !root into it from the console it never asks for a password. If I root into the console the password attempt shows up in our logfiles. I'm just lost on it. Any help is appreciated. If you need more info, please let me know. I've tried changing the port type for s0 to network hardwired to no avail. The cable I'm using works on our reg TC chassis with Netservers and Hipers. Steve ----------------------- Current Status - Port S0 --------------------------- Status: USERNAME Input: 41 Parity Errors: 0 Output: 1134 Framing Errors: 0 Pending: 0 Overrun Errors: 0 Active Configuration Default Configuration (* = Host -------------------- --------------------- Can Override) Port Type: Login Login Login Service: Telnet Telnet Baud Rates: 9600 9600,9600,9600 Databits: 8 8 Stopbits: 1 1 Parity: none none Flow Control: None None Modem Control: off off Init Script: (None) Init When?: Never Hosts: default Terminal Type: vt100 Login Prompt: login: Idle Timeout: 20 min 0 sec Login Message: login: } Welcome to CORE Digital

The ER code is in Totalservice. Check in software Library and search for Hiper ARc. The code ver is 4.1.59-6 Regards Sanjay Agarwal On Fri, 5 Mar 1999, Jeff Binkley wrote: > > What happened to the new HiPerArc ER code which fixes the Webramp and > Mac connect problems ? I just checked and it was on the TotalService > site yesterday but now it's gone. > > Jeff Binkley > ASA Network 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. >

http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm "The German communications giant is in preliminary discussions with 3Com to acquire a unit of the U.S. vendor that sells networking equipment to telephone companies, for a price of around $1.2 billion, the New York Times report said. " What unit would that be? Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com

What happened to the new HiPerArc ER code which fixes the Webramp and Mac connect problems ? I just checked and it was on the TotalService site yesterday but now it's gone. Jeff Binkley ASA Network Computing

This code wiped out the ip pools entires on about 1/3 of my units, be sure to do a "list ip pools" after you upgrade and make sure they are still there. I don't know if any other settings were affected. You may want to reconfigure from scratch if you can. Mike Wronski writes... >A service release of HiPerARC has been posted to the Totalservice website. It >addresses the Webramp/Mac issues as well as some other ISDN TA's. Please >carefully "READ THE RELEASE NOTES" so you know how to verify the HARC >configuration to resolve these problems. A blind upgrade will without some >configuring may NOT resolve the issues. > >HARC 4.1.59-6 -- Aaron Nabil

On Fri, 5 Mar 1999 vanhalen@coredcs.com wrote: > Hello- > > We have an old Netserver 16 that we use for some dedicated line people for > their low traffic mail servers. I need to get into the box to change the > IP information. I have the password for the box and can telnet into it > from any other host on the internet. However in order to change the ip > info I would like to have the console available. > Telnet to the box and change the following below set security on set host 0.0.0.0 set s0 login_service portmux set s0 login network diailin reset s0 krish > I can't get the console to let me in and I'm at wit's end on it. Below is > the config for s0. If I try to !root into it from the console it never > asks for a password. If I root into the console the password attempt > shows up in our logfiles. I'm just lost on it. Any help is appreciated. > If you need more info, please let me know. > > I've tried changing the port type for s0 to network hardwired to no avail. > The cable I'm using works on our reg TC chassis with Netservers and > Hipers. > > Steve > > > > ----------------------- Current Status - Port S0 --------------------------- > Status: USERNAME > Input: 41 Parity Errors: 0 > Output: 1134 Framing Errors: 0 > Pending: 0 Overrun Errors: 0 > > Active Configuration Default Configuration (* = Host > -------------------- --------------------- Can > Override) > Port Type: Login Login > Login Service: Telnet Telnet > Baud Rates: 9600 9600,9600,9600 > Databits: 8 8 > Stopbits: 1 1 > Parity: none none > Flow Control: None None > Modem Control: off off > Init Script: (None) > Init When?: Never > Hosts: default > Terminal Type: vt100 > Login Prompt: login: > Idle Timeout: 20 min 0 sec > Login Message: > login: > } > > Welcome to CORE Digital > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Hello- Thanks for the reply. I did the commands and also had to set !root on to set !root dial-in access on. This was different than our TC hub with Netservers and Quads where !root dialin access is set to off and it still allows console connections. I thought that was a little curious. btw set s0 login_service portmux should be set s0 service_login portmux. But either way, I'm happy that I can console in now. Thanks much for the help. Steve On Sat, 6 Mar 1999, Tatai SV Krishnan wrote: > Telnet to the box and change the following below > > > set security on > set host 0.0.0.0 > set s0 login_service portmux > set s0 login network diailin > reset s0 > > krish >

hey, someone mentioned some compression you could shut off that would help winmodem people connect better? which compression is this and how do you shut it off? matthew

Hi - Do any of you guys know if there is a way to extract the session ID's that are used in Radius accounting (Acct-Session-Id 44) for all connected users from a HiperArc? I've poked through the MIB files and there are a couple items that are close but they either do not work (the chassis does not respond at all, though the MIB says thet should be there) or they return a diffrent sort of session ID (internal?). Also, related, the below is an exerpt from the "usr_hiper.mib" file. Any clue what integer INDEX component "uumActiveSessionId" actually is? These values don't seem to relate to anything that I can find... uumActiveSessionEntry OBJECT-TYPE SYNTAX UumActiveSessionEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "" INDEX { uumActiveSessionUserName, uumActiveSessionSessionId } ::= { usrUserManActiveSessionTable 1 } Thanks! -Jim

My Webramp 310i now connects but it's still not good. The connection is good for about 1-10mins then is hosed this is without VJ and Stac turned on. With VJ and Stac turned on the connections is hosed right away but it connects now. Mike Wronski wrote: > > A service release of HiPerARC has been posted to the Totalservice website. It > addresses the Webramp/Mac issues as well as some other ISDN TA's. Please > carefully "READ THE RELEASE NOTES" so you know how to verify the HARC > configuration to resolve these problems. A blind upgrade will without some > configuring may NOT resolve the issues. > > HARC 4.1.59-6 > ftp://mwronski:qwerty@totalservice.usr.com/pub/.files/ne040159_6.zip > Release Notes ftp://totalservice.usr.com/pub/.docs/040159_6.pdf > > This code will does not require a service contract to download. > > --------------------------------------------------------- > Mike Wronski (mike@coredump.ae.usr.com) > Rogue 3Com Network Systems Engineer / BETA Engineer > PGP:http://coredump.ae.usr.com/pgp iCQ:15796141 > "If at first you do succeed, try not to look astonished." > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

On Sat, 6 Mar 1999, Matthew Opoka wrote: > My Webramp 310i now connects but it's still not good. The connection is > good for about 1-10mins then is hosed this is without VJ and Stac turned > on. With VJ and Stac turned on the connections is hosed right away but > it connects now. > Totally a different issue. This code 4.1.59 -6 solves the pap connection issue only. What you are experiencing a a different problem. Need PPP trace to find out what is exactly happening. Where are you enabling stac and vj? Where are you disabling stac and vj? When it disconnects what is the disconnect reason? Is this problem solved if you use chap? Apart from the ppp trace answers to the above questions will be helpful krish > > > > This code will does not require a service contract to download. > > > > --------------------------------------------------------- > > Mike Wronski (mike@coredump.ae.usr.com) > > Rogue 3Com Network Systems Engineer / BETA Engineer > > PGP:http://coredump.ae.usr.com/pgp iCQ:15796141 > > "If at first you do succeed, try not to look astonished." > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

I've heard the rumor about 3Com offloading the Total Control unit a few times now, so I'm starting to believe it. This Siemens story makes me think it's going to happen. > http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm I hope the deal is beneficial for everyone. Maybe Siemens will commit more resources to developing the Total Control products than 3Com has. Higher density and DS3 ingress would be nice. -CH Related older stories: http://images.cnnfn.com/digitaljam/9707/09/3com/ http://www.3com.co.uk/news/ihop/ihopnews6.html Randy Cosby wrote: > > > "The German communications giant is in preliminary discussions with 3Com to > acquire a unit of the U.S. vendor that sells networking equipment to > telephone companies, for a price of around $1.2 billion, the New York Times > report said. " > > What unit would that be? > > Randy Cosby <dcosby@infowest.com> > Vice President > InfoWest Global Internet Services, Inc. > (435)674-0165 http://www.infowest.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.

Charles Hill wrote: > > I've heard the rumor about 3Com offloading the Total Control unit a few > times now, so I'm starting to believe it. This Siemens story makes me > think it's going to happen. > > > http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm > > I hope the deal is beneficial for everyone. Maybe Siemens will commit > more resources to developing the Total Control products than 3Com has. > Higher density and DS3 ingress would be nice. Plus when things don't go right, I'll pick up my Siemens phone, call Siemens tech support, and tell them that my Total Control is connected to a Siemens EWSD switch, and the damn thing better work properly on thier own switch. Maybe we can get blocking to work properly on NI2 PRI's. Ten digit numbers for DNIS would be nice as well. Actually it's quite funny to see a local problem where two EWSD switches just don't seem to like each other. The woman working for Ameritech said, "These damn things should like each other, god knows that the EWSD doesn't like Lucent or Nortel switches." -Ron GLISnet, Inc. +1 810/939.9885

I was poking around in the Total Control MIB lately, and noticed objects for reading the status and colors of the LEDs on a chassis-wide basis. However, it's a proprietary encoding. Anybody crack the encoding scheme? Or, can somebody point me to documentation that tells me how to decode them? I promise any project gleamed from this info would be given away for free. ;-) ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

I am trying to use the new IEA feature in the 4.1.59-6 HARC code. I managed to use it with local non-radius users: set network usr my_local_user IP IEA_NEXT_HOP_GATEWAY 192.0.0.1 Now this is great, but I need to use this for particular users from RADIUS, so I added in the dictionnary the following: ATTRIBUTE IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr And I added to my "users" file the entry IEA_NEXT_HOP_GATEWAY = 192.0.0.1, The RADIUS users still pick the defaultroute :( I tried to monitor the connection with "mon radius" on the HARC but it does not seem to report any VSA attributes anyway. Oh BTW for those who don't know what IEA is, it stands for Internet Equal Access and it is used to specify a different gateway than the defaultroute. D. Baud

Either that, or the TC line will become just like the rest of Siemens equipment: Siemens - You can buy better, but you can't pay more. At 11:07 PM 3/6/99 -0600, you wrote: >I've heard the rumor about 3Com offloading the Total Control unit a few >times now, so I'm starting to believe it. This Siemens story makes me >think it's going to happen. > >> http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm > >I hope the deal is beneficial for everyone. Maybe Siemens will commit >more resources to developing the Total Control products than 3Com has. >Higher density and DS3 ingress would be nice. > >-CH > >Related older stories: >http://images.cnnfn.com/digitaljam/9707/09/3com/ >http://www.3com.co.uk/news/ihop/ihopnews6.html > >Randy Cosby wrote: >> >> >> "The German communications giant is in preliminary discussions with 3Com to >> acquire a unit of the U.S. vendor that sells networking equipment to >> telephone companies, for a price of around $1.2 billion, the New York Times >> report said. " >> >> What unit would that be? >> >> Randy Cosby <dcosby@infowest.com> >> Vice President >> InfoWest Global Internet Services, Inc. >> (435)674-0165 http://www.infowest.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. > --- Clayton Zekelman Managed Network Systems Inc. (MNSi) 875 Ouellette Avenue Windsor, Ontario N9A 4J6 tel. 519-985-8410 fax. 519-258-3009

On Sun, 7 Mar 1999, d baud wrote: > I am trying to use the new IEA feature in the 4.1.59-6 HARC code. I > managed to use it with local non-radius users: > set network usr my_local_user IP IEA_NEXT_HOP_GATEWAY 192.0.0.1 > > Now this is great, but I need to use this for particular users from > RADIUS, so I added in the dictionnary the following: > ATTRIBUTE IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr > > And I added to my "users" file the entry > IEA_NEXT_HOP_GATEWAY = 192.0.0.1, > > The RADIUS users still pick the defaultroute :( > I tried to monitor the connection with "mon radius" on the HARC but it > does not seem to report any VSA attributes anyway. > > Oh BTW for those who don't know what IEA is, it stands for Internet > Equal Access and it is used to specify a different gateway than the > defaultroute. use VPN-Neighbor instaead: VPN-Neighbor = "192.0.0.1" > > D. Baud > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

> I've heard the rumor about 3Com offloading the Total Control unit a few > times now, so I'm starting to believe it. This Siemens story makes me > think it's going to happen. > > > http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm > > I hope the deal is beneficial for everyone. Maybe Siemens will commit > more resources to developing the Total Control products than 3Com has. > Higher density and DS3 ingress would be nice. Seimens is the ones who payed for the development of VoIP in the TC. (Maybe I want to move to Chicago after all :-)) --Ricky

Hi All, Is there any commercial software or shareware, w/ whatever the Language it was written, that can be used to analyze the user login info that was logged from TC box into our Unix syslogd file. ? We tried 3com's Accounting software before and not too enthusastic about it. And we do not have Radius. Thanks Meng tsaim@mft.com

> Is there any commercial software or shareware, w/ whatever the Language > it was written, > that can be used to analyze the user login info that was logged from TC > box into our > Unix syslogd file. ? > > We tried 3com's Accounting software before and not too enthusastic about > it. > And we do not have Radius. Well, I've found the syslog data to be wrong too often to use it to bill people. I'll post the perl based junk I have for processing the syslog data after I dig it back up. --Ricky

Does your radius server support VSAs? krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Sun, 7 Mar 1999, d baud wrote: > I am trying to use the new IEA feature in the 4.1.59-6 HARC code. I > managed to use it with local non-radius users: > set network usr my_local_user IP IEA_NEXT_HOP_GATEWAY 192.0.0.1 > > Now this is great, but I need to use this for particular users from > RADIUS, so I added in the dictionnary the following: > ATTRIBUTE IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr > > And I added to my "users" file the entry > IEA_NEXT_HOP_GATEWAY = 192.0.0.1, > > The RADIUS users still pick the defaultroute :( > I tried to monitor the connection with "mon radius" on the HARC but it > does not seem to report any VSA attributes anyway. > > Oh BTW for those who don't know what IEA is, it stands for Internet > Equal Access and it is used to specify a different gateway than the > defaultroute. > > D. Baud > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

At 04:18 PM 3/8/99 +0100, Robert von Bismarck <rvb@petrel.ch> wrote: >I'm kinda sick of reading all this junk about suing 3com and blablabla... >Stop the whining. Did you also all whine as much when you found out your old >286 wasn't able to run win95 ? You're missing the whole point of their complaints. Their gripe isn't that a 286 won't run Win'95, the gripe is that they were promised that it would when they bought it, now it doesn't, and they're being told that their only option is to buy something else. It's not about the Netserver's capabilities, it's about the salesman or company misrepresenting the product and it's capabilities in order to sell it. At least that's what I inferred by actually reading the complaints. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Thus spake Robert von Bismarck >I'm kinda sick of reading all this junk about suing 3com and blablabla... >Stop the whining. Did you also all whine as much when you found out your old >286 wasn't able to run win95 ? >You eventually found out that you had to upgrade to a 386 to be able to run >Linux, if you haven't found out yet, stop reading this right now ;-). This >also happens with servers, even with NAS's. The 486 has outlived it's life, >welcome to the PPC. >If you want the features, buy the right hardware and software. You just don't get it, do you? This is *NOT* about features. I don't need to upgrade, I need the NETServers to work as advertised, nothing more. >You want 48 >ports ? fine... buy a couple pm2's with a bunch of Courier modems and a >2501, and off you go into the happy world of low-cost, low-business >ISPing... and you're out of business in 2 years, Sorry to disappoint you, but IgLou has been in this business for over 12 years at this point, hardly some "low-cost, low-business" ISP or out of business in 2 years. I would hazard a bet that we've been using USR/3Com equipment for longer than your ISP has been in business! >Upgrade is the power-word. In the ISP business it's "do or die". You want to >survive, you need more (be it customers, employees, ports, PoP's, etc...) >else you're dead or dying. I agree...and we're working on upgrading...however, at the same time, throwing away hundreds of thousands of dollars of investments because some vendor says their incapable of fixing something that should have worked in the first place is certainly not a good recipe for being profitable either. Another news flash for you...IgLou is profitable, and has been for longer than probably 90% of ISP's have been in business, we didn't do that by flushing equipment investments down the drain just because the equipment is a generation older. If it still does what we need it to do, we continue to use it. Yes, upgrading is important to be able to get new features...at this point, the HiPer Arc doesn't have any features that the NETServer doesn't, or more importantly, any features which make it worth our while to go into debt in order to obtain. We'll make, and are making, the move to HiPer Arc's, but are doing it in a way that's fiscally responsible. We're not going out and buying the latest, greatest hardware just because it gives us a testosterone boost to do so. The simple fact is that 3Com is using illegal tactics to sell HiPer Arcs. 3Com promised a software feature and in order to get that software feature to work, they are trying to get people to buy new hardware that it *CANNOT* be argued is necessary to get this feature working. You *CANNOT* argue that a 486 doesn't have enough CPU power to run MPIP. A PPC is simply not needed to do this...and for 3Com to try to sell the extra hardware (at a premium) to do this is a used car lot Bait and Switch tactic, nothing more. >I think 3com is aiming at the future, not at the "now". Oh, I agree...the HiPer Arc hardware is good hardware...and the OS on it has a nice feel (I don't know anything about the internals of it)...and IgLou is moving to the future and purchasing HiPer Arcs as they finally have all the features that we need to offer our service on them. To look to the future without also considering the "now" though is to assure that you won't make it to what you're looking at. I need functional MPIP, period. 3Com can deliver that however they wish, but to say that I need to pay a premium to get a feature that they said 3 months ago that I didn't need to pay a premium for, is downright unethical at best. >My boss usually says >"now is too late", and I'm sure he's right. Yeah, and 3Com is in the past, not even up to the "now," as they don't even have functional MPIP on the NETServers where it was originally delivered. >Well enough blathering, Perhaps if you'd listen to what others are saying before responding you might be able to respond with relevant points. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake K Mitchell >At 04:18 PM 3/8/99 +0100, Robert von Bismarck <rvb@petrel.ch> wrote: >>I'm kinda sick of reading all this junk about suing 3com and blablabla... >>Stop the whining. Did you also all whine as much when you found out your old >>286 wasn't able to run win95 ? > You're missing the whole point of their complaints. Their gripe isn't >that a 286 won't run Win'95, the gripe is that they were promised that it >would when they bought it, now it doesn't, and they're being told that >their only option is to buy something else. > It's not about the Netserver's capabilities, it's about the salesman or >company misrepresenting the product and it's capabilities in order to sell it. >At least that's what I inferred by actually reading the complaints. Actually...I'd go even further than that....its like being told that a 286 would run DOS 3.3...which by all means it should be able to...and then being told that to run DOS 3.3 we have to upgrade to a Pentium because they can't fix DOS 3.3 on a 286 anymore. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Greg, I placed an order, and we're doing the wire transfer this morning. I noticed something on the web page about a Palm III for new customers. Rita said that's an old promo, but I thought I'd ask anyway. I've got one buy my partner is very jealous :) Randy > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Genge > Sent: Wednesday, March 03, 1999 11:06 AM > To: usr-tc@xmission.com > Subject: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335 US for > 48 ports. > > > I checked the info on the list and found no mention of any problem posting > items for sale on this list. I'm sure I'll be corrected if I'm wrong and I > apologize in advance if that's the case but here goes. > > I noticed a couple people posting requesting to buy DSP cards. I have a > number of 3465 Double ups available for $8335 US delivered. Single cards > are $4200 each. These are brand new, full warranty, from a certified 3COM > (USRobotics) VAR. We want to move these quickly so we will beat any quote > for new cards by 5%. I also have a number or ARC Cards for $2000 each. > Custom configs are also no problem, AC, DC, 70, 130 AMP, 1 or 2 ARC's 1-14 > DSP's, edgeserver, any combination. > > As for my offer for free support, I have a number of Total Control trained > engineers on staff, including myself, and I offer free technical > support to > Dynavar customers and even Non-Dynavar customers to show that we can add > value to you future purchases. We also have a full lab setup here with > spares galore if anyone ever needs urgent replacement. We also offer > on-site training, we just completed 2 courses each for a customer (18 > students) Installation and Management, and HiPer ARC at less than 1/2 > 3COM's on-site cost, and within 4 weeks of request. > > Let me know if there is anything I can do for you. > > Regards, Greg > > Gregory F. Genge, President, Dynavar Networking, Inc. > Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, > 5005 Fax, http://www.dynavar.com > #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 > Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, > Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, > Compatible, > Microcom (Compaq), Garrett, Sonic, Cobalt. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Sorry about that... Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com

At 11:00 AM 3/8/99 -0500, Jeff Mcadams wrote: >Actually...I'd go even further than that....its like being told that a >286 would run DOS 3.3...which by all means it should be able to...and >then being told that to run DOS 3.3 we have to upgrade to a Pentium >because they can't fix DOS 3.3 on a 286 anymore. I stand corrected :) Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Have been reading this list for quite a while now and have learned a great deal about the TC platform from the knowledgeable people who are on this list. I wonder if anyone has put together an overview of the steps they take when putting a new Hiper Chassis (ARCs&HDMs) into service and whether they would share it with the rest of us. It seems to me from reading this list that there are some steps which would not be in the 3COM manuals, but which experience shows make the chassis more stable or better able to connect with a broader range of client modems. We still have more connect problems to our HDMs than with our quads and maybe we are missing some obvious ways to improve their connectivity while we wait for all the various v.90 implementations to improve. This ocurred to me while reading the thread on disabling v.42bis modem compression. It would also be nice to know what things are being done temporarily to work around current firmware issues. Thanks, Jim

On Mon, 8 Mar 1999, matthew de Jongh wrote: > well i rec'vd a junk fax from dynavar this weekend that mentions the free > palm III Did you file in small claims court for dynavar's violation of USC Title 47 Sec. 227(b)(1)(C)? Under 227(b)(3)(B) youre entitled to $500. Make that the most expensive fax dynavar has ever sent B) -Dan

I assume that those modems weren't MICA... These modems really suck bad. We had a dozen here for a "mini-POP" and finally gave it up, and replaced the cisco by a TC (ARC + DSP) and were really happy with it (still are ;-). Robert oh yeah, nearly forgot : FS : 12 Mica Modems with carrier module for Cisco 3640 ;-) > But the next purchase will not be 3com or Livingston but rather Cisco. :-) > > Not that were displeased with 3com Hiper or anything (its nice hardware, > and I like the interface better than ComOS), just that under months of > testing Cisco gave our customers more consistent and stable modem > connections than either Hiper or PM3 and in the end its customer > satisfaction not admin satisfaction that counts. Whatever magic DSP code > Cisco has it works and thats all that matters. > > And please no "run code version XYZ it will give better connects than > Cisco" because it doesnt. No code versons on either 3com or Livingston > made appreciably better or worse connections than any other version. > > -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.

The PM2-30 sitting in the closet is a 30 port. It's got an AMD Am386dx-40 and a mind-boggling 4 megs of RAM. Well it's an OEM by Cayman Systems, called "GatorAccess" but the mboard is definitely marked Livingston. -Robert > -----Original Message----- > From: MegaZone [SMTP:megazone@megazone.org] > Sent: lundi, 1. mars 1999 12:05 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 3Com Problems. > > Once upon a time Ricky Beam shaped the electrons to say... > >_damn_ good NAS -- who else has ever been able to get a 386dx40 to run > >48 115.2k serial ports without a problem? > > Well, the PM-2eR-30 only has a 386-33, early revs were 386-25. :-) That's > the most ports on an async PM. The PM-3 is a 486-66. > > -MZ > -- > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> > X*=- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, > me.. > Join ISP/C Internet Service Providers' Consortium > <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest men" > 781-788-0130 > <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail > Discordia! > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Correction, there is an upgrade to the 3640, I just performed that with an old 4000, you send in an old 4000 with all it's goodies, and they send you a 3640 chassis (no interfaces mind you, but you can get those at a very interesting price) -Robert > -----Original Message----- > From: Dan Hollis [SMTP:goemon@sasami.anime.net] > Sent: lundi, 1. mars 1999 22:09 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 3Com Problems. > > On Fri, 26 Feb 1999, Jeff Mcadams wrote: > > I can still buy Cisco 2500's, that's older hardware technology than the > > NETServers by a generation or two. > > Cisco has EOL'd the 4000 and 4500's. There is no upgrade path. > What are owners of that technology to do? > > -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.

well i rec'vd a junk fax from dynavar this weekend that mentions the free palm III matthew At 11:12 AM 3/8/99 -0700, you wrote: >Greg, > >I placed an order, and we're doing the wire transfer this morning. I >noticed something on the web page about a Palm III for new customers. Rita >said that's an old promo, but I thought I'd ask anyway. I've got one buy my >partner is very jealous :) > >Randy > > >> -----Original Message----- >> From: owner-usr-tc@lists.xmission.com >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Genge >> Sent: Wednesday, March 03, 1999 11:06 AM >> To: usr-tc@xmission.com >> Subject: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335 US for >> 48 ports. >> >> >> I checked the info on the list and found no mention of any problem posting >> items for sale on this list. I'm sure I'll be corrected if I'm wrong and I >> apologize in advance if that's the case but here goes. >> >> I noticed a couple people posting requesting to buy DSP cards. I have a >> number of 3465 Double ups available for $8335 US delivered. Single cards >> are $4200 each. These are brand new, full warranty, from a certified 3COM >> (USRobotics) VAR. We want to move these quickly so we will beat any quote >> for new cards by 5%. I also have a number or ARC Cards for $2000 each. >> Custom configs are also no problem, AC, DC, 70, 130 AMP, 1 or 2 ARC's 1-14 >> DSP's, edgeserver, any combination. >> >> As for my offer for free support, I have a number of Total Control trained >> engineers on staff, including myself, and I offer free technical >> support to >> Dynavar customers and even Non-Dynavar customers to show that we can add >> value to you future purchases. We also have a full lab setup here with >> spares galore if anyone ever needs urgent replacement. We also offer >> on-site training, we just completed 2 courses each for a customer (18 >> students) Installation and Management, and HiPer ARC at less than 1/2 >> 3COM's on-site cost, and within 4 weeks of request. >> >> Let me know if there is anything I can do for you. >> >> Regards, Greg >> >> Gregory F. Genge, President, Dynavar Networking, Inc. >> Toll Free 877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct, >> 5005 Fax, http://www.dynavar.com >> #300, 1550 - 5th Street S.W., Calgary, Alberta, Canada, T2R-1K3 >> Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard, >> Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, >> Compatible, >> Microcom (Compaq), Garrett, Sonic, Cobalt. >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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.

Stephen Amadei <amadei@dandy.net> writes: > I was poking around in the Total Control MIB lately, and noticed > objects for reading the status and colors of the LEDs on a chassis-wide > basis. However, it's a proprietary encoding. No so much proprietary (it's documented) as just a binary encoding, since your kind of stuck with opaque object definitions for binary stuff using SNMP's object types. Of course, it'd probably be nice if they stuck the encoding in the description for the object :-) You should be able to find the documentation in the "Network Management Card Parameter Reference Guide" - in the PDF copy I have for NMC 5.0, the LED objects specifically are discussed in chapter 3 (NMC parameters), starting on page 3-36. You can get the guide (NMCPRG50.PDF) off of the 3Com TotalService web site (http://totalservice.usr.com) by searching the documentation - last I checked it looked like it was generally accessible even as a guest account if you don't have a service contract. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Am I the only one seeing problems with 3com Winmodems and DSP code 1.2.59? I had 1.2.60 running, then went to 1.2.59 and the number of "takes multiple attempts to connect" complaints shot WAY up. This is the second time I've tried this, and looks like the second time I'm going back to 1.2.60. Someone tell me it's coincidence.... Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

You are correct. :) I've seen this since december. There is new code comming our soon that will fix this problem. -Dale On Mon, 8 Mar 1999, Mike Andrews wrote: > Am I the only one seeing problems with 3com Winmodems and DSP code 1.2.59? > I had 1.2.60 running, then went to 1.2.59 and the number of "takes > multiple attempts to connect" complaints shot WAY up. This is the second > time I've tried this, and looks like the second time I'm going back to > 1.2.60. Someone tell me it's coincidence.... > > > Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me > getting beaten by the police, put down the video camera and come help me!" > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I'm kinda sick of reading all this junk about suing 3com and blablabla... Stop the whining. Did you also all whine as much when you found out your old 286 wasn't able to run win95 ? You eventually found out that you had to upgrade to a 386 to be able to run Linux, if you haven't found out yet, stop reading this right now ;-). This also happens with servers, even with NAS's. The 486 has outlived it's life, welcome to the PPC. If you want the features, buy the right hardware and software. You want 48 ports ? fine... buy a couple pm2's with a bunch of Courier modems and a 2501, and off you go into the happy world of low-cost, low-business ISPing... and you're out of business in 2 years, while your next door neigbour invested in a more powerful system which is better in the upgrade and grabs your client database for 10$ at a court-level auction. Upgrade is the power-word. In the ISP business it's "do or die". You want to survive, you need more (be it customers, employees, ports, PoP's, etc...) else you're dead or dying. I think 3com is aiming at the future, not at the "now". My boss usually says "now is too late", and I'm sure he's right. The folks at 3com have built very good hardware, now they have to get the soft up to speed (all the major bugs are out, and the minors are getting solved). I remember a time, where I was rebooting my PM2e's every night at 4:30 to remove the memory leaks. Well enough blathering, all flames to /dev/null -- Robert von Bismarck Network Systems Engineer Petrel Communications SA / SPAN Tel : +41 22 304 47 47 Fax : +41 22 300 48 43 WWW : http://www.petrel.ch e-mail : rvb@petrel.ch

Sorry folks, didn't know you'd take it so.. erhm.. personally... I apologize if I've been rude, but I subscribed to this mailing-list for one thing : Tech answers to tech problems. I didn't find anything new in all those posts. This whining/blathering/whatever takes up time and bandwidth (brain bandwidth in my case) and I've got enough work/trouble to be able to live without all this noise, thank you. The signal to noise ratio on this list has dropped dramatically, but well, now I'm killing threads instead of messages. -Robert PS : I don't read complaints, I just trash'em, and when there are too many I respond something so that it stops (NOT !) PPS : your 286 story is wrong, you don't change the hw platform, try running dos 3.3 on a mac and that's more like it... ;-) > -----Original Message----- > From: Jeff Mcadams [SMTP:jeffm@iglou.com] > Sent: lundi, 8. mars 1999 17:00 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 3Com Problems. > > Thus spake K Mitchell > >At 04:18 PM 3/8/99 +0100, Robert von Bismarck <rvb@petrel.ch> wrote: > >>I'm kinda sick of reading all this junk about suing 3com and > blablabla... > >>Stop the whining. Did you also all whine as much when you found out your > old > >>286 wasn't able to run win95 ? > > > You're missing the whole point of their complaints. Their gripe isn't > >that a 286 won't run Win'95, the gripe is that they were promised that it > >would when they bought it, now it doesn't, and they're being told that > >their only option is to buy something else. > > It's not about the Netserver's capabilities, it's about the salesman or > >company misrepresenting the product and it's capabilities in order to > sell it. > > >At least that's what I inferred by actually reading the complaints. > > Actually...I'd go even further than that....its like being told that a > 286 would run DOS 3.3...which by all means it should be able to...and > then being told that to run DOS 3.3 we have to upgrade to a Pentium > because they can't fix DOS 3.3 on a 286 anymore. > -- > 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.

Look in the HiPer ARC documentation for NCSI. Go to http://www.networkproducts.com/ to download the client software. Works great for sharing a modem on the network. I tried to fax through it once, but there was a bug. I never checked to see if they fixed it in a later rev. -CH On Mon, 8 Mar 1999, Peter D. Mayer wrote: > Does anyone know of a way to share a quad or DSP modem over the network (i.e. > use it as a device under Windows) from a TCH? I thought I read somewhere that > you could do this, but I haven't been able to find any documentation to that > end. If you can't do this with TCH, can anyone recommend products that can? > > TIA for any info. > > Peter D. Mayer > NetWalk System Administrator > dmayer@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. >

Does anyone know of a way to share a quad or DSP modem over the network (i.e. use it as a device under Windows) from a TCH? I thought I read somewhere that you could do this, but I haven't been able to find any documentation to that end. If you can't do this with TCH, can anyone recommend products that can? TIA for any info. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

I have just installed our first set of DSP/ARC cards and have an issue with port numbers in the thousands. This would not bother me if it was 2000 - 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a decoder ring for this. Does any one have an idea what to do? I just upgraded to the newest code on the ARC and DSP's and did a reboot. Still no change. TIA Sean Herr @YourNET Connection, Inc. 847-524-3910 http://www.ync.net

On Mon, 8 Mar 1999, Sean Herr wrote: > I have just installed our first set of DSP/ARC cards and have an issue with > port numbers in the thousands. This would not bother me if it was 2000 - > 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a > decoder ring for this. Does any one have an idea what to do? I just > upgraded to the newest code on the ARC and DSP's and did a reboot. Still no > change. Port number = slot*256+modem, slots being numbered starting with 0, modems starting with 1.

I had the same problem when I first got an ARC ... I had a former 3Com tech show me how a port number is assigned ... I can probably get it if anyone is interested ... Something like (Slot# * 1024) - 256 ... Have a Great Day! Jamie Orzechowski RipNET System Admin Tel.: 613-342-3946 ext 293 Tel.: 800-267-4434 ext 293 Page.: 613-341-0883 EMail.: mhz@ripnet.com Web.: http://www.ripnet.com Personal.: http://www.moonchilli.com -----Original Message----- 'radiusnt@iea-software.com' <radiusnt@iea-software.com> >I have just installed our first set of DSP/ARC cards and have an issue with >port numbers in the thousands. This would not bother me if it was 2000 - >2100 but it spans from 1028 to 2365 to 3850 I am not about to build a >decoder ring for this. Does any one have an idea what to do? I just >upgraded to the newest code on the ARC and DSP's and did a reboot. Still no >change. > >TIA > >Sean Herr >@YourNET Connection, Inc. >847-524-3910 >http://www.ync.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. > >

There is a semi-sensible formula for this -- not sensible in the fact that you have to do this in the first place, but sensible in that you can get the slot #/channel # from it... In Perl: $portnum = $portname - 1000; $card = ($portnum >> 8); $chan = $portnum - ($card * 256); First, subtract 1000 (decimal). The lower 16 bits (8 bits, really) are the channel number. The next 8 bits up are the card number. (If you convert the port numbers into hex, it's a *lot* easier to figure this out...) Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!" On Mon, 8 Mar 1999, Sean Herr wrote: > I have just installed our first set of DSP/ARC cards and have an issue with > port numbers in the thousands. This would not bother me if it was 2000 - > 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a > decoder ring for this. Does any one have an idea what to do? I just > upgraded to the newest code on the ARC and DSP's and did a reboot. Still no > change.

On Mon, 8 Mar 1999, Brian wrote: > On Mon, 8 Mar 1999, Dan Hollis wrote: > > On Mon, 8 Mar 1999, matthew de Jongh wrote: > > > well i rec'vd a junk fax from dynavar this weekend that mentions the free > > > palm III > > Did you file in small claims court for dynavar's violation of USC Title 47 > > Sec. 227(b)(1)(C)? Under 227(b)(3)(B) youre entitled to $500. > > Make that the most expensive fax dynavar has ever sent B) > Every try to collect on that? I would be interested in hearing if anyones > put the law to the test. I get alot of junk faxes from VARs Heres one way you can go: http://x1.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=362567244&CONTEXT=920964009.1053818974&hitnum=0 -Dan

On Mon, 8 Mar 1999, Dan Hollis wrote: > On Mon, 8 Mar 1999, matthew de Jongh wrote: > > well i rec'vd a junk fax from dynavar this weekend that mentions the free > > palm III > > Did you file in small claims court for dynavar's violation of USC Title 47 > Sec. 227(b)(1)(C)? Under 227(b)(3)(B) youre entitled to $500. > > Make that the most expensive fax dynavar has ever sent B) > Dan, Every try to collect on that? I would be interested in hearing if anyones put the law to the test. I get alot of junk faxes from VARs > -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. > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

> if I've been rude, but I subscribed to this mailing-list for one thing > : Tech answers to tech problems. Hey, if you can give us a technical description of how to make MPIP work properly on a *NETserver* then we'll be all ears :-) Regards, Bob Purdon, Technical Manager, Southern Internet Services.

I have seen some weird problems with Webramps, particularly ones that have 3com Impact IQ modems as their ISDN TA. The problem is that after connecting the connection between the webramp and the HiperARC will 'freeze'. The connection doesn't drop and everything looks ok in terms on the bundle and links but no data moves in or out of the connection. It only takes around 15 minutes for this to happen. I am currently running 4.1.63 -6 and 1.2.60. What code does everyone recommend for best results with Webramps? I also read on a Webramp doc somewhere that they recommend using the command set ppp ccp_MODEMTYPE_ACCEPT none to turn off compression on the HiperARC. Has anybody done this and had success? Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700

well no, i actually didn't mind getting the fax, the bundles they had looked pretty good, i just hate coming in the office on sunday to feed the cats and finding our fax machine full of faxes from people i have never requested info from. between the boardwatch isp book and the damn hummer giveaways where you have to get stamped at 30 booths we get way too much junk mail, faxes and sales weasels calling on the phone. matthew At 12:09 PM 3/8/99 -0800, you wrote: >On Mon, 8 Mar 1999, matthew de Jongh wrote: >> well i rec'vd a junk fax from dynavar this weekend that mentions the free >> palm III > >Did you file in small claims court for dynavar's violation of USC Title 47 >Sec. 227(b)(1)(C)? Under 227(b)(3)(B) youre entitled to $500. > >Make that the most expensive fax dynavar has ever sent B) > >-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.

I've got a few customers using 3com Office Connect Hubs and they we're having problems with the PPP stack just dieing after about 5 minutes. I finially tracked it down to STAC compression... I dedicded to try a different device which supports STAC so I modify my Ascend Pipelin 75 and enable STAC and end up having the same problem. Anyone else had this problem? Thanks, Billy Huddleston Dataworld's Net-Express

On Tue, 9 Mar 1999, matthew de Jongh wrote: > between the boardwatch isp book and the damn hummer giveaways where you > have to get stamped at 30 booths we get way too much junk mail, faxes and > sales weasels calling on the phone. A $500 judgement against the sales weasels cant be a bad thing. I can think of lots of wonderful things to spend $500 on. -Dan

So far, 4.1.59-6 is working very well on the HiperArc, on a combination of 6 HiperDSP and Quad boxes. I was getting some problems with IP addresses not being released with 4.1.59-1, haven't seen that so far (fingers crossed). I didn't have problems with lost IP pools that Aaron Nabil experienced on the upgrade. I wrote them down and did one extra "save all" before rebooting witht the new code just to be sure. Now, if we can get a few more fixes in the HiperDSP code, we'll really be in business! Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com

Rather than mucking around with formulas and stuff, I've heard you can also do this: set pbus reported_port_density 24 This reportedly will number the ports in a more normal fashion, though I haven't tried it yet myself. It should number the ports so that slot 1 will be ports 1-24, slot 2 will be 25-48, etc. Keep in mind that if you have a quad in a slot, it will still number 24 ports for that card, but only the first 4 will be "real". So if you have a quad modem in slot 2, it will be numbered 25-28, a quad in slot 3 will be 49-52, etc. Hope this does the trick, let me know how it works as I'll probably try it myself in the next couple of weeks. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com ----- Original Message ----- Cc: <usr-tc@lists.xmission.com> Sent: Monday, March 08, 1999 8:35 PM >On Mon, 8 Mar 1999, Sean Herr wrote: > >> I have just installed our first set of DSP/ARC cards and have an issue with >> port numbers in the thousands. This would not bother me if it was 2000 - >> 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a >> decoder ring for this. Does any one have an idea what to do? I just >> upgraded to the newest code on the ARC and DSP's and did a reboot. Still no >> change. > >Port number = slot*256+modem, slots being numbered starting with 0, modems >starting with 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. >

seems to work for me ... Have a Great Day! Jamie Orzechowski RipNET System Admin Tel.: 613-342-3946 ext 293 Tel.: 800-267-4434 ext 293 Page.: 613-341-0883 EMail.: mhz@ripnet.com Web.: http://www.ripnet.com Personal.: http://www.moonchilli.com -----Original Message----- >Rather than mucking around with formulas and stuff, I've heard you can also do >this: > >set pbus reported_port_density 24 > >This reportedly will number the ports in a more normal fashion, though I haven't >tried it yet myself. It should number the ports so that slot 1 will be ports >1-24, slot 2 will be 25-48, etc. > >Keep in mind that if you have a quad in a slot, it will still number 24 ports >for that card, but only the first 4 will be "real". So if you have a quad modem >in slot 2, it will be numbered 25-28, a quad in slot 3 will be 49-52, etc. > >Hope this does the trick, let me know how it works as I'll probably try it >myself in the next couple of weeks. > >Peter D. Mayer >NetWalk System Administrator >dmayer@netwalk.com > >----- Original Message ----- >From: ROC Services <rocsoft@itol.com> >To: Sean Herr <Sean@YNC.NET> >Cc: <usr-tc@lists.xmission.com> >Sent: Monday, March 08, 1999 8:35 PM >Subject: Re: (usr-tc) DSP Port Numbers > > >>On Mon, 8 Mar 1999, Sean Herr wrote: >> >>> I have just installed our first set of DSP/ARC cards and have an issue with >>> port numbers in the thousands. This would not bother me if it was 2000 - >>> 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a >>> decoder ring for this. Does any one have an idea what to do? I just >>> upgraded to the newest code on the ARC and DSP's and did a reboot. Still no >>> change. >> >>Port number = slot*256+modem, slots being numbered starting with 0, modems >>starting with 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. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

I have just installed 4 hiper DSP (sw:1.1.93 E1/CAS), 1 ARC in a tcs hub (sw:4.1.1) , may problem is how come that almost all of the v.90 connections I have doesn't go beyond 33K if they do they get disconnected in a few sec ... also how do you set a connection x2 first then v.90 ? I hope you can help me on this Thanks Jobert

FYI - The reported issue of "lost IP pools" could be the result of the following: IP pools and static routes on the ARC are installed after the system has been booted for ~15-20 seconds. (Type "list ip pool" right after a boot at the prompt and you'll see that this is the case). Wait a bit, and you'll see the IP pools wink into existance. Anyhow, if you happen to perform a "save all" before the system has installed the IP pools, then you would possibly loose the pools. There is an open MR on this issue - MR9119. -- Matt "Randy Cosby" <dcosby@infowest.com> on 03/09/99 06:31:41 PM Please respond to usr-tc@lists.xmission.com cc: (Matt Harper/MW/US/3Com) So far, 4.1.59-6 is working very well on the HiperArc, on a combination of 6 HiperDSP and Quad boxes. I was getting some problems with IP addresses not being released with 4.1.59-1, haven't seen that so far (fingers crossed). I didn't have problems with lost IP pools that Aaron Nabil experienced on the upgrade. I wrote them down and did one extra "save all" before rebooting witht the new code just to be sure. Now, if we can get a few more fixes in the HiperDSP code, we'll really be in business! Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.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.

This is a multi-part message in MIME format. ------=_NextPart_000_0023_01BE6A74.FE3E5100 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, We just upgraded from Netserver based code relase 2.5.1 to HyperArc = release 3.3.3 And now we are getting tons of disconnects. Within 30 = seconds or less of logging on. 90% of the quickly disconnected users = show V42Disconect(42) command while 10% show GatewayDisconnect(62) = Mostly USR modems Sportsters a few Courier and few Sportster Winmodems. = ISDN clients work great. We have the latest code on the Quads, they were running 5.1.7 now 5.10.9 = ,NMC is 5.5.5 with the inculded mem upgrade. and the HyperArc is the = latest 4.1.59 -6, though on chassiy inventory the -6 is missing. Before we upgraded we put the PRI's out of service, onhooked offhooked = the modem's and set all the Quads to "default" then saved to NVRAM and = rebooted. Any Ideas? ------=_NextPart_000_0023_01BE6A74.FE3E5100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Hi all,</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>We just upgraded from Netserver based code relase = 2.5.1 to=20 HyperArc release 3.3.3 And now we are getting tons of disconnects. = Within 30=20 seconds or less of logging on. 90% of the quickly disconnected&nbsp; = users show=20 V42Disconect(42) command while 10% show GatewayDisconnect(62) Mostly USR = modems=20 Sportsters a few Courier and few Sportster Winmodems. ISDN clients work=20 great.</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>We have the latest code on the Quads, they were = running 5.1.7=20 now 5.10.9 ,NMC is 5.5.5 with the inculded mem upgrade. and the HyperArc = is the=20 latest 4.1.59 -6, though on chassiy inventory the -6 is = missing.</FONT></DIV> <DIV>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>Before we upgraded we put the PRI's = out of=20 service, onhooked offhooked the modem's and set all the Quads to=20 &quot;default&quot; then saved to NVRAM and rebooted. Any = Ideas?</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV>&nbsp;</DIV></BODY></HTML> ------=_NextPart_000_0023_01BE6A74.FE3E5100--

Has anyone seen any problems with the USR Accounting Reports with regards to Duration time timing? I've been looking over some of our "high hours" clients, and noticed a lot of overlapping times, even though they're from the same phone number. I'm adding the Duration time to the connect time (by hand!) to get a disconnect time. Some of our clients are clearly logging in concurrently from two computers if these times are correct. We're running Security, Accounting, radius server version 4.3 from USR. The report is a new layout. The "Duration" formula was copied from the example "Sample Billing" report provided by USR. Thanks! Steve

Does anybody have any experience using hiper platform to dial out, using telnet? We have an application that reqires 7 bit Even Parity and right now we got Netserver 8I for this purpose (only has 8 bit no parity). The main problem is if telnet session gets closed before the modem disconnects the modem interface is being reported as in use, but Netserver would let you to telnet to that modem again even it's not usable until you reset that interface from CLI. How the Hiper Arc works in this case, would the modem drop the connection if telnet session is broken, and is there such thing as round-robin dialout within one modem group? Thanks! Yevgeniy

Once upon a time Pete Ashdown shaped the electrons to say... >I was interested to see that MPPP now has a global switch. What is the >proper Framed-Protocol to use for MPPP? I have a customer who is Framed-Protocol = PPP Anything else is not RFC compliant. If you don't want to allow multiple ports, then add: Port-Limit = 1 -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Robert von Bismarck shaped the electrons to say... >The PM2-30 sitting in the closet is a 30 port. It's got an AMD Am386dx-40 >and a mind-boggling 4 megs of RAM. > >Well it's an OEM by Cayman Systems, called "GatorAccess" but the mboard is >definitely marked Livingston. They're all but identical - different ROM. In fact, back around 1995 when Cayman got all messed up, Livingston offered a 'refurb/upgrade' for around $900 where they'd take the unit, clean it, test it, swap out the ROM, and ship it back with Livingston support, warranty, etc. I don't know if they'd still do that. The PM-3 can do 3 T1 (2 on the main board, and a WAN card) and it has a 486DX2-66 as I recall, and 4MB of RAM. And it'll do OSPF. Give it 16MB or more and it'll do BGP happily. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Robert von Bismarck shaped the electrons to say... >also happens with servers, even with NAS's. The 486 has outlived it's life, >welcome to the PPC. But this is BULLSHIT. Wake up - the NetServer *HARDWARE* has plenty of power, as long as the OS isn't crap. They only need a PPC because Pilgrim isn't efficient enough to use the 486-100. A PPC is overpriced, overkill for a small-to-medium NAS. And that is what many people need - now AND tomorrow. If you think xDSL, etc, is going to be ubiquitous tomorrow, you're high. Modems/ISDN will remain for a number of years. And spending money on unnecessary hardware for a rural POP is bad business, anyway you slice it. The NetServer TCs could server on for many years yet - if only 3Com knew how to code an OS. But just look at how bad the bloated ComOS by the end. It was bigger than the original, took 4 times the RAM, and did LESS. >Upgrade is the power-word. In the ISP business it's "do or die". You want to This is moronic. You could also use a vendor who knows how to write an OS and doesn't bloat it so fast they ARTIFICIALLY obsolete perfectly good HW. It sure sounds like you've been brainwashed by the M$/Intel mentality. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Charles Hill shaped the electrons to say... >I've heard the rumor about 3Com offloading the Total Control unit a few >times now, so I'm starting to believe it. This Siemens story makes me >think it's going to happen. Sounds reasonable. Nortel grabbed Aptis and Bay, Lucent grabbed Livingston and Ascend, Ericsson grabbed ACC, Alcatel just grabbed Assured Access. Why not Siemens going after 3Com, or part thereof? Don't they already make a VOIP gateway based on the HiPer? >I hope the deal is beneficial for everyone. Maybe Siemens will commit >more resources to developing the Total Control products than 3Com has. >Higher density and DS3 ingress would be nice. Do you think they can re-double the density for T3? -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time d baud shaped the electrons to say... >Now this is great, but I need to use this for particular users from >RADIUS, so I added in the dictionnary the following: >ATTRIBUTE IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr You're doing the wrong thing. This is NOT a RADIUS attribute, this is a Vendor Specific Attribute. So: 1. You need a RADIUS server that not only understands VSAs, but that understands 3Com's oddball format. (3Com chose not to follow the format recommended by the RFC, so some VSA supporting servers still don't do 3Com VSAs.) 2. You need to enter this into the RADIUS server's dictionary in the format that server uses for VSAs. As a tip, the free Cistron RADIUS server does support 3Com VSAs. >Oh BTW for those who don't know what IEA is, it stands for Internet That's going to be so annoying, as IEA Software is a major RADIUS server vendor - with RadiusNT and Emerald. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Robert von Bismarck shaped the electrons to say... > Even the PM2 does BGP... but it's BGP3 which is pretty useless. The PM-2 does RIP and OSPFv2 with NSSA. No BGP. The only PortMaster products which do BGP are the PM-3, PM-4, and IRX. All do BGP4. Actually, the implementation supports many of the supplimental RFCs, and some of the draft material for BGP5. All PortMasters (well, except for the ancient PM-11 and IR4) support RIPv1 and OSPFv2 with NSSA, the above three do BGP as well. Lucent is adding RIPv2 to the PM-4 in ComOS 4.1, a reversal on Livingston's stance on supporting OSPF but not RIPv2 since OSPF is superior. No definite word yet on if that means the other products will also receive RIPv2 in 3.9. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Same here on my WebRamp 310i. It is worse with VJ and/or stac turned on in the WebRamp. Running 4.1.59-6 ARC 4.1.59 DSP. Mark Lemmert wrote: > > I have seen some weird problems with Webramps, particularly > ones that have 3com Impact IQ modems as their ISDN TA. > > The problem is that after connecting the connection between > the webramp and the HiperARC will 'freeze'. The connection > doesn't drop and everything looks ok in terms on the bundle > and links but no data moves in or out of the connection. > It only takes around 15 minutes for this to happen. > > I am currently running 4.1.63 -6 and 1.2.60. What code > does everyone recommend for best results with Webramps? > > I also read on a Webramp doc somewhere that they recommend > using the command set ppp ccp_MODEMTYPE_ACCEPT none to turn > off compression on the HiperARC. Has anybody done this and > had success? > > Mark Lemmert AthEnet Data Exchange > Chief Technical Officer 888-919-8700 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Robert von Bismarck wrote: > Disabled Modules: OSPF BGP > SBL-PM1> version > Livingston PortMaster PM-2e ComOS 3.7.2 > System uptime is 126 days 16 hours 3 minutes > SBL-PM1> exit > > Why mention it, if it's not inside or planned ? (I never tried to use it as > it would have been pretty useless for me) ComOS uses a common code base. -- Thomas C Kinnen - <tkinnen@ra.lucent.com> <tkinnen@sobhrach.com> [RADIUS Test Engineer] - LUCENT Technologies RABU "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer"

BGP4 didn't exist way back then :-) On Wed, 10 Mar 1999, Robert von Bismarck wrote: > Even the PM2 does BGP... but it's BGP3 which is pretty useless. >

On Tue, 9 Mar 1999, MegaZone wrote: > 2. You need to enter this into the RADIUS server's dictionary in the > format that server uses for VSAs. > > As a tip, the free Cistron RADIUS server does support 3Com VSAs. O.K... the muddy water is starting to clear here... We run an OS/2 port of Cistron RADIUS (easy access to our DB2 server). I tried setting up 3Com's VSA's in my dictionary file, using the complaints RADIUS had when it encountered an unknown attribute. My dictionary.3com: ATTRIBUTE Vendor-Specific 26 string ATTRIBUTE Acct-Multi-Session-ID 50 string ATTRIBUTE Acct-Link-Count 51 string I used to have more, as specificed in 3Com's RADIUS guide... but they were never used, and they got tossed out during an upgrade long ago. However, the attributes still come up null: Mon Mar 8 16:08:27 1999 User-Name = "steve" NAS-IP-Address = 209.101.140.2 Acct-Status-Type = Start Acct-Session-Id = "2558" Acct-Delay-Time = 0 Acct-Authentic = RADIUS Service-Type = Framed-User NAS-Port-Type = Async NAS-Port-Id = 1796 Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Calling-Station-Id = "6095550773" Called-Station-Id = "5555555" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Vendor-Specific = "" Framed-Protocol = PPP Framed-IP-Address = 209.101.140.23 Timestamp = 920927307 Request-Authenticator = Unverified Is there something else I need to add to my dictionary to reveal these VSAs? Is the info in these VSAs useful? I can't imagine it is not... ;-) Thanx in advance. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

On Wed, 10 Mar 1999, Matthew Opoka wrote: > Same here on my WebRamp 310i. It is worse with VJ and/or stac turned on > in the WebRamp. Running 4.1.59-6 ARC 4.1.59 DSP. > Do a show ppp on the hiper arc Make sure that you have ppp offloading enabled Make sure that ppp receive_accm is disabled. Make sure that ppp ccp is set to all Make sure header comprssion is on on the hiper arc This will solve your problem. krish > > Mark Lemmert wrote: > > > > I have seen some weird problems with Webramps, particularly > > ones that have 3com Impact IQ modems as their ISDN TA. > > > > The problem is that after connecting the connection between > > the webramp and the HiperARC will 'freeze'. The connection > > doesn't drop and everything looks ok in terms on the bundle > > and links but no data moves in or out of the connection. > > It only takes around 15 minutes for this to happen. > > > > I am currently running 4.1.63 -6 and 1.2.60. What code > > does everyone recommend for best results with Webramps? > > > > I also read on a Webramp doc somewhere that they recommend > > using the command set ppp ccp_MODEMTYPE_ACCEPT none to turn > > off compression on the HiperARC. Has anybody done this and > > had success? > > > > Mark Lemmert AthEnet Data Exchange > > Chief Technical Officer 888-919-8700 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

On Wed, 10 Mar 1999, Matthew Opoka wrote: > Same here on my WebRamp 310i. It is worse with VJ and/or stac turned on > in the WebRamp. Running 4.1.59-6 ARC 4.1.59 DSP. > Do a show ppp on the hiper arc Make sure that you have ppp offloading enabled Make sure that ppp receive_accm is disabled. Make sure that ppp ccp is set to all Make sure header comprssion is on on the hiper arc This will solve your problem. krish > > Mark Lemmert wrote: > > > > I have seen some weird problems with Webramps, particularly > > ones that have 3com Impact IQ modems as their ISDN TA. > > > > The problem is that after connecting the connection between > > the webramp and the HiperARC will 'freeze'. The connection > > doesn't drop and everything looks ok in terms on the bundle > > and links but no data moves in or out of the connection. > > It only takes around 15 minutes for this to happen. > > > > I am currently running 4.1.63 -6 and 1.2.60. What code > > does everyone recommend for best results with Webramps? > > > > I also read on a Webramp doc somewhere that they recommend > > using the command set ppp ccp_MODEMTYPE_ACCEPT none to turn > > off compression on the HiperARC. Has anybody done this and > > had success? > > > > Mark Lemmert AthEnet Data Exchange > > Chief Technical Officer 888-919-8700 > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Even the PM2 does BGP... but it's BGP3 which is pretty useless. > -----Original Message----- > From: MegaZone [SMTP:megazone@megazone.org] > Sent: mercredi, 10. mars 1999 08:26 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 3Com Problems. > > The PM-3 can do 3 T1 (2 on the main board, and a WAN card) and it has a > 486DX2-66 as I recall, and 4MB of RAM. And it'll do OSPF. Give it > 16MB or more and it'll do BGP happily. > > -MZ > -- > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> > X*=- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, > me.. > Join ISP/C Internet Service Providers' Consortium > <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest men" > 781-788-0130 > <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail > Discordia! > >

ok. Our opinions differ and that's fine. Let me explain the situation I live with so you'll understand my points better. We have 107 "virtual" PoPs provided by our telco. This means that we have 107 local numbers for 107 different tariff zones. All the numbers are forwarded to two "MegaPoPs" in which we store our equipment. We have 700 ports in one location, and 300 in another. We do not have any other Pop with dial-up access. We do have other Pops for Frame-Relay, DSL and snych leased lines. I think that this kind of "back-hauling" telephone calls will become more and more used by everyone (be it carriers, ISP, etc...). I don't know if this kind of operation is possible in the states, or elsewhere (I know for example that it's impossible to do in France). This has lots of advantages and disadvantages versus smaller PoP's : - All the equipment is in a few locations, you don't have to travel miles to reboot a board - The modems are better used - If one board fails, there's not one Pop that'll sound busy, but only one ring in twenty - You don't need multiple leased lines going to one central site, you just order 10M/s of ATM to your internet access and you're fine. - As your megapop is in the telco's racks, you're right next door to their engineers, who can help if you got trouble with protocol analyzers, etc... - The equipment is all on the same switch, if that fails, you're out of business for a while - There's only one line going out, if that fails, you're in trouble - There's one big router, failure = trouble (better have those smartnet 24/7 contracts ready) - Insurance is lighter (only one building, and you share costs with the telco) - There's only two UPS's per POP (thank God for redundant Power Supplies) With this trend, I see no more use for small Pops with 30 or so lines except as RAS service for the employees of a big company, or a very local ISP who'll probably have not very many customers, and a very limited Net access (remember the BBS's of old...). I believe the garage-family-business ISP time is over in Europe. I'm not really aware of what the situation is like in the USA, but I don't think it's really very different. This is the situation, and I hope you now understand why I think the Netserver has outlived it's useful life (even with bloated OS and blablabla) Robert PS : I have not been brainwashed by M$/Intel (even though we use MS Exchange for e-mail). Our production equipment is not running MS or Intel stuff except Frontpage server extensions ;-) > -----Original Message----- > From: MegaZone [SMTP:megazone@megazone.org] > Sent: mercredi, 10. mars 1999 08:32 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 3Com Problems. > > Once upon a time Robert von Bismarck shaped the electrons to say... > >also happens with servers, even with NAS's. The 486 has outlived it's > life, > >welcome to the PPC. > > But this is BULLSHIT. Wake up - the NetServer *HARDWARE* has plenty of > power, as long as the OS isn't crap. They only need a PPC because Pilgrim > isn't efficient enough to use the 486-100. > > A PPC is overpriced, overkill for a small-to-medium NAS. And that is what > many people need - now AND tomorrow. If you think xDSL, etc, is going to > be ubiquitous tomorrow, you're high. Modems/ISDN will remain for a number > of years. And spending money on unnecessary hardware for a rural POP is > bad business, anyway you slice it. The NetServer TCs could server on > for many years yet - if only 3Com knew how to code an OS. But just look > at how bad the bloated ComOS by the end. It was bigger than the original, > took 4 times the RAM, and did LESS. > > >Upgrade is the power-word. In the ISP business it's "do or die". You want > to > > This is moronic. You could also use a vendor who knows how to write an > OS and doesn't bloat it so fast they ARTIFICIALLY obsolete perfectly good > HW. It sure sounds like you've been brainwashed by the M$/Intel > mentality. > > -MZ > -- > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> > X*=- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, > me.. > Join ISP/C Internet Service Providers' Consortium > <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest men" > 781-788-0130 > <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail > Discordia! > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Huh ? explain this to me then, (it's an old PM2-e refurbished cayman we use for RS-232 console access) ComOS - Livingston PortMaster login: !root Password: SBL-PM1> sh glo [ lots of config stuff deleted ] Disabled Modules: OSPF BGP SBL-PM1> version Livingston PortMaster PM-2e ComOS 3.7.2 System uptime is 126 days 16 hours 3 minutes SBL-PM1> exit Why mention it, if it's not inside or planned ? (I never tried to use it as it would have been pretty useless for me) Robert > -----Original Message----- > From: MegaZone [SMTP:megazone@megazone.org] > Sent: mercredi, 10. mars 1999 10:25 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) 3Com Problems. > > Once upon a time Robert von Bismarck shaped the electrons to say... > > Even the PM2 does BGP... but it's BGP3 which is pretty useless. > > The PM-2 does RIP and OSPFv2 with NSSA. No BGP. > > The only PortMaster products which do BGP are the PM-3, PM-4, and IRX. > All do BGP4. Actually, the implementation supports many of the > supplimental RFCs, and some of the draft material for BGP5. > > All PortMasters (well, except for the ancient PM-11 and IR4) support RIPv1 > and OSPFv2 with NSSA, the above three do BGP as well. Lucent is adding > RIPv2 to the PM-4 in ComOS 4.1, a reversal on Livingston's stance on > supporting OSPF but not RIPv2 since OSPF is superior. No definite word > yet on if that means the other products will also receive RIPv2 in 3.9. > > -MZ > -- > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> > X*=- > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, > me.. > Join ISP/C Internet Service Providers' Consortium > <URL:http://www.ispc.org/> > "A little nonsense now and then, is relished by the wisest men" > 781-788-0130 > <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail > Discordia! > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Ok just for the record, I re-checked my settings and it turned out that I did a typo in the dictionary entry. so the problem is fixed and IEA is working properly. The monitor ppp and monitor radius commands helped alot in debugging this silly error. and I would like to share with the list the very helpfull undocumented CLI command: _auth username password This will "fake" a login connection to the HARC and will actually authenticate the user as if it was a regular call. d baud > > I am trying to use the new IEA feature in the 4.1.59-6 HARC code. I > managed to use it with local non-radius users: > set network usr my_local_user IP IEA_NEXT_HOP_GATEWAY 192.0.0.1 > > Now this is great, but I need to use this for particular users from > RADIUS, so I added in the dictionnary the following: > ATTRIBUTE IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr > > And I added to my "users" file the entry > IEA_NEXT_HOP_GATEWAY = 192.0.0.1, > > The RADIUS users still pick the defaultroute :( > I tried to monitor the connection with "mon radius" on the HARC but it > does not seem to report any VSA attributes anyway. > > Oh BTW for those who don't know what IEA is, it stands for Internet > Equal Access and it is used to specify a different gateway than the > defaultroute. > > D. Baud

What is the consensus opinion of leaving Selective Reject enabled on the quads? The default setting is enabled when you restore a quad from defaults, but not on the HDMs. Does it cause more problems than it helps? Jim

This is a multi-part message in MIME format. ------=_NextPart_000_013D_01BE6B02.91B1AE40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been trying to set up a way for users whose modems won't = negotiate with the v.90 code on our quad modems to call a number other = than our huntgroup lead number and then based on that DNIS number limit = the modem to v.34 speeds. So far it hasn't worked (it still connects at = v.90 speeds). I am getting the DNIS digits, but perhaps my init strings = were not correct. Any help would be apreciated. Randy McMillan PacInfo ------=_NextPart_000_013D_01BE6B02.91B1AE40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 face=3DArial size=3D2>I have been trying to = set up a way=20 for users whose modems won't negotiate with the v.90 code on our quad = modems to=20 call a number other than our huntgroup lead number and then based on = that DNIS=20 number limit the modem to v.34 speeds.&nbsp; So far it hasn't worked (it = still=20 connects at v.90 speeds).&nbsp; I am getting the DNIS digits, but = perhaps my=20 init strings were not correct.&nbsp; Any help would be = apreciated.</FONT></DIV> <DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 face=3DArial size=3D2>Randy = McMillan</FONT></DIV> <DIV><FONT color=3D#000000 face=3DArial = size=3D2>PacInfo</FONT></DIV></BODY></HTML> ------=_NextPart_000_013D_01BE6B02.91B1AE40--

I was wondering if there was any easy fix for getting 3Com Impact IQ ISDN "modems" to connect to the Quad cards? I have a chassis with the Dual T1/12 Quads/ARC and NMC setup, and the Impact absolutely refuses to connect. All firmware is current (even 4.1.59-6). On my Hiper chassis, the Impact connects to the DSPs without a glitch. It also has all current firmware. Thanx in advance. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

This is a multi-part message in MIME format. ------=_NextPart_000_01B1_01BE6B0F.0FB73920 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am using quad modems and hiper ARC card. The telco is passing 4 = digits, the modem "call control" options are set for 4 DNIS digits, and = those digits are in the modem "DNIS access codes". The init strings I = have tried with no luck are: ATS76.0=3D0S81.4=3D0S81.5=3D0S81.6=3D0 ATS32=3D98 AT&N21 Do they look right or wrong to you? I am not positive that they are = actually being executed, and not sure of a way to check. Randy McMillan PacInfo -----Original Message----- strings? <snip> >So, I can't be of much help now, but I will be posting my results >here. > >Couple of things I'd investigate in your position tho...make sure >that you're getting all the dnis digits, or if you're getting a >subset, make sure it's the same in your hdsp config. And definately >verify your init strings of course.... > >Lon Stockton >MoonStar > > >On Wed, 10 Mar 1999, Randy McMillan wrote (without any word wrap): > >> I have been trying to set up a way for users whose modems won't >> negotiate with the v.90 code on our quad modems to call a number >> other than our huntgroup lead number and then based on that DNIS >> number limit the modem to v.34 speeds. So far it hasn't worked >> (it still connects at v.90 speeds). I am getting the DNIS digits, >> but perhaps my init strings were not correct. Any help would be >> apreciated. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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_01B1_01BE6B0F.0FB73920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY> <DIV> <DIV>I am using quad modems and hiper ARC card.&nbsp; The telco is = passing 4=20 digits, the modem &quot;call control&quot; options are set for 4 DNIS = digits,=20 and those digits are in the modem &quot;DNIS access codes&quot;.&nbsp; = The init=20 strings I have tried with no luck are:</DIV> <DIV>ATS76.0=3D0S81.4=3D0S81.5=3D0S81.6=3D0</DIV> <DIV>ATS32=3D98</DIV> <DIV>AT&amp;N21</DIV> <DIV>Do they look right or wrong to you?&nbsp; I am not positive that = they are=20 actually being executed, and not sure of a way to check.<BR></DIV> <DIV>&nbsp;</DIV> <DIV><FONT color=3D#000000 face=3DArial size=3D2>Randy = McMillan</FONT></DIV> <DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT><FONT = face=3DArial=20 size=3D2>PacInfo</FONT></DIV> <DIV>&nbsp;</DIV></DIV> <DIV><FONT face=3DArial size=3D2>-----Original Message-----<BR>From: Lon = R.=20 Stockton, Jr. &lt;<A=20 href=3D"mailto:lon@moonstar.com">lon@moonstar.com</A>&gt;<BR>To: <A=20 href=3D"mailto:usr-tc@lists.xmission.com">usr-tc@lists.xmission.com</A> = &lt;<A=20 href=3D"mailto:usr-tc@lists.xmission.com">usr-tc@lists.xmission.com</A>&g= t;<BR>Date:=20 Wednesday, March 10, 1999 3:21 PM<BR>Subject: Re: (usr-tc) Is there a = way to=20 disable x2/v.90 with DNIS init strings?<BR><BR></FONT></DIV> <DIV>&lt;snip&gt;</DIV> <DIV>&gt;So, I can't be of much help now, but I will be posting my=20 results<BR>&gt;here.<BR>&gt;<BR>&gt;Couple of things I'd investigate in = your=20 position tho...make sure<BR>&gt;that you're getting all the dnis digits, = or if=20 you're getting a<BR>&gt;subset, make sure it's the same in your hdsp = config. And=20 definately<BR>&gt;verify your init strings of course....</DIV> <DIV>&nbsp;</DIV> <DIV>&nbsp;</DIV> <DIV>&gt;<BR>&gt;Lon Stockton<BR>&gt;MoonStar<BR>&gt;<BR>&gt;<BR>&gt;On = Wed, 10=20 Mar 1999, Randy McMillan wrote (without any word = wrap):<BR>&gt;<BR>&gt;&gt; I=20 have been trying to set up a way for users whose modems = won't<BR>&gt;&gt;=20 negotiate with the v.90 code on our quad modems to call a = number<BR>&gt;&gt;=20 other than our huntgroup lead number and then based on that = DNIS<BR>&gt;&gt;=20 number limit the modem to v.34 speeds.&nbsp; So far it hasn't = worked<BR>&gt;&gt;=20 (it still connects at v.90 speeds).&nbsp; I am getting the DNIS=20 digits,<BR>&gt;&gt; but perhaps my init strings were not correct.&nbsp; = Any help=20 would be<BR>&gt;&gt; apreciated.<BR>&gt;<BR>&gt;<BR>&gt;-<BR>&gt; To = unsubscribe=20 to usr-tc, send an email to &quot;<A=20 href=3D"mailto:majordomo@xmission.com">majordomo@xmission.com</A>&quot;<B= R>&gt;=20 with &quot;unsubscribe usr-tc&quot; in the body of the message.<BR>&gt; = For=20 information on digests or retrieving files and old messages send<BR>&gt; = &quot;help&quot; to the same address.&nbsp; Do not use quotes in your=20 message.<BR>&gt;</DIV></BODY></HTML> ------=_NextPart_000_01B1_01BE6B0F.0FB73920--

This is a multi-part message in MIME format. ------=_NextPart_000_0003_01BE6B14.31ED3620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit I've done something similar, but from the opposite end. I just have the user disable the V.90 on their end. This usually works fine for us. John C Hill II North East Texas Internet -----Original Message----- From: owner-usr-tc@lists.xmission.com [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy McMillan Sent: Wednesday, March 10, 1999 4:31 PM To: usr-tc@xmission.com Subject: (usr-tc) Is there a way to disable x2/v.90 with DNIS init strings? I have been trying to set up a way for users whose modems won't negotiate with the v.90 code on our quad modems to call a number other than our huntgroup lead number and then based on that DNIS number limit the modem to v.34 speeds. So far it hasn't worked (it still connects at v.90 speeds). I am getting the DNIS digits, but perhaps my init strings were not correct. Any help would be apreciated. Randy McMillan PacInfo ------=_NextPart_000_0003_01BE6B14.31ED3620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><SPAN class=3D480353522-10031999><FONT color=3D#0000ff face=3DArial = size=3D3>I've=20 done something similar, but from the opposite end. I just have the user = disable=20 the V.90 on their end. This usually works fine for = us.</FONT></SPAN></DIV> <DIV>&nbsp;</DIV><BR> <P><FONT face=3DArial size=3D2>John C Hill II</FONT> <BR><FONT = face=3DArial=20 size=3D2>North East Texas Internet</FONT> </P><BR> <DIV>&nbsp;</DIV> <BLOCKQUOTE> <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20 size=3D2>-----Original Message-----<BR><B>From:</B>=20 owner-usr-tc@lists.xmission.com=20 [mailto:owner-usr-tc@lists.xmission.com]<B>On Behalf Of</B> Randy=20 McMillan<BR><B>Sent:</B> Wednesday, March 10, 1999 4:31 = PM<BR><B>To:</B>=20 usr-tc@xmission.com<BR><B>Subject:</B> (usr-tc) Is there a way to = disable=20 x2/v.90 with DNIS init strings?<BR><BR></FONT></DIV> <DIV><FONT color=3D#000000 face=3DArial size=3D2>I have been trying = to set up a=20 way for users whose modems won't negotiate with the v.90 code on our = quad=20 modems to call a number other than our huntgroup lead number and = then based=20 on that DNIS number limit the modem to v.34 speeds.&nbsp; So far it = hasn't=20 worked (it still connects at v.90 speeds).&nbsp; I am getting the = DNIS=20 digits, but perhaps my init strings were not correct.&nbsp; Any help = would=20 be apreciated.</FONT></DIV> <DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 face=3DArial size=3D2>Randy = McMillan</FONT></DIV> <DIV><FONT color=3D#000000 face=3DArial=20 size=3D2>PacInfo</FONT></DIV></BLOCKQUOTE></BODY></HTML> ------=_NextPart_000_0003_01BE6B14.31ED3620--

There is some good software at www.tsmon.com that we use. We had about 20% of the subscribers that were using (abusing) the system in some fashion. Twas much higher than I thought and the program merrily keeps kicking them off every couple of minutes. Works well and I know of no other option. I think its around $600 for 3 pops and $25 per pop after that. We use it on our TC's and some netserver 16's with no problem. At 07:04 PM 3/10/99 -0500, you wrote: > I am just wondering about port limits. I still want to allow for >multilink PPP though sp that if there radius attribute of Port-Limit = 2 >they will be allowed multilink. "" but then I noticed that some people >we logged in multiple times ... any ideas?? is this possible on >netserver also?? >--------------------------------------------------- >Have a Great Day! Jamie Orzechowski >RipNET System Admin Tel.: 613-342-3946 ext 293 >Tel.: 800-267-4434 ext 293 >Page.: 613-341-0883 >EMail.: mhz@ripnet.com >Web.: http://www.ripnet.com >Personal.: http://www.moonchilli.com >--------------------------------------------------- Thanks, Greg Coffey, CoffeyNet Voice 307-234-5443 307-234-5446 Fax ==================================================================== 142 S. Center St. 3Com v.90 56k $20 in Casper & Douglas Casper, WY 82601 Local Internet for Casper, Rawlins, Douglas, http://WWW.COFFEY.COM Wheatland, Pinedale, Lander & Lusk, WY

John, I like your solution and I'm curious... are you using "AT&F0S38=0" or something else on the customer end? Michael Ezzell The Austin Consultant Group Oklahoma City, Oklahoma -----Original Message----- Sent: Wednesday, March 10, 1999 4:37 PM strings? I've done something similar, but from the opposite end. I just have the user disable the V.90 on their end. This usually works fine for us. John C Hill II North East Texas Internet -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy McMillan Sent: Wednesday, March 10, 1999 4:31 PM I have been trying to set up a way for users whose modems won't negotiate with the v.90 code on our quad modems to call a number other than our huntgroup lead number and then based on that DNIS number limit the modem to v.34 speeds. So far it hasn't worked (it still connects at v.90 speeds). I am getting the DNIS digits, but perhaps my init strings were not correct. Any help would be apreciated. Randy McMillan PacInfo

It depends on what type of modem they are using. I fist find out what the chipset is. Usually you can do this by going to Modems in Control Panel (Win95 & Win98). If you click on the Diagnostics tab and then select the modem, then click on the button that says More Info. Usually somewhere is the chipset of the modem. After learning this info, I found a WebPages that tells the init string to disable either V.90, X2, or KFlex. The URL is http://www.56k.com/trouble/interop.shtml . Another good WebPages is http://www.v90stuff.com/ . Hope this helps. If not, let me know. John C Hill II North East Texas Internet -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael E. Ezzell Sent: Wednesday, March 10, 1999 5:09 PM strings? John, I like your solution and I'm curious... are you using "AT&F0S38=0" or something else on the customer end? Michael Ezzell The Austin Consultant Group Oklahoma City, Oklahoma -----Original Message----- Sent: Wednesday, March 10, 1999 4:37 PM strings? I've done something similar, but from the opposite end. I just have the user disable the V.90 on their end. This usually works fine for us. John C Hill II North East Texas Internet -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy McMillan Sent: Wednesday, March 10, 1999 4:31 PM I have been trying to set up a way for users whose modems won't negotiate with the v.90 code on our quad modems to call a number other than our huntgroup lead number and then based on that DNIS number limit the modem to v.34 speeds. So far it hasn't worked (it still connects at v.90 speeds). I am getting the DNIS digits, but perhaps my init strings were not correct. Any help would be apreciated. 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.

Based on an idea I mentioned a couple of threads ago, I'm currently working on setting this up and getting it tested; am waiting on the telco to point another number at my head-of-huntgroup line (they say it'll take 'em till Friday 19th to do it *roll* Yes, I told 'em that if they gave me dialup access to their switch I could do it in the time it took me to ask them. Of course, they thought I was pretty good at being a comedian). The basic idea is to have two configurations...one with all the bells and whistles, and one that's more a generic work-with-anything configuration with no 56k or v.42bis, etc. If a customer has trouble with our main number (which is configged to kick ass for the ones who have fancy modems that actually work), they just try our secondary number (which is configged to get anything connected, including me whistling a 300bps carrier). Sure, one can get the customer to turn it all off on their end (as we currently do), but I don't like that solution. It requires the customer to have to learn too much about modems for one. And the killer is the amount of time tech support is online with someone's mom trying to get her to type strange things in a strange panel (something she *never* had to do when she was with AOL, she'll remind you). So getting the customer to turn it off is *lame*. Anything I can do to avoid it must be attempted. If I succeed, I fully expect higher customer satisfaction and yet another stick I can smack my competition with. So, I can't be of much help now, but I will be posting my results here. Couple of things I'd investigate in your position tho...make sure that you're getting all the dnis digits, or if you're getting a subset, make sure it's the same in your hdsp config. And definately verify your init strings of course.... Lon Stockton MoonStar On Wed, 10 Mar 1999, Randy McMillan wrote (without any word wrap): > I have been trying to set up a way for users whose modems won't > negotiate with the v.90 code on our quad modems to call a number > other than our huntgroup lead number and then based on that DNIS > number limit the modem to v.34 speeds. So far it hasn't worked > (it still connects at v.90 speeds). I am getting the DNIS digits, > but perhaps my init strings were not correct. Any help would be > apreciated.

This is a multi-part message in MIME format. ------=_NextPart_000_0013_01BE6B28.DC9B9440 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am just wondering about port limits. I want to set my ARC up so that ONLY 1 userID can be logged in at once. = I still want to allow for multilink PPP though sp that if there radius = attribute of Port-Limit =3D 2 they will be allowed multilink. I tried a "set user default port_limit 1" but then I noticed that some = people we logged in multiple times ... any ideas?? is this possible on netserver also?? Have a Great Day! Jamie Orzechowski RipNET System Admin Tel.: 613-342-3946 ext 293 Tel.: 800-267-4434 ext 293 Page.: 613-341-0883 EMail.: mhz@ripnet.com Web.: http://www.ripnet.com Personal.: http://www.moonchilli.com ------=_NextPart_000_0013_01BE6B28.DC9B9440 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML> <HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 = HTML//EN"> <META content=3D'"MSHTML 4.72.3612.1700"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>I am just wondering about port=20 limits.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>I want to set my ARC up so that ONLY 1 userID can be = logged in=20 at once.&nbsp; I still want to allow for multilink PPP though sp that if = there=20 radius attribute of Port-Limit =3D 2 they will be allowed = multilink.</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>I tried a &quot;set user default port_limit 1&quot; = but then I=20 noticed that some people we logged in multiple times ... any=20 ideas??</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>is this possible on netserver also??</FONT></DIV> <DIV><FONT color=3D#000000=20 size=3D2><BR>---------------------------------------------------<BR>Have = a Great=20 Day!</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>Jamie Orzechowski<BR>RipNET System=20 Admin</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV> <DIV><FONT color=3D#000000 size=3D2>Tel.: 613-342-3946 ext 293<BR>Tel.: = 800-267-4434=20 ext 293<BR>Page.: 613-341-0883<BR>EMail.: <A=20 href=3D"mailto:mhz@ripnet.com">mhz@ripnet.com</A><BR>Web.: <A=20 href=3D"http://www.ripnet.com">http://www.ripnet.com</A><BR>Personal.: = <A=20 href=3D"http://www.moonchilli.com">http://www.moonchilli.com</A><BR>-----= ------=_NextPart_000_0013_01BE6B28.DC9B9440--

I believe www.tsmon.com will do what I need ... -----Original Message----- >On Wed, 10 Mar 1999, Jamie Orzechowski wrote: > >> I am just wondering about port limits. >> >> I want to set my ARC up so that ONLY 1 userID can be logged in at once. >> I still want to allow for multilink PPP though sp that if there radius >> attribute of Port-Limit = 2 they will be allowed multilink. >> >> I tried a "set user default port_limit 1" but then I noticed that some >> people we logged in multiple times ... any ideas?? >> >> is this possible on netserver also?? > >Apparently, Port-Limit won't stop multiple logins. > >Really, Radius is a poor tool for limiting multiple logins. However, if >you use Cistron Radius, it has a Simultaneous-Use attribute that you can >use... that's the good news. It calls a small script that checks your >access server to see if the original user is still on. The bad news is >that the Total Control is a PITA to check what users are on. The good >news is that a few Perl add-ons will give you the ability to check the TC. >However, this is as far as I have gotten since I can't find the "pmcmd" >script/program. Oh well... > > ----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. > >

This is a hell of a good idea ... sure would save us a lot of time with all the users afflicted with cheap modems. If anyone has this working, please let us all know :) We're using both Quads and DSP's, which complicates things a bit, though we are an all-PRI and all-ARC shop. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!" On Wed, 10 Mar 1999, Lon R. Stockton, Jr. wrote: > > Based on an idea I mentioned a couple of threads ago, I'm currently > working on setting this up and getting it tested; am waiting on > the telco to point another number at my head-of-huntgroup line (they > say it'll take 'em till Friday 19th to do it *roll* Yes, I told 'em > that if they gave me dialup access to their switch I could do it > in the time it took me to ask them. Of course, they thought I was > pretty good at being a comedian). > > The basic idea is to have two configurations...one with all the > bells and whistles, and one that's more a generic work-with-anything > configuration with no 56k or v.42bis, etc. If a customer has trouble > with our main number (which is configged to kick ass for the ones > who have fancy modems that actually work), they just try our secondary > number (which is configged to get anything connected, including me > whistling a 300bps carrier). > > Sure, one can get the customer to turn it all off on their end (as > we currently do), but I don't like that solution. It requires the > customer to have to learn too much about modems for one. And the > killer is the amount of time tech support is online with someone's > mom trying to get her to type strange things in a strange panel > (something she *never* had to do when she was with AOL, she'll > remind you). > > So getting the customer to turn it off is *lame*. Anything I can do > to avoid it must be attempted. If I succeed, I fully expect higher > customer satisfaction and yet another stick I can smack my competition > with. > > So, I can't be of much help now, but I will be posting my results > here. > > Couple of things I'd investigate in your position tho...make sure > that you're getting all the dnis digits, or if you're getting a > subset, make sure it's the same in your hdsp config. And definately > verify your init strings of course.... > > Lon Stockton > MoonStar > > > On Wed, 10 Mar 1999, Randy McMillan wrote (without any word wrap): > > > I have been trying to set up a way for users whose modems won't > > negotiate with the v.90 code on our quad modems to call a number > > other than our huntgroup lead number and then based on that DNIS > > number limit the modem to v.34 speeds. So far it hasn't worked > > (it still connects at v.90 speeds). I am getting the DNIS digits, > > but perhaps my init strings were not correct. Any help would be > > apreciated. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 10 Mar 1999, Jamie Orzechowski wrote: > I am just wondering about port limits. > > I want to set my ARC up so that ONLY 1 userID can be logged in at once. > I still want to allow for multilink PPP though sp that if there radius > attribute of Port-Limit = 2 they will be allowed multilink. > > I tried a "set user default port_limit 1" but then I noticed that some > people we logged in multiple times ... any ideas?? > > is this possible on netserver also?? Apparently, Port-Limit won't stop multiple logins. Really, Radius is a poor tool for limiting multiple logins. However, if you use Cistron Radius, it has a Simultaneous-Use attribute that you can use... that's the good news. It calls a small script that checks your access server to see if the original user is still on. The bad news is that the Total Control is a PITA to check what users are on. The good news is that a few Perl add-ons will give you the ability to check the TC. However, this is as far as I have gotten since I can't find the "pmcmd" script/program. Oh well... ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Thus spake Mike Andrews >This is a hell of a good idea ... sure would save us a lot of time with >all the users afflicted with cheap modems. If anyone has this working, >please let us all know :) We're using both Quads and DSP's, which >complicates things a bit, though we are an all-PRI and all-ARC shop. Oh, it is a great idea...and one that I'll definitely remember for implementation here, but since we're dealing with a horrible mismash of quads, DSPs, NETServers and Arcs at the moment, I don't even want to *think* about implementing this until our environment settles down a bit. Primarily I think getting fully switched over to Arc's will be the first part of getting this settled down. Not sure *how* long its gonna take (if ever) to really do away with all our quads. Count me as another interested in the outcome of your experiments though :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wed, 10 Mar 1999, Jamie Orzechowski wrote: > I believe www.tsmon.com will do what I need ... Yeah... but Cistron Radius is free. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Jim Johnson writes... >What is the consensus opinion of leaving Selective Reject enabled on the >quads? I re-enable it on my H-DSP's. >The default setting is enabled when you restore a quad from defaults, >but not on the HDMs. > >Does it cause more problems than it helps? I hope not. -a

If this has been answered before I apologize... Is there anyway to prevent the HiPer ARC from logging telnet sessions to Radius Accounting? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason W jwatkins@iland.net I-Land NOC Tech http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I couldbe way off base here, but it may be that you need to turn root dialin access off. Steve On Thu, 11 Mar 1999, Jason W. wrote: > If this has been answered before I apologize... > Is there anyway to prevent the HiPer ARC from > logging telnet sessions to Radius Accounting? > > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Jason W jwatkins@iland.net > I-Land NOC Tech http://www.iland.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. >

Here's one more hint... http://www.internet.siemens.com/ISB/products/ip/iXpress2000.html Cheers, Robert -- Robert von Bismarck Network Systems Engineer Petrel Communications SA / SPAN Tel : +41 22 304 47 47 Fax : +41 22 300 48 43 WWW : http://www.petrel.ch e-mail : rvb@petrel.ch

I am using Merit Radius 3.6b (freely available)on FreeBSD. This is my default user entry: DEFAULT Authentication-Type = Unix-PW Service-Type = Framed, Simultaneous-Use = 1, Port-Limit = 1, Session-Timeout = 14400, Idle-Timeout = 900, Filter-Id = filter, Framed-Protocol = PPP, Framed-IP-Netmask = 255.255.255.0, Framed-Routing = None, Framed-MTU = 1500, Framed-Compression = Van-Jacobson-TCP-IP Works like a charm with HiperARCs and Netservers. For Multilink customers, I enter a separate profile with no port limitation. Jason Cropper CTO ClearSail Communications http://www.clearsail.net > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski > Sent: Wednesday, March 10, 1999 19:44 > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Port Limit > > > I believe www.tsmon.com will do what I need ... > > -----Original Message----- > From: Stephen Amadei <amadei@dandy.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, March 10, 1999 8:31 PM > Subject: Re: (usr-tc) Port Limit > > > >On Wed, 10 Mar 1999, Jamie Orzechowski wrote: > > > >> I am just wondering about port limits. > >> > >> I want to set my ARC up so that ONLY 1 userID can be logged in at once. > >> I still want to allow for multilink PPP though sp that if there radius > >> attribute of Port-Limit = 2 they will be allowed multilink. > >> > >> I tried a "set user default port_limit 1" but then I noticed that some > >> people we logged in multiple times ... any ideas?? > >> > >> is this possible on netserver also?? > > > >Apparently, Port-Limit won't stop multiple logins. > > > >Really, Radius is a poor tool for limiting multiple logins. However, if > >you use Cistron Radius, it has a Simultaneous-Use attribute that you can > >use... that's the good news. It calls a small script that checks your > >access server to see if the original user is still on. The bad news is > >that the Total Control is a PITA to check what users are on. The good > >news is that a few Perl add-ons will give you the ability to > check the TC. > >However, this is as far as I have gotten since I can't find the "pmcmd" > >script/program. Oh well... > > > > ----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. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Does anyone know how to translate between the accounting session ID as returned in Radius accounting packets and the session ID's returned via SNMP? I'm guessing the SNMP items are internal versions of the same ID's? Also, is there any easy way to get a list of sessions via SNMP? -Jim

stay away from it at ALL costs. stay far away!! they acutally have a version 6.??, but it's full of bugs, use's access, run's your cpu to 100% all the time. You can't use port restrictions in every other version, it forgets who is logged in, then won't log them out and won't let them back in. There is of couse NO support whatsoever from USR! tony Marlo Montanaro wrote: > Does anyone know where I can find detailed information on 3COM V5.0 Security and Accounting Radius Server Software for Windows NT? > > I've searched the 3COM website and can't seem to locate anything other than the basic "this is what it is" product info. I would like to find part numbers, detailed specs, pricing info, etc. and there are no links to more detailed information. > > Also, I would like comments from anyone using this software- how easy is it to install and configure, etc.? > > Thanks! > > Regards... > Marlo Montanaro > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Tried to upload new code to a HARC today, twice (remotely, no less). First time, at 13% complete, TCM informed me "Failed: TFTP Access Violation". Second time, at 17% complete, same error. Anyone have any clues? Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

I had the same probmen. I think this is very serious. I had to load the code by booting the unit and loading the code from a tftp server. Here are the instructions from 3com john Here are two options to load code. 1. You can use the console port and zmodem download the code 2. You can set the hiper arc to load the code from bootp. Here is how you do it and its merits/de-merits case 1: Reboot the card and make sure you have a console / Hiper term and when the card boots download the code using zmodem. only one problem here - you will loose all the cofiguration. Case 2: set the hiper arc to load code from a boot p server First set the tftp server and put the code at the tftp server. second configure the hiper arc to load the code from the bootp server. set booTROM ip inTERFACE eth:1 addRESS <ip address ofyour hiper arc> netmask <netmask for the hiper arc> tftpserver <ip address of the tftp server> tftp_boot once gateway <gateway/router's ip address from the hiper arc> loadfile < the code file name on the tftpserver> save all now reboot the card it will then start loading the file no crash or loss of any config in this case krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jesse Sipprell > Sent: Friday, March 12, 1999 11:29 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) TFTP Access Violation? > > > Tried to upload new code to a HARC today, twice (remotely, no less). > > First time, at 13% complete, TCM informed me "Failed: TFTP Access > Violation". > Second time, at 17% complete, same error. > > Anyone have any clues? > > Thanks! > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * 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. >

I have a few questions... They have been touched on in the past but I didn't see any def. answers in the archives... 1. Should I enable or disable selective reject on my quad modems and hdms? Do enough modems have SREJ to make it worth while? 2. Should I enable or disable v.42bis on my quads and HDMs? Is this worth while in the long run? Will I have to do this with an init string? 3. Is ppp offloading good or bad for quads? hdms? What does it do??? I'm trying to set the best modem configuration that will work for the widest type and number of modems in order to minimize drop-out and connection problems. Thank you. - andrew

Does anyone know where I can find detailed information on 3COM V5.0 = Security and Accounting Radius Server Software for Windows NT? I've searched the 3COM website and can't seem to locate anything other = than the basic "this is what it is" product info. I would like to find = part numbers, detailed specs, pricing info, etc. and there are no links = to more detailed information. Also, I would like comments from anyone using this software- how easy is = it to install and configure, etc.? Thanks! Regards... Marlo Montanaro

I would also recommend staying away. Use Emerald or Cistron or something else. 3Com claims the 100% cpu thing is a MS bug (surprised?) and i somewhat believe them because the machine we ran it on did not behave like it was stressed. also i you look at the you look at the password in the access database will notice the "encryption" is nothing more than a constant added to the ASCII value of the character in the password. i may be totally ignorant on this type of encryption but it looks like you only need your Cap'n Crunch decoder ring, the access file, half a brain and your in! when we realized this we turned white with fear. IOW stay away from 3com's SA server. we went with emerald a while ago and although there is a bit of a learning curve it was well worth it. contact me privately if you want more reasons to stay away. blake > -----Original Message----- > From: Tony Loosle [mailto:tony@tcsourceone.com] > Sent: Friday, March 12, 1999 12:01 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) V5.0 Security and Accounting Radius Server > Software > > > stay away from it at ALL costs. stay far away!! > > they acutally have a version 6.??, but it's full of bugs, > use's access, run's your cpu to 100% all the time. You can't > use port restrictions in every other version, it forgets who > is logged in, then won't log them out and won't let them back in. > > There is of couse NO support whatsoever from USR! > > tony > > > Marlo Montanaro wrote: > > > Does anyone know where I can find detailed information on > 3COM V5.0 Security and Accounting Radius Server Software for > Windows NT? > > > > I've searched the 3COM website and can't seem to locate > anything other than the basic "this is what it is" product > info. I would like to find part numbers, detailed specs, > pricing info, etc. and there are no links to more detailed > information. > > > > Also, I would like comments from anyone using this > software- how easy is it to install and configure, etc.? > > > > Thanks! > > > > Regards... > > Marlo Montanaro > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Hi Jesse, Have you tried taking TCM out of the picture and TFTPing the file directly to the ARC? Below are directions if you want to give it a shot. Hope this helps. Regards, David 1) At ARC "add tftp client <ip address>" (this is the address of the box you are tftping from. You can use 0.0.0.0 to allow anyone to tftp to the ARC, although probably not a good idea) 2) At TFTP box "tftp <ip address>" (this is the IP address or hostname of the ARC) 3) At TFTP prompt "bin" (binary mode transfer) 4) At TFTP prompt "verbose" (verbose mode if you like) 5) At TFTP prompt "trace" (trace packet progress if you like) 6) At TFTP prompt "put <filename> netserve.dmf" (if the filename that you are uploading is named 'netserve.dmf' then you can just do a "put netserve.dmf". If it isn't named netserve.dmf you have to add the second argument so it gets renamed on the ARC as netserve.dmf. For example, "put ne040111.dmf netserve.dmf" 7) Reboot ARC for code to take effect. I always use a Sun box to TX files but if you are a windows guy there are lots of TFTP clients available for W95 and NT. I can't make any recommendations but I know there are a few you might want to check out on www.winfiles.com. Jesse Sipprell <jss@evcom.net> on 03/12/99 11:22:06 AM Please respond to usr-tc@lists.xmission.com cc: (David Bachta/MW/US/3Com) On Fri, Mar 12, 1999 at 11:44:43AM -0500, John Verreault wrote: > I had the same probmen. I think this is very serious. I had to load the code > by booting the unit and loading the code from a tftp server. > Here are the instructions from 3com > > john Ugg. This is indeed painful for us, especially since the unit is located 250 miles away and no staff are available at the location to manually attend to it [although we can remotely power the unit on/off]. > Here are two options to load code. > > 1. You can use the console port and zmodem download the code > 2. You can set the hiper arc to load the code from bootp. > > Here is how you do it and its merits/de-merits > > case 1: > > Reboot the card and make sure you have a console / Hiper term and when > the card boots download the code using zmodem. > > only one problem here - you will loose all the cofiguration. > > > Case 2: > > set the hiper arc to load code from a boot p server > > First set the tftp server and put the code at the tftp server. > > second configure the hiper arc to load the code from the bootp server. > > set booTROM ip inTERFACE eth:1 addRESS <ip address ofyour hiper arc> > netmask <netmask for the hiper arc> tftpserver <ip address of the tftp > server> tftp_boot once gateway <gateway/router's ip address from the > hiper arc> loadfile < the code file name on the tftpserver> > > save all > > > now reboot the card > > it will then start loading the file > > no crash or loss of any config in this case > > krish > > ----------------------------------------- > \ T.S.V. Krishnan \ > \ Network System Engineer \ ( : - : ) > \ 3Com ............ \ > ----------------------------------------------/ > > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jesse Sipprell > > Sent: Friday, March 12, 1999 11:29 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) TFTP Access Violation? > > > > > > Tried to upload new code to a HARC today, twice (remotely, no less). > > > > First time, at 13% complete, TCM informed me "Failed: TFTP Access > > Violation". > > Second time, at 17% complete, same error. > > > > Anyone have any clues? > > > > Thanks! > > > > -- > > Jesse Sipprell > > Technical Operations Director > > Evolution Communications, Inc. > > 800-496-4736 (ext 106) > > > > * 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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * 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.

I've got a couple of old quad A/D cards that I dug up. I can only get them to pick up at 1200baud, I checked all the DTE settings, and put the latest code on them but no luck. Is there anything else I can try? Thanks

We have recently changed our HiperDSPs from channelized T1s to PRIs. The local dial up # works fine, an 800 # that directs to the local # has stopped working. The connection completes, and a valid IP is assigned to the PC (verified by winipcfg). The IP and user name do not show up on the TCtrl box (list sess, show users, etc.). The connection is there, but the client PC cant ping or route anywhere. It is a plain-jane ISP set up (just PPP) Any ideas? Thanks, Scott Boggs IS Manager United Bank

We formerly used Ascend Access control with a max4000. When we put in our TotCtrl box, we needed a RADIUS that was usable with multiple hardware vendors. The 3com RADIUS couldnt do it. And the Access97 guts was needless overhead in my opinion. I found a great RADIUS in "Steel belted RADIUS" from Funk software. No complaints, it supports generic and vendor specific attributes. Services both our Ascend MAX and TotCtrl. Regards, Scott Boggs IS Manager United Bank > -----Original Message----- > From: Blake Fithen [SMTP:fithen@NetworksPlus.com] > Sent: Friday, March 12, 1999 1:28 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) V5.0 Security and Accounting Radius Server > Software > > I would also recommend staying away. Use Emerald or Cistron or > something else. 3Com claims the 100% cpu thing is a MS bug (surprised?) > and i somewhat believe them because the machine we ran it on did > not behave like it was stressed. also i you look at the you look at > the password in the access database will notice the "encryption" >

On Fri, 12 Mar 1999, Tony Loosle wrote: >stay away from it at ALL costs. stay far away!! > >they acutally have a version 6.??, but it's full of bugs, use's access, >run's your cpu to 100% all the time. You can't use port restrictions in >every other version, it forgets who is logged in, then won't log them out >and won't let them back in. The server itself is not "full of bugs" -- it may still have a few, but they aren't serious problems. Only under NT does it use Access at "run you cpu to 100%". It can use Oracle, or any other ODBC capable database. I've used it with postgres, mysql, Oracle, Sybase, and flat files under UNIX. The 100% CPU thing is NT lying to you. It is not using 100% of the CPU -- if it were, then it would be interfering with other applications and it simply isn't. (Of course, that's a good reason to not use NT for a RADIUS server.) HOWEVER, I do strongly recommend you burn the script and database schema USR ships with the thing... it's just _ugly_. I spent about a month rewriting the database and the script to work in a more sane fashion -- it's written for SA4, however, and alot has changed from SA4 -> SA5 -> SA6. I started updating the system, but the company I formerly worked for abandoned all my work in favor of the far inferior CiscoSecure (6 months later, they still don't have CiscoSecure doing all the things SA4 _is_ doing -- I doubt they ever will.) If anyone is interested in that setup, drop me a note and I'll let you at it. As for the RADIUS server keeping up with who is logged in where... that's always been a mess. I've yet to see a RADIUS system that did it correctly without some outside help. The RADIUS protocol is too stateless to construct such a stateful restriction. (Of course, USR goes about the restriction in the wrong way from the get go... just because they authenticated doesn't mean they are logged in.) >There is of couse NO support whatsoever from USR! And this suprises you? USR does support it, but it hard to find the right people. Once you get past the muck, there are people who will help you with it. Of course, the best help comes from those who have used the product. (esp. those who have had source code access to the product *grin*) For all the bad press, I still think the USR RADIUS server is most full featured and customizable of any RADIUS system. It's a bit slow, but very powerful. (It'd be a screamer if it was multithreaded, but 3Com management is too blind and/or stupid to see the benefits.) --Ricky

At 12:28 PM 3/12/99 -0600, you wrote: >I would also recommend staying away. Use Emerald or Cistron or >something else. 3Com claims the 100% cpu thing is a MS bug (surprised?) >and i somewhat believe them because the machine we ran it on did >not behave like it was stressed. also i you look at the you look at >the password in the access database will notice the "encryption" >is nothing more than a constant added to the ASCII value of the >character in the password. i may be totally ignorant on this type >of encryption but it looks like you only need your Cap'n Crunch decoder >ring, the access file, half a brain and your in! when we realized this >we turned white with fear. IOW stay away from 3com's SA server. we >went with emerald a while ago and although there is a bit of a learning >curve it was well worth it. contact me privately if you want more >reasons to stay away. I've been using S&A Server 5.5.3 mainly due to the cost(vendor threw it in for free). It's been working ok for me as far as authentication goes, but getting logging information from it has been a fruitless nightmare. I've gone rounds with 3Com support about it that has been less than helpful. Each time I approach 3Com, the scenario is similar; Step 1: Reluctance to provide support since I didn't pay 3Com for it. I don't care, take that up with the vendor that gave it to me. Finally, 3Com grudgingly decides they'll help. Step 2: After going over configuration/settings, etc, tech suggests a few changes and tells me to make them and let him know whether or not that solved the problem. Step 3: I make the changes, seeing little or no improvement in the logging information available. Try to contact the tech to inform him that the changes haven't gotten things functional. Leave email and phone messages. Step 4: Never hear back from tech, despite numerous emails/calls. After another 2 months of frustration, revisit issue...back to Step 1. I've gone through this process 3 times in the last 7 or 8 months. As for the CPU usage, it does keep my CPU pretty much pegged, but doesn't seem to affect the machine. I have a mailserver on that machine also that doesn't appear to be taking any performance hit from the Access CPU usage. I'd like to look at other RADIUS options, but I'm not sure what direction to go in. I'm a little guy(250 or so users) and need something economical, but also need to be able to import the S&A Server database as I don't keep records of user passwords. Any ideas? Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

On Fri, 12 Mar 1999, Scott Boggs wrote: >We formerly used Ascend Access control with a max4000. >When we put in our TotCtrl box, we needed a RADIUS that >was usable with multiple hardware vendors. The 3com RADIUS >couldnt do it. And the Access97 guts was needless overhead in my opinion. SA6 can handle multiple vendors. And yes, I've hated the MS Access BS forever as well. But, if you don't run it under windows, then you don't have that problem. What's up with all you nuts using NT for a RADIUS server? Gez. --Ricky

Can anyone tell me how to clear the Flash ROM on a HiperARC. Thanks, Sean Herr

I've got a similar problem on my side too... ever since we started using ARC's, I've had a HELL of a time with Sportster modems... they will connect, negotiate fine, get to SOME web site (3 that they have problems with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a WINMODEM, I dont have this problem from home, nor do I have this problem from the office (I'm dialing into the SAME modem pool as my customers from home) The only difference in the setup is my modem vs theirs... it seems to be centered around the Sportster 56K v.90 modem (X2's that were converted are not affected.) The problem exists in chassis that have both Quad Modems, and DSP's, however, my remaining chassis with Quads and Netservers are not affected... someone PLEASE toss me a bone, I've been on the phone with 3com support for 42 minutes now, without so much as a clue as to why this is happening, any suggestions? Paul M. Oster <devious@minot.com> http://www.minot.com/ Magic Internet Services (701) 838-1265 Minots FIRST Internet Connection -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- "I might not agree with what you have to say but I will defend, to my death, your right to say it." - Voltaire On Fri, 12 Mar 1999, Scott Boggs wrote: > We have recently changed our HiperDSPs from channelized T1s > to PRIs. The local dial up # works fine, an 800 # that directs to the > local # has stopped working. The connection completes, and a valid > IP is assigned to the PC (verified by winipcfg). The IP and user name do > not show up > on the TCtrl box (list sess, show users, etc.). > > The connection is there, but the client PC cant ping or route anywhere. > It is a plain-jane ISP set up (just PPP) > > Any ideas? > > Thanks, > Scott Boggs > IS Manager > United Bank > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Herr |Sent: Friday, March 12, 1999 3:30 PM |To: 'usr-tc@lists.xmission.com' |Subject: (usr-tc) How to clear ROM on ARC | | |Can anyone tell me how to clear the Flash ROM on a HiperARC. | Multiple Options below: Format Flash: Set up a console connection. Reboot the card. During the pause after the ROM version number type (case sensative!) "AT{ZF}" Begin a zmodem upload of HARC software. You will have a completely clean software install when the upload completes. If you just want to erase the configuration, the command "DELETE CONFIGURATION" will do. Unless you forgot the manage user password? Then use the console connection and clear the ROM from the boot ROM menu. -M

On Fri, 12 Mar 1999, Sean Herr wrote: > Can anyone tell me how to clear the Flash ROM on a HiperARC. > You can do a delete config On the hiper arc login as admin and type delete config or you can do a zmodem download of the code that will erase all the config and clear the flash. krish > Thanks, > > Sean Herr > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I have a PRI hooked into a HiperDSP. Modem code is 1.2.59. 4 of the modems had an operational status of miuFailed. I replaced the card with a brand new HiperDSP running 1.2.59. The HiperArc on this chassis is running 4.1.59-1. 3com told me they had never seen this error message before and they said it was probably a bad card. I replaced the card and the message came back, but it is on different modems than before. Any ideas? Chris Henderson Rural Connections ~ Information Services

umm, well, my call with 3com seems to have solved this, they told me not to set MTU in radius.... Who do I call to make this into an official bug report. Paul M. Oster <devious@minot.com> http://www.minot.com/ Magic Internet Services (701) 838-1265 Minots FIRST Internet Connection -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- "I might not agree with what you have to say but I will defend, to my death, your right to say it." - Voltaire On Fri, 12 Mar 1999, Paul Oster wrote: > I've got a similar problem on my side too... ever since we started using > ARC's, I've had a HELL of a time with Sportster modems... they will > connect, negotiate fine, get to SOME web site (3 that they have problems > with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a > WINMODEM, I dont have this problem from home, nor do I have this problem > from the office (I'm dialing into the SAME modem pool as my customers from > home) The only difference in the setup is my modem vs theirs... it seems > to be centered around the Sportster 56K v.90 modem (X2's that were > converted are not affected.) The problem exists in chassis that have both > Quad Modems, and DSP's, however, my remaining chassis with Quads and > Netservers are not affected... someone PLEASE toss me a bone, I've been on > the phone with 3com support for 42 minutes now, without so much as a clue > as to why this is happening, any suggestions? > > Paul M. Oster <devious@minot.com> http://www.minot.com/ > Magic Internet Services (701) 838-1265 > Minots FIRST Internet Connection > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > > "I might not agree with what you have to say but I will defend, to > my death, your right to say it." - Voltaire > > On Fri, 12 Mar 1999, Scott Boggs wrote: > > > We have recently changed our HiperDSPs from channelized T1s > > to PRIs. The local dial up # works fine, an 800 # that directs to the > > local # has stopped working. The connection completes, and a valid > > IP is assigned to the PC (verified by winipcfg). The IP and user name do > > not show up > > on the TCtrl box (list sess, show users, etc.). > > > > The connection is there, but the client PC cant ping or route anywhere. > > It is a plain-jane ISP set up (just PPP) > > > > Any ideas? > > > > Thanks, > > Scott Boggs > > IS Manager > > United Bank > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

As long as you don't run it as a service you won't be faced with the cpu problem. I put it in the startup group and it works fine. Concurrency checking, that's another issue/problem. I honestly believe it's i the HiPerArc because they had it fixed once but since the accounting record changes that were added around the 4.1 code, it's never worked since. As was mentioned, it will miss stop records and then folks will try to reauthenticate and poof, it thinks they are logged in. Makes for some nasty tech support phone calls. It's #1 on my wish list for them to fix (aside from being able to port the backend to an SQL type of server). Jeff Binkley ASA Network Computing u>I would also recommend staying away. Use Emerald or Cistron or u>something else. 3Com claims the 100% cpu thing is a MS bug u>(surprised?) and i somewhat believe them because the machine we ran it u>on did not behave like it was stressed. also i you look at the you u>look at the password in the access database will notice the u>"encryption" is nothing more than a constant added to the ASCII value u>of the character in the password. i may be totally ignorant on this u>type of encryption but it looks like you only need your Cap'n Crunch u>decoder ring, the access file, half a brain and your in! when we u>realized this we turned white with fear. IOW stay away from 3com's SA u>server. we went with emerald a while ago and although there is a bit u>of a learning curve it was well worth it. contact me privately if you u>want more reasons to stay away. u>blake u> u>> -----Original Message----- u>> From: Tony Loosle [mailto:tony@tcsourceone.com] u>> Sent: Friday, March 12, 1999 12:01 PM u>> To: usr-tc@lists.xmission.com u>> Subject: Re: (usr-tc) V5.0 Security and Accounting Radius Server u>> Software u>> stay away from it at ALL costs. stay far away!! u>> they acutally have a version 6.??, but it's full of bugs, u>> use's access, run's your cpu to 100% all the time. You can't u>> use port restrictions in every other version, it forgets who u>> is logged in, then won't log them out and won't let them back in. u>> There is of couse NO support whatsoever from USR! u>> tony u>> Marlo Montanaro wrote: u>> > Does anyone know where I can find detailed information on u>> 3COM V5.0 Security and Accounting Radius Server Software for u>> Windows NT? u>> > u>> > I've searched the 3COM website and can't seem to locate u>> anything other than the basic "this is what it is" product u>> info. I would like to find part numbers, detailed specs, u>> pricing info, etc. and there are no links to more detailed u>> information. u>> > u>> > Also, I would like comments from anyone using this u>> software- how easy is it to install and configure, etc.? u>> > u>> > Thanks! u>> > Regards... u>> > Marlo Montanaro u>> > - u>> > To unsubscribe to usr-tc, send an email to u>> > "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of u>> > the message. For information on digests or retrieving files and u>> old messages send u>> > "help" to the same address. Do not use quotes in your message. u>> - u>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u>> with "unsubscribe usr-tc" in the body of the message. u>> For information on digests or retrieving files and old messages u>> send "help" to the same address. Do not use quotes in your u>> message. u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42-21 9999

> First time, at 13% complete, TCM informed me "Failed: TFTP Access > Violation". Second time, at 17% complete, same error. > > Anyone have any clues? Reboot the HARC. You probably have too many deleted sectors on HARCs flash (do "list files") and rebooting seem to defrag it. At least it worked for me. __________________________________ Kalev Nurklik MicroLink Online Sakala 19, 10141 Tallinn, Estonia Tel: +372 6 308 909 Fax: +372 6 308 901 E-mail: k.nurklik@online.ee http://www.online.ee

What version of the codes are you running on the ARC, DSP's and Quads? Also can anyone else confirm that we're _not_ supposed to be shooting the MTU value in radius? Steve On Fri, 12 Mar 1999, Paul Oster wrote: > > > umm, well, my call with 3com seems to have solved this, they told me not > to set MTU in radius.... Who do I call to make this into an official bug > report. > > Paul M. Oster <devious@minot.com> http://www.minot.com/ > Magic Internet Services (701) 838-1265 > Minots FIRST Internet Connection > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > > "I might not agree with what you have to say but I will defend, to > my death, your right to say it." - Voltaire > > On Fri, 12 Mar 1999, Paul Oster wrote: > > > I've got a similar problem on my side too... ever since we started using > > ARC's, I've had a HELL of a time with Sportster modems... they will > > connect, negotiate fine, get to SOME web site (3 that they have problems > > with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a > > WINMODEM, I dont have this problem from home, nor do I have this problem > > from the office (I'm dialing into the SAME modem pool as my customers from > > home) The only difference in the setup is my modem vs theirs... it seems > > to be centered around the Sportster 56K v.90 modem (X2's that were > > converted are not affected.) The problem exists in chassis that have both > > Quad Modems, and DSP's, however, my remaining chassis with Quads and > > Netservers are not affected... someone PLEASE toss me a bone, I've been on > > the phone with 3com support for 42 minutes now, without so much as a clue > > as to why this is happening, any suggestions? > > > > Paul M. Oster <devious@minot.com> http://www.minot.com/ > > Magic Internet Services (701) 838-1265 > > Minots FIRST Internet Connection > > > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > > > > "I might not agree with what you have to say but I will defend, to > > my death, your right to say it." - Voltaire > > > > On Fri, 12 Mar 1999, Scott Boggs wrote: > > > > > We have recently changed our HiperDSPs from channelized T1s > > > to PRIs. The local dial up # works fine, an 800 # that directs to the > > > local # has stopped working. The connection completes, and a valid > > > IP is assigned to the PC (verified by winipcfg). The IP and user name do > > > not show up > > > on the TCtrl box (list sess, show users, etc.). > > > > > > The connection is there, but the client PC cant ping or route anywhere. > > > It is a plain-jane ISP set up (just PPP) > > > > > > Any ideas? > > > > > > Thanks, > > > Scott Boggs > > > IS Manager > > > United Bank > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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. >

ARCs are 4.1.59-6, DSP's are 1.2.59, Netservers are 3.8.1, NMC's are either 5.4.95 or 5.5.5 (depending on 4M or 16M version)... Quads are mostly 5.10.9 or 5.x.9 (whatever the double sided cards are, I've only got a vew of them) in other words, completely up to date... I'll let everyone know if my complaints are eliminated by this change... NOTE, NetServer cards are/were unaffected by this problem. Time for yet another maintenance release? Paul M. Oster <devious@minot.com> http://www.minot.com/ Magic Internet Services (701) 838-1265 Minots FIRST Internet Connection -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- "I might not agree with what you have to say but I will defend, to my death, your right to say it." - Voltaire On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote: > What version of the codes are you running on the ARC, DSP's and Quads? > > Also can anyone else confirm that we're _not_ supposed to be shooting the > MTU value in radius? > > Steve > > On Fri, 12 Mar 1999, Paul Oster wrote: > > > > > > > umm, well, my call with 3com seems to have solved this, they told me not > > to set MTU in radius.... Who do I call to make this into an official bug > > report. > > > > Paul M. Oster <devious@minot.com> http://www.minot.com/ > > Magic Internet Services (701) 838-1265 > > Minots FIRST Internet Connection > > > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > > > > "I might not agree with what you have to say but I will defend, to > > my death, your right to say it." - Voltaire > > > > On Fri, 12 Mar 1999, Paul Oster wrote: > > > > > I've got a similar problem on my side too... ever since we started using > > > ARC's, I've had a HELL of a time with Sportster modems... they will > > > connect, negotiate fine, get to SOME web site (3 that they have problems > > > with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a > > > WINMODEM, I dont have this problem from home, nor do I have this problem > > > from the office (I'm dialing into the SAME modem pool as my customers from > > > home) The only difference in the setup is my modem vs theirs... it seems > > > to be centered around the Sportster 56K v.90 modem (X2's that were > > > converted are not affected.) The problem exists in chassis that have both > > > Quad Modems, and DSP's, however, my remaining chassis with Quads and > > > Netservers are not affected... someone PLEASE toss me a bone, I've been on > > > the phone with 3com support for 42 minutes now, without so much as a clue > > > as to why this is happening, any suggestions? > > > > > > Paul M. Oster <devious@minot.com> http://www.minot.com/ > > > Magic Internet Services (701) 838-1265 > > > Minots FIRST Internet Connection > > > > > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > > > > > > "I might not agree with what you have to say but I will defend, to > > > my death, your right to say it." - Voltaire > > > > > > On Fri, 12 Mar 1999, Scott Boggs wrote: > > > > > > > We have recently changed our HiperDSPs from channelized T1s > > > > to PRIs. The local dial up # works fine, an 800 # that directs to the > > > > local # has stopped working. The connection completes, and a valid > > > > IP is assigned to the PC (verified by winipcfg). The IP and user name do > > > > not show up > > > > on the TCtrl box (list sess, show users, etc.). > > > > > > > > The connection is there, but the client PC cant ping or route anywhere. > > > > It is a plain-jane ISP set up (just PPP) > > > > > > > > Any ideas? > > > > > > > > Thanks, > > > > Scott Boggs > > > > IS Manager > > > > United Bank > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the 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. >

Yes. I was an ass and forgot the password. Sean Herr @YourNET Connection, Inc. 847-524-3910 http://www.ync.net -----Original Message----- Sent: Friday, March 12, 1999 3:52 PM |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Herr |Sent: Friday, March 12, 1999 3:30 PM |To: 'usr-tc@lists.xmission.com' |Subject: (usr-tc) How to clear ROM on ARC | | |Can anyone tell me how to clear the Flash ROM on a HiperARC. | Multiple Options below: Format Flash: Set up a console connection. Reboot the card. During the pause after the ROM version number type (case sensative!) "AT{ZF}" Begin a zmodem upload of HARC software. You will have a completely clean software install when the upload completes. If you just want to erase the configuration, the command "DELETE CONFIGURATION" will do. Unless you forgot the manage user password? Then use the console connection and clear the ROM from the boot ROM menu. -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.

Hi, I am in the process of configuring a Netserver 8 V.34 device. I have = tried following the steps described in Users Manual. Following is the = summary Of commands issued so far.=20 netserver>netserver>set system name "netserver" netserver>set system location "ABC" netserver>set system contact "XYZ" netserver>set command login_required yes netserver>add user "administrator" password "password" type login,manage netserver>add snmp community public address 0.0.0.0 access RW netserver>enable security_option remote_user_administration telnet netserver>add syslog 172.16.8.2 loglevel critical netserver>set accounting primary_server 172.16.8.2 netserver>set authentication primary_server 172.16.8.2 primary_secret = "unknown" netserver>add ip network "drcnet" interface eth:1 address = 172.16.8.4/255.255.248 .0 frame ethernet_ii enable no netserver>enable ip network "net" netserver>enable ip forwarding netserver>add dns server 172.16.8.2 preference 1 netserver>set dns domain_name "xyz.com" netserver>set ip system initial_pool_address 172.16.9.101 pool_members 8 netserver>add tftp client 0.0.0.0 netserver>save all Saving..... SAVE ALL SAVE ALL Complete netserver>add user test password test type network network_service ppp netserver>set network user test address_selection assign netserver>save all Saving..... SAVE ALL SAVE ALL Complete Problem is that when I try connecting to Netserver from my PC through = modem, message " server couldn't negotiate compatible set of protocols = defined Under Network Configuration , check your network configuration under = control panel" appears, and fails to make a connection. On my PC I have configured TCP/IP for dial up connection, PPP is defined = as protocol for dial up connection. I have tried disabling remote authentication as Radius is still not = configured. Any idea what I am missing while configuring. TIA Regards,

Thus spake Paul Oster > umm, well, my call with 3com seems to have solved this, they told me not >to set MTU in radius.... Who do I call to make this into an official bug >report. The PPP IETF working group? Actually...that's not necessarily true. Background... During PPP negotiation, LCP is negotiated first, MTU is a part of LCP. *Then* PAP, CHAP, EAP, which authentication protocol you use is "negotiated", meaning that the MTU in RADIUS isn't received by the RADIUS until *after* the MTU was already negotiated in LCP. The question then becomes...where really is the bug. When the Arc gets the RADIUS response, it could, in theory at least, lower its own MTU without any problems (the other side already said it would accept packets up to size x, if you only send packets up to size x-y, that's not going to screw up the other side). If it needs to lower the MRU (or conceivably MRRU), then it would need to restart LCP, which is problematic at best as I doubt there are all that many PPP implementations out there that will handle having LCP restarted. Obviously, there are all sorts of other permutations of what can be going on in here, but hopefully this gives you a direction to start from to help understand what issues are involved. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake vanhalen@coredcs.com >Also can anyone else confirm that we're _not_ supposed to be shooting the >MTU value in radius? Other than, for the most part its not really going to do you much good? Since the MTU is already negotiated in LCP before the RADIUS response is received in PAP, most systems will just drop the MTU setting on the floor. See my other message for how it *might* be useful to use this value, even in this situation (and I'm sure other RADIUS guru's like MZ and David Bolen can correct me if I've misstated something). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Howdy. We're having trouble getting a couple of dual-PRI cards working. We've followed the directions given in the docs, and referred to in the archives, but with no luck. I'm going to paste some table output here that might lend some clues. Our problem is this: the dual PRI won't take any calls. My theory is that because it's not showing a mapping of DS0s to modems, it doesn't think there are any modems available for the incoming calls. However: in some other displayable tables, the PRI card itself is saying that both the modems and the ISDN gateway (a Netserver, in this case) are available. It bothers me that, on one hand, we have a good DS0-to-modem mapping, but it's not showing up in the DS0 status table. Have a look, and please help us figure out how to slay this beast. I'll appreciate any help. --- Mark R. Lindsey, mark@datasys.net Internet Engineering, DSS Online Voice: 912.241.0607, Fax: 912.241.0190 (US) Copyright (c) 3Com Corporation, 1995-1997 Dual T1 PRI Application Card Revision 3.0.2 (Card Id: 27) Boot Code Linked Date : Mon Dec 04 17:41:48 1995 Operation Code Linked Date: Fri Sep 05 12:11:37 1997 Chassis Slot Device Configuration Status Current Configuration Status Device Device Slot# Type Slot# Type 1 Dual-PRI 9 Qbch-I_mdm 2 NONE 10 Qbch-I_mdm 3 Qbch-I_mdm 11 Qbch-I_mdm 4 Qbch-I_mdm 12 Qbch-I_mdm 5 Qbch-I_mdm 13 Qbch-I_mdm 6 Qbch-I_mdm 14 Qbch-I_mdm 7 Qbch-I_mdm 15 NONE 8 Qbch-I_mdm 16 ISDN-GW Assign device types to chassis slot numbers given the format below: DEVICE_TYPE#:S#[,S#,S#-S#] Where, DEVICE_TYPE# -> q - QBCH-MDM,g - ISDN-GW,n - NONE (no ISDN Device in Slot) i - QBCH-I_MDM,S# -> Chassis Slot# (1-16) Example: q:4,5 assigns the QBCH-MDM NAC device type to slots 4 and 5. >: Card Configuration Current Setting 1 Save current Configuration to NVRAM 2 Restore NVRAM Configuration 3 Restore Default Configuration 4 Timing Source Priority Assignment Span-1=1 Span-2=2 5 Chassis Slot Device Configuration 6 Modem Routing Method Fixed Assignment 7 Configure Local Console Password 8 Change DS0 state on Quad Modem NAC action Disabled 9 Companding Code Configuration U-Law Inbound Call Routing Configuration Current 1 Default ISDN-GW Slot: 16 2 Allow Analog Modem Calls: Enabled 3 Inbound Phone Number Routing Configuration 4 Inbound Phone Number Routing Configuration Status (Entries 1-24) 5 Inbound Phone Number Routing Configuration Status (Entries 25-48) 6 Reserved Pool to Inbound Phone Number Assignment 7 Modem /I-Modem to Reserved Pool Assignment 8 ISDN-GWC to Reserved Pool Assignment Span Line 1 Configuration Current Setting 1 Framing Mode ESF 2 Line Coding B8ZS 3 Remotely Initiated Loopback Ignore 4 Jitter Attenuation Transmitter 5 Transmit Line Build Out 0.0 dB 6 Switch Type (Boot time) Config=DMS-100(NT)Act.=DMS-100(NT) 7 Idle Byte Sent to TELCO FE Hex 8 DS0 to Modem Slot/Chan Mapping 9 Signaling Channel Config (Boot time) Config=D-channel Act.=D-channel 10 Interface ID 0 11 Span Level Call Type Blocking No Call Blocked 12 Span Level Cause Codes 13 DS0 Level Call Type Blocking 14 DS0 Level Service State 15 Short Haul NIC Line Length Not Applicable 16 Use ALERTING Response NO Span Line 1 DS0 Status DS0 DS0 Device Slot/ DS0 DS0 Device Slot/ Status Type Chan Status Type Chan 1 IDLE NONE -/- 13 OOS NONE -/- 2 IDLE NONE -/- 14 OOS NONE -/- 3 IDLE NONE -/- 15 OOS NONE -/- 4 IDLE NONE -/- 16 OOS NONE -/- 5 IDLE NONE -/- 17 OOS NONE -/- 6 IDLE NONE -/- 18 OOS NONE -/- 7 IDLE NONE -/- 19 OOS NONE -/- 8 IDLE NONE -/- 20 OOS NONE -/- 9 IDLE NONE -/- 21 OOS NONE -/- 10 IDLE NONE -/- 22 OOS NONE -/- 11 OOS NONE -/- 23 OOS NONE -/- 12 OOS NONE -/- 24 D-CHANNEL NONE -/- Press Return to Update status or press ESC to exit Span Line 2 DS0 Status DS0 DS0 Device Slot/ DS0 DS0 Device Slot/ Status Type Chan Status Type Chan 1 IDLE NONE -/- 13 OOS NONE -/- 2 IDLE NONE -/- 14 OOS NONE -/- 3 IDLE NONE -/- 15 OOS NONE -/- 4 IDLE NONE -/- 16 OOS NONE -/- 5 IDLE NONE -/- 17 OOS NONE -/- 6 IDLE NONE -/- 18 OOS NONE -/- 7 IDLE NONE -/- 19 OOS NONE -/- 8 IDLE NONE -/- 20 OOS NONE -/- 9 IDLE NONE -/- 21 OOS NONE -/- 10 IDLE NONE -/- 22 OOS NONE -/- 11 OOS NONE -/- 23 OOS NONE -/- 12 OOS NONE -/- 24 D-CHANNEL NONE -/- Press Return to Update status or press ESC to exit Card Status Current PRI Timing Source: Span Line 1. Current PBus Timing Source: Slave. NIC Type: Dual T1 v2 PRI Chassis Slot Number: 01 NAC Uptime (days::hh:mm:ss): 0::5:23:34 DRAM Installed: 4 M FLASH ROM Installed: 1 M Press Esc to exit. Chassis Slot Device Configuration Status Device Slot# Type 1 Dual-PRI 2 NONE 3 Qbch-I_mdm 4 Qbch-I_mdm 5 Qbch-I_mdm 6 Qbch-I_mdm 7 Qbch-I_mdm 8 Qbch-I_mdm 9 Qbch-I_mdm 10 Qbch-I_mdm 11 Qbch-I_mdm 12 Qbch-I_mdm 13 Qbch-I_mdm 14 Qbch-I_mdm 15 NONE 16 ISDN-GW Press Return to update status or press Esc to exit. Span Line 1 DS0 to Modem Slot/Chan Mapping DS0 Slot/Chan DS0 Slot/Chan 1 3/1 13 6/1 2 3/2 14 6/2 3 3/3 15 6/3 4 3/4 16 6/4 5 4/1 17 7/1 6 4/2 18 7/2 7 4/3 19 7/3 8 4/4 20 7/4 9 5/1 21 8/1 10 5/2 22 8/2 11 5/3 23 8/3 12 5/4 24 Unmapped -in use Example: 2:14/1 maps DS0 2 to slot 14, channel 1 (ds0:slot/chan,):

Thus spake Mark R. Lindsey >Our problem is this: the dual PRI won't take any calls. My theory is >that because it's not showing a mapping of DS0s to modems, it doesn't >think there are any modems available for the incoming calls. However: in >some other displayable tables, the PRI card itself is saying that both >the modems and the ISDN gateway (a Netserver, in this case) are >available. Not that it should affect it, but change your ISDN GW to 0, let the quads handle it...you'll be much better off with it. The other thing to check is on the modems, make sure they are set to line src of pritdm and not t1tdm. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote: > What version of the codes are you running on the ARC, DSP's and Quads? > > Also can anyone else confirm that we're _not_ supposed to be shooting the > MTU value in radius? > This has nothing to do with HiPer arc code or DSP or Quad code. For all HiPer arcs you either set the MTU to 1500 or do not set any value. Setting the MTU to a lower value other than 1500 will cause users unable to browse certain websites. krish > Steve > > On Fri, 12 Mar 1999, Paul Oster wrote: > > > > > > > umm, well, my call with 3com seems to have solved this, they told me not > > to set MTU in radius.... Who do I call to make this into an official bug > > report. > > > > Paul M. Oster <devious@minot.com> http://www.minot.com/ > > Magic Internet Services (701) 838-1265 > > Minots FIRST Internet Connection > > > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > > > > "I might not agree with what you have to say but I will defend, to > > my death, your right to say it." - Voltaire > > > > On Fri, 12 Mar 1999, Paul Oster wrote: > > > > > I've got a similar problem on my side too... ever since we started using > > > ARC's, I've had a HELL of a time with Sportster modems... they will > > > connect, negotiate fine, get to SOME web site (3 that they have problems > > > with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a > > > WINMODEM, I dont have this problem from home, nor do I have this problem > > > from the office (I'm dialing into the SAME modem pool as my customers from > > > home) The only difference in the setup is my modem vs theirs... it seems > > > to be centered around the Sportster 56K v.90 modem (X2's that were > > > converted are not affected.) The problem exists in chassis that have both > > > Quad Modems, and DSP's, however, my remaining chassis with Quads and > > > Netservers are not affected... someone PLEASE toss me a bone, I've been on > > > the phone with 3com support for 42 minutes now, without so much as a clue > > > as to why this is happening, any suggestions? > > > > > > Paul M. Oster <devious@minot.com> http://www.minot.com/ > > > Magic Internet Services (701) 838-1265 > > > Minots FIRST Internet Connection > > > > > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- > > > > > > "I might not agree with what you have to say but I will defend, to > > > my death, your right to say it." - Voltaire > > > > > > On Fri, 12 Mar 1999, Scott Boggs wrote: > > > > > > > We have recently changed our HiperDSPs from channelized T1s > > > > to PRIs. The local dial up # works fine, an 800 # that directs to the > > > > local # has stopped working. The connection completes, and a valid > > > > IP is assigned to the PC (verified by winipcfg). The IP and user name do > > > > not show up > > > > on the TCtrl box (list sess, show users, etc.). > > > > > > > > The connection is there, but the client PC cant ping or route anywhere. > > > > It is a plain-jane ISP set up (just PPP) > > > > > > > > Any ideas? > > > > > > > > Thanks, > > > > Scott Boggs > > > > IS Manager > > > > United Bank > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the 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. >

If you have forgot your password and if radius is already configured for the hiper arc, then you can add a login user of type adminstrator and logon to the hiper arc. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Fri, 12 Mar 1999, Sean Herr wrote: > Yes. I was an ass and forgot the password. > > Sean Herr > @YourNET Connection, Inc. > 847-524-3910 > http://www.ync.net > > > -----Original Message----- > From: Mike Wronski [mailto:mike@coredump.ae.usr.com] > Sent: Friday, March 12, 1999 3:52 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) How to clear ROM on ARC > > > > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Herr > |Sent: Friday, March 12, 1999 3:30 PM > |To: 'usr-tc@lists.xmission.com' > |Subject: (usr-tc) How to clear ROM on ARC > | > | > |Can anyone tell me how to clear the Flash ROM on a HiperARC. > | > > Multiple Options below: > > Format Flash: > Set up a console connection. Reboot the card. During the pause after the ROM > version number type (case sensative!) > "AT{ZF}" > > Begin a zmodem upload of HARC software. You will have a completely clean > software > install when the upload completes. > > > If you just want to erase the configuration, the command "DELETE > CONFIGURATION" > will do. Unless you forgot the manage user password? Then use the console > connection and clear the ROM from the boot ROM menu. > > -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. >

: >Our problem is this: the dual PRI won't take any calls. My theory is : >that because it's not showing a mapping of DS0s to modems, it doesn't : >think there are any modems available for the incoming calls. However: in : >some other displayable tables, the PRI card itself is saying that both : >the modems and the ISDN gateway (a Netserver, in this case) are : >available. : : Not that it should affect it, but change your ISDN GW to 0, let the : quads handle it...you'll be much better off with it. I thought the ISDN GW was supposed to be the Netserver or HARC. I guess not. : The other thing to check is on the modems, make sure they are set to : line src of pritdm and not t1tdm. Right. Thanks.

Thus spake Mark R. Lindsey >: >Our problem is this: the dual PRI won't take any calls. My theory is >: >that because it's not showing a mapping of DS0s to modems, it doesn't >: >think there are any modems available for the incoming calls. However: in >: >some other displayable tables, the PRI card itself is saying that both >: >the modems and the ISDN gateway (a Netserver, in this case) are >: >available. >: >: Not that it should affect it, but change your ISDN GW to 0, let the >: quads handle it...you'll be much better off with it. >I thought the ISDN GW was supposed to be the Netserver or HARC. I guess not. The ISDN GW is the card(s) that the PRI card hands off ISDN calls to in order to handle the ISDN data signaling. The NETServer can do this because of the Munich daughter card, you're better off letting the quads handle it though (indicate this by setting the gw to 0) >: The other thing to check is on the modems, make sure they are set to >: line src of pritdm and not t1tdm. >Right. Thanks. There are other things that can cause what you were/are seeing, but this is the first thing I check. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Tatai SV Krishnan >On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote: >> What version of the codes are you running on the ARC, DSP's and Quads? >> >> Also can anyone else confirm that we're _not_ supposed to be shooting the >> MTU value in radius? >> >This has nothing to do with HiPer arc code or DSP or Quad code. For all >HiPer arcs you either set the MTU to 1500 or do not set any value. >Setting the MTU to a lower value other than 1500 will cause users unable >to browse certain websites. Boy is *that* an oversimplification of the situation. Care to expound on *why* this occurs? Are we talking about broken path mtu discovery here or what? if so, where is it broken? if not, what else is causing this? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

: The ISDN GW is the card(s) that the PRI card hands off ISDN calls to in : order to handle the ISDN data signaling. The NETServer can do this : because of the Munich daughter card, you're better off letting the quads : handle it though (indicate this by setting the gw to 0) Aha. The console interface won't let you configure this to 0, so I set it to `None'. : >: The other thing to check is on the modems, make sure they are set to : >: line src of pritdm and not t1tdm. : : >Right. Thanks. : : There are other things that can cause what you were/are seeing, but this : is the first thing I check. :) I verified that that was setup, and I see no change. Should the DS0 status (Main Menu -> 2 -> 6 or 8) show modem cards together with slots? This may be related: When I try to change the slot devices from Qbch-I_mdm to Qbch-Mdm, I get a bunch of errors. Here's a log of an attempt to do so. (Scanning over the archives, I see that this has been mentioned before.) Chassis Slot Device Configuration Status Current Configuration Status Device Device Slot# Type Slot# Type 1 Dual-PRI 9 Qbch-I_mdm 2 NONE 10 Qbch-I_mdm 3 Qbch-I_mdm 11 Qbch-I_mdm 4 Qbch-I_mdm 12 Qbch-I_mdm 5 Qbch-I_mdm 13 Qbch-I_mdm 6 Qbch-I_mdm 14 Qbch-I_mdm 7 Qbch-I_mdm 15 NONE 8 Qbch-I_mdm 16 ISDN-GW Assign device types to chassis slot numbers given the format below: DEVICE_TYPE#:S#[,S#,S#-S#] Where, DEVICE_TYPE# -> q - QBCH-MDM,g - ISDN-GW,n - NONE (no ISDN Device in Slot) i - QBCH-I_MDM,S# -> Chassis Slot# (1-16) Example: q:4,5 assigns the QBCH-MDM NAC device type to slots 4 and 5. >: q:3-14ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 eRROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1 ERROR uccpbus_closed_cb: handle >0< being closed is invalid. ERROR uccpbus_closed_cb: handle >1< being closed is invalid. ERROR uccpbus_closed_cb: handle >2< being closed is invalid. ERROR uccpbus_closed_cb: handle >3< being closed is invalid. ERROR uccpbus_opened_cb: handle >49< already up OR not pending. ERROR uccpbus_opened_cb: handle >50< already up OR not pending. ERROR uccpbus_opened_cb: handle >51< already up OR not pending. ERROR uccpbus_opened_cb: handle >52< already up OR not pending. ERROR uccpbus_closed_cb: handle >4< being closed is invalid. ERROR uccpbus_closed_cb: handle >5< being closed is invalid. ERROR uccpbus_closed_cb: handle >6< being closed is invalid. ERROR uccpbus_closed_cb: handle >7< being closed is invalid. ERROR uccpbus_opened_cb: handle >53< already up OR not pending. ERROR uccpbus_opened_cb: handle >54< already up OR not pending. ERROR uccpbus_opened_cb: handle >55< already up OR not pending. ERROR uccpbus_opened_cb: handle >56< already up OR not pending. ERROR uccpbus_closed_cb: handle >8< being closed is invalid. ERROR uccpbus_closed_cb: handle >9< being closed is invalid. ERROR uccpbus_closed_cb: handle >10< being closed is invalid. ERROR uccpbus_closed_cb: handle >11< being closed is invalid. ERROR uccpbus_opened_cb: handle >57< already up OR not pending. ERROR uccpbus_opened_cb: handle >58< already up OR not pending. ERROR uccpbus_opened_cb: handle >59< already up OR not pending. ERROR uccpbus_opened_cb: handle >60< already up OR not pending. ERROR uccpbus_closed_cb: handle >12< being closed is invalid. ERROR uccpbus_closed_cb: handle >13< being closed is invalid. ERROR uccpbus_closed_cb: handle >14< being closed is invalid. ERROR uccpbus_closed_cb: handle >15< being closed is invalid. ERROR uccpbus_opened_cb: handle >61< already up OR not pending. ERROR uccpbus_opened_cb: handle >62< already up OR not pending. ERROR uccpbus_opened_cb: handle >63< already up OR not pending. ERROR uccpbus_closed_cb: handle >16< being closed is invalid. ERROR uccpbus_closed_cb: handle >17< being closed is invalid. ERROR uccpbus_closed_cb: handle >18< being closed is invalid. ERROR uccpbus_closed_cb: handle >19< being closed is invalid. ERROR uccpbus_closed_cb: handle >20< being closed is invalid. ERROR uccpbus_closed_cb: handle >21< being closed is invalid. ERROR uccpbus_closed_cb: handle >22< being closed is invalid. ERROR uccpbus_closed_cb: handle >23< being closed is invalid. ERROR uccpbus_closed_cb: handle >24< being closed is invalid. ERROR uccpbus_closed_cb: handle >25< being closed is invalid. ERROR uccpbus_closed_cb: handle >26< being closed is invalid. ERROR uccpbus_closed_cb: handle >27< being closed is invalid. ERROR uccpbus_closed_cb: handle >28< being closed is invalid. ERROR uccpbus_closed_cb: handle >29< being closed is invalid. ERROR uccpbus_closed_cb: handle >30< being closed is invalid. ERROR uccpbus_closed_cb: handle >31< being closed is invalid. ERROR uccpbus_closed_cb: handle >32< being closed is invalid. ERROR uccpbus_closed_cb: handle >33< being closed is invalid. ERROR uccpbus_closed_cb: handle >34< being closed is invalid. ERROR uccpbus_closed_cb: handle >35< being closed is invalid. ERROR uccpbus_closed_cb: handle >36< being closed is invalid. ERROR uccpbus_closed_cb: handle >37< being closed is invalid. ERROR uccpbus_closed_cb: handle >38< being closed is invalid. ERROR uccpbus_closed_cb: handle >39< being closed is invalid. ERROR uccpbus_closed_cb: handle >40< being closed is invalid. ERROR uccpbus_closed_cb: handle >41< being closed is invalid. ERROR uccpbus_closed_cb: handle >42< being closed is invalid. ERROR uccpbus_closed_cb: handle >43< being closed is invalid. ERROR uccpbus_closed_cb: handle >44< being closed is invalid. ERROR uccpbus_closed_cb: handle >45< being closed is invalid. ERROR uccpbus_closed_cb: handle >46< being closed is invalid. ERROR uccpbus_closed_cb: handle >47< being closed is invalid. ERROR uccpbus_closed_cb: handle >49< being closed is invalid. ERROR uccpbus_closed_cb: handle >50< being closed is invalid. ERROR uccpbus_closed_cb: handle >51< being closed is invalid. ERROR uccpbus_closed_cb: handle >52< being closed is invalid. ERROR uccpbus_opened_cb: handle >0< already up OR not pending. ERROR uccpbus_opened_cb: handle >1< already up OR not pending. ERROR uccpbus_opened_cb: handle >2< already up OR not pending. ERROR uccpbus_opened_cb: handle >3< already up OR not pending. ERROR uccpbus_closed_cb: handle >53< being closed is invalid. ERROR uccpbus_closed_cb: handle >54< being closed is invalid. ERROR uccpbus_closed_cb: handle >55< being closed is invalid. ERROR uccpbus_closed_cb: handle >56< being closed is invalid. ERROR uccpbus_opened_cb: handle >4< already up OR not pending. ERROR uccpbus_opened_cb: handle >5< already up OR not pending. ERROR uccpbus_opened_cb: handle >6< already up OR not pending. ERROR uccpbus_opened_cb: handle >7< already up OR not pending. ERROR uccpbus_closed_cb: handle >57< being closed is invalid. ERROR uccpbus_closed_cb: handle >58< being closed is invalid. ERROR uccpbus_closed_cb: handle >59< being closed is invalid. ERROR uccpbus_closed_cb: handle >60< being closed is invalid. ERROR uccpbus_opened_cb: handle >8< already up OR not pending. ERROR uccpbus_opened_cb: handle >9< already up OR not pending. ERROR uccpbus_opened_cb: handle >10< already up OR not pending. ERROR uccpbus_opened_cb: handle >11< already up OR not pending. ERROR uccpbus_closed_cb: handle >61< being closed is invalid. ERROR uccpbus_closed_cb: handle >62< being closed is invalid. ERROR uccpbus_closed_cb: handle >63< being closed is invalid. ERROR uccpbus_opened_cb: handle >12< already up OR not pending. ERROR uccpbus_opened_cb: handle >13< already up OR not pending. ERROR uccpbus_opened_cb: handle >14< already up OR not pending. ERROR uccpbus_opened_cb: handle >15< already up OR not pending. ERROR uccpbus_opened_cb: handle >16< already up OR not pending. ERROR uccpbus_opened_cb: handle >17< already up OR not pending. ERROR uccpbus_opened_cb: handle >18< already up OR not pending. ERROR uccpbus_opened_cb: handle >19< already up OR not pending. ERROR uccpbus_opened_cb: handle >20< already up OR not pending. ERROR uccpbus_opened_cb: handle >21< already up OR not pending. ERROR uccpbus_opened_cb: handle >22< already up OR not pending. ERROR uccpbus_opened_cb: handle >23< already up OR not pending. ERROR uccpbus_opened_cb: handle >24< already up OR not pending. ERROR uccpbus_opened_cb: handle >25< already up OR not pending. ERROR uccpbus_opened_cb: handle >26< already up OR not pending. ERROR uccpbus_opened_cb: handle >27< already up OR not pending. ERROR uccpbus_opened_cb: handle >28< already up OR not pending. ERROR uccpbus_opened_cb: handle >29< already up OR not pending. ERROR uccpbus_opened_cb: handle >30< already up OR not pending. ERROR uccpbus_opened_cb: handle >31< already up OR not pending. ERROR uccpbus_opened_cb: handle >32< already up OR not pending. ERROR uccpbus_opened_cb: handle >33< already up OR not pending. ERROR uccpbus_opened_cb: handle >34< already up OR not pending. ERROR uccpbus_opened_cb: handle >35< already up OR not pending. ERROR uccpbus_opened_cb: handle >36< already up OR not pending. ERROR uccpbus_opened_cb: handle >37< already up OR not pending. ERROR uccpbus_opened_cb: handle >38< already up OR not pending. ERROR uccpbus_opened_cb: handle >39< already up OR not pending. ERROR uccpbus_opened_cb: handle >40< already up OR not pending. ERROR uccpbus_opened_cb: handle >41< already up OR not pending. ERROR uccpbus_opened_cb: handle >42< already up OR not pending. ERROR uccpbus_opened_cb: handle >43< already up OR not pending. ERROR uccpbus_opened_cb: handle >44< already up OR not pending. ERROR uccpbus_opened_cb: handle >45< already up OR not pending. ERROR uccpbus_opened_cb: handle >46< already up OR not pending. ERROR uccpbus_opened_cb: handle >47< already up OR not pending. Card Configuration Current Setting 1 Save current Configuration to NVRAM 2 Restore NVRAM Configuration 3 Restore Default Configuration 4 Timing Source Priority Assignment Span-1=1 Span-2=2 5 Chassis Slot Device Configuration 6 Modem Routing Method Fixed Assignment 7 Configure Local Console Password 8 Change DS0 state on Quad Modem NAC action Disabled 9 Companding Code Configuration U-Law (NOTE: Changing configuration parameters may effect calls in progress.) Enter menu selection and press Return or press Esc to exit. Menu Selection (1-9):

More likely simple packet fragmentation problems. I've seen users mess with their MTU setting and make them too high and have the exact same effect. Jeff Binkley ASA Network Computing u>Thus spake Tatai SV Krishnan u>>On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote: u>>> What version of the codes are you running on the ARC, DSP's and u>>> Quads? u>>> Also can anyone else confirm that we're _not_ supposed to be u>>> shooting the MTU value in radius? u>>This has nothing to do with HiPer arc code or DSP or Quad code. For u>all >HiPer arcs you either set the MTU to 1500 or do not set any u>value. >Setting the MTU to a lower value other than 1500 will cause u>users unable >to browse certain websites. u>Boy is *that* an oversimplification of the situation. Care to expound u>on *why* this occurs? Are we talking about broken path mtu discovery u>here or what? if so, where is it broken? if not, what else is u>causing this? u>-- u>Jeff McAdams Email: jeffm@iglou.com u>Head Network Administrator Voice: (502) 966-3848 u>IgLou Internet Services (800) 436-4456 u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. CMPQwk 1.42-21 9999

On Sat, 13 Mar 1999, Jeff Mcadams wrote: > >This has nothing to do with HiPer arc code or DSP or Quad code. For all > >HiPer arcs you either set the MTU to 1500 or do not set any value. > >Setting the MTU to a lower value other than 1500 will cause users unable > >to browse certain websites. > > Boy is *that* an oversimplification of the situation. Care to expound > on *why* this occurs? Are we talking about broken path mtu discovery > here or what? if so, where is it broken? if not, what else is causing > this? > -- It is not a oversimplification of the situation. Here the situation itself is very simple. Its nothing to do with broken path mtu or discovery here. MTU - here is the MRU requested by the peer and it opten maps locally into the interface as MTU as long as MP is not in use. If you look at the RFC 1661 the MTU that is mapped which is the peer MRU - which is sent in a configure-request message is the maximum size of PPP information field that the implementation can receive. The negotiated MRU is used for both subsequenct NCP negotiations messages and actual user data. This means that the actual MRU negotiated must be atlesat as large as the largest negotiation messages or user datagram sent. In particualr if this value is smaill the it may need to be alterned to allow authentication to proceed. Some implementations are requried to accept a PPP information field of atleast 1500 octets at all times, regardless of the negotiated value. Some implementations caluculate this value based on connection speed, but then again in case of speed greater than 14.4 K this is not worthwile. Hiper arc is implemented in sucha a way that the value here should be 1500 buytes at all times. Krish > 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. >

On Sat, 13 Mar 1999, Jeff Mcadams wrote: > So how does the HiPer Arc respond if the MTU/MRU is set (either on the > interface, default user, or whatever) is set to something other than > 1500 (the default on the default user from what I've seen is 1514, so > please comment on when its set higher than 1500 and lower). > -- The default user is set to a value of 1514. Eventhough only 1500 is set and used, the default user setup is still set to 1514. There is a open issue where we have requested this value to be set at 1500. If the radius server sends a MTU then the default user MTU is not applied. Meaning - the default user is a template so when a user is authenticated via radius - all values that are sent by radius are applied to the user and other values that are not sent by the radius are taken from the default user. So if you do not send a MTU then the default user MTU is used. I have never tried sending a MTU value greater than 1500 from radius. I am not sure what will happen if this is done. Need to get back to you on this issue. krish > 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. >

I just saw the Mediagate universal messaging box at ISPF and must say it was one of the few things I was impressed with at the show. However, it had a couple of drawbacks (IMHO), it runs on NT (no flames please), and I hate the $39 per mailbox "license fee" they charge for each person you setup on YOUR OWN HARDWARE. It sure would be swell if I could turn my TC's into a massive universal messaging gateway. If wishes were fishes... Does anyone know of any other similar products?

Once upon a time Ricky Beam shaped the electrons to say... >Seimens is the ones who payed for the development of VoIP in the TC. >(Maybe I want to move to Chicago after all :-)) Not if what I heard from a number of people at ISPF is true, that there is heavy downsizing in Chicago. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Robert von Bismarck shaped the electrons to say... > Disabled Modules: OSPF BGP > >Why mention it, if it's not inside or planned ? (I never tried to use it as >it would have been pretty useless for me) All ComOS builds, from the tiny OR to the mighty PM-4, come from the same code tree. There is a stub where the BGP code would be if it were included, but there has never been any intention of actually putting it in a PM-2. My OR-U has the same thing. It is disabled - and cannot be enabled on that platform. -MZ -- -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Stephen Amadei shaped the electrons to say... >VSA's in my dictionary file, using the complaints RADIUS had when it >encountered an unknown attribute. My dictionary.3com: > >ATTRIBUTE Vendor-Specific 26 string >ATTRIBUTE Acct-Multi-Session-ID 50 string >ATTRIBUTE Acct-Link-Count 51 string This is the current Cistron 3Com dictionary - I don't know of the OS/2 port has the full 3Com VSA support, it was added fairly recently. # # dictionary.usr USR Robotics dictionary. # # Taken from the dictionary included with the USR RADIUS server, # and adjusted a bit. # # Version: @(#)dictionary.usr 1.10 11-Nov-1998 miquels@cistron.nl # # # USR specific attributes # # Prompt value should be 1 for echo, 0 for no echo, default 1. #ATTRIBUTE Prompt 64 integer ATTRIBUTE Multi-Link-Flag 126 integer ATTRIBUTE Char-Noecho 250 integer # # USR specific Integer Translations # VALUE Termination-Action Manage-Resources 2 VALUE Service-Type Authenticate-User 8 VALUE Service-Type Dialback-NAS-User 9 VALUE Acct-Status-Type Modem-Start 4 VALUE Acct-Status-Type Modem-Stop 5 VALUE Acct-Status-Type Cancel 6 VALUE Multi-Link-Flag True 1 VALUE Multi-Link-Flag False 0 # USR specific Authentication Types VALUE Acct-Authentic None 0 VALUE Acct-Authentic Remote 3 VALUE Acct-Authentic RADIUS 4 VALUE Acct-Authentic MNET 5 VALUE Acct-Authentic KCHAP 6 VALUE Acct-Authentic TACACS 7 VALUE Acct-Authentic Realm 8 VALUE Acct-Authentic Local 9 VALUE Acct-Authentic File 10 VALUE Acct-Authentic Local-VPN 11 # # USR Extensions: USR Vendor-Specific stuff. # # For now in NMC format (whatever that stands for), though the # normal vendor-specific format would work just as well. # # ATTRIB_NMC USR-Last-Number-Dialed-Out 0x0066 string ATTRIB_NMC USR-Last-Number-Dialed-In-DNIS 0x00E8 string ATTRIB_NMC USR-Last-Callers-Number-ANI 0x00E9 string ATTRIB_NMC USR-Channel 0xBF38 integer ATTRIB_NMC USR-Event-Id 0xBFBE integer ATTRIB_NMC USR-Event-Date-Time 0xBF2F date ATTRIB_NMC USR-Call-Start-Date-Time 0xBFF7 date ATTRIB_NMC USR-Call-End-Date-Time 0xBFF6 date ATTRIB_NMC USR-Default-DTE-Data-Rate 0x005E integer ATTRIB_NMC USR-Initial-Rx-Link-Data-Rate 0xBF2D integer ATTRIB_NMC USR-Final-Rx-Link-Data-Rate 0xBF2C integer ATTRIB_NMC USR-Initial-Tx-Link-Data-Rate 0x006A integer ATTRIB_NMC USR-Final-Tx-Link-Data-Rate 0x006B integer ATTRIB_NMC USR-Chassis-Temperature 0xBF31 integer ATTRIB_NMC USR-Chassis-Temp-Threshold 0xBE84 integer ATTRIB_NMC USR-Actual-Voltage 0xBF32 integer ATTRIB_NMC USR-Expected-Voltage 0xBF33 integer ATTRIB_NMC USR-Power-Supply-Number 0xBF34 integer ATTRIB_NMC USR-Card-Type 0xBE85 integer ATTRIB_NMC USR-Chassis-Slot 0xBF39 integer ATTRIB_NMC USR-Sync-Async-Mode 0x0067 integer ATTRIB_NMC USR-Originate-Answer-Mode 0x0068 integer ATTRIB_NMC USR-Modulation-Type 0x006C integer ATTRIB_NMC USR-Connect-Term-Reason 0x009B integer ATTRIB_NMC USR-Failure-to-Connect-Reason 0x0069 integer ATTRIB_NMC USR-Equalization-Type 0x006F integer ATTRIB_NMC USR-Fallback-Enabled 0x0070 integer ATTRIB_NMC USR-Connect-Time-Limit 0xBFE7 integer ATTRIB_NMC USR-Number-of-Rings-Limit 0xBFE6 integer ATTRIB_NMC USR-DTE-Data-Idle-Timout 0x0048 integer ATTRIB_NMC USR-Characters-Sent 0x0071 integer ATTRIB_NMC USR-Characters-Received 0x0072 integer ATTRIB_NMC USR-Blocks-Sent 0x0075 integer ATTRIB_NMC USR-Blocks-Received 0x0076 integer ATTRIB_NMC USR-Blocks-Resent 0x0077 integer ATTRIB_NMC USR-Retrains-Requested 0x0078 integer ATTRIB_NMC USR-Retrains-Granted 0x0079 integer ATTRIB_NMC USR-Line-Reversals 0x007A integer ATTRIB_NMC USR-Number-Of-Characters-Lost 0x007B integer ATTRIB_NMC USR-Number-of-Blers 0x007D integer ATTRIB_NMC USR-Number-of-Link-Timeouts 0x007E integer ATTRIB_NMC USR-Number-of-Fallbacks 0x007F integer ATTRIB_NMC USR-Number-of-Upshifts 0x0080 integer ATTRIB_NMC USR-Number-of-Link-NAKs 0x0081 integer ATTRIB_NMC USR-DTR-False-Timeout 0x00BE integer ATTRIB_NMC USR-Fallback-Limit 0x00BF integer ATTRIB_NMC USR-Block-Error-Count-Limit 0x00C0 integer ATTRIB_NMC USR-DTR-True-Timeout 0x00DA integer ATTRIB_NMC USR-Security-Login-Limit 0xBEDE integer ATTRIB_NMC USR-Security-Resp-Limit 0xBEFA integer ATTRIB_NMC USR-DTE-Ring-No-Answer-Limit 0xBF17 integer ATTRIB_NMC USR-Back-Channel-Data-Rate 0x007C integer ATTRIB_NMC USR-Simplified-MNP-Levels 0x0099 integer ATTRIB_NMC USR-Simplified-V42bis-Usage 0x00C7 integer ATTRIB_NMC USR-Mbi_Ct_PRI_Card_Slot 0x0184 integer ATTRIB_NMC USR-Mbi_Ct_TDM_Time_Slot 0x0185 integer ATTRIB_NMC USR-Mbi_Ct_PRI_Card_Span_Line 0x0186 integer ATTRIB_NMC USR-Mbi_Ct_BChannel_Used 0x0187 integer ATTRIB_NMC USR-Physical-State 0xBE77 integer ATTRIB_NMC USR-Packet-Bus-Session 0xBF14 integer ATTRIB_NMC USR-Server-Time 0xF000 date # 0xBE5D-0xBE63 sent with Event-Id 79 ATTRIB_NMC USR-Channel-Connected-To 0xBE5D integer ATTRIB_NMC USR-Slot-Connected-To 0xBE5E integer ATTRIB_NMC USR-Device-Connected-To 0xBE5F integer ATTRIB_NMC USR-NFAS-ID 0xBE60 integer ATTRIB_NMC USR-Q931-Call-Reference-Value 0xBE61 integer ATTRIB_NMC USR-Call-Event-Code 0xBE62 integer ATTRIB_NMC USR-DS0 0xBE63 integer # DS0s sent with Event-Id 77,78 ATTRIB_NMC USR-DS0s 0xBE64 string # Gateway-IP-Address sent with Event-Id 71,72 ATTRIB_NMC USR-Gateway-IP-Address 0xBE66 ipaddr # # These are CCA Radius attributes # ATTRIB_NMC USR-PW_USR_IFilter_IP 0x9000 string ATTRIB_NMC USR-PW_USR_IFilter_IPX 0x9001 string ATTRIB_NMC USR-PW_USR_OFilter_IP 0x9003 string ATTRIB_NMC USR-PW_USR_OFilter_IPX 0x9004 string ATTRIB_NMC USR-PW_USR_OFilter_SAP 0x9005 string ATTRIB_NMC USR-PW_VPN_ID 0x9006 string ATTRIB_NMC USR-PW_VPN_Name 0x9007 string ATTRIB_NMC USR-PW_VPN_Neighbor 0x9008 string ATTRIB_NMC USR-PW_Framed_Routing_V2 0x9009 string ATTRIB_NMC USR-PW_VPN_Gateway 0x900a string ATTRIB_NMC USR-PW_Tunnel_Authentication 0x900b string ATTRIB_NMC USR-PW_Index 0x900c string ATTRIB_NMC USR-PW_Cutoff 0x900d string ATTRIB_NMC USR-PW_Packet 0x900e string ATTRIB_NMC USR-Primary_DNS_Server 0x900f ipaddr ATTRIB_NMC USR-Secondary_DNS_Server 0x9010 ipaddr ATTRIB_NMC USR-Primary_NBNS_Server 0x9011 ipaddr ATTRIB_NMC USR-Secondary_NBNS_Server 0x9012 ipaddr ATTRIB_NMC USR-Syslog-Tap 0x9013 integer ATTRIB_NMC USR-Chassis-Call-Slot 0x9019 integer ATTRIB_NMC USR-Chassis-Call-Span 0x901A integer ATTRIB_NMC USR-Chassis-Call-Channel 0x901B integer ATTRIB_NMC USR-Keypress-Timeout 0x901C integer ATTRIB_NMC USR-Unauthenticated-Time 0x901D integer ATTRIB_NMC USR-Connect-Speed 0x9023 integer ATTRIB_NMC USR-Framed_IP_Address_Pool_Name 0x9024 string ATTRIB_NMC USR-MP-EDO 0x9025 string # # Pilgrim attributes # ATTRIB_NMC USR-Bearer-Capabilities 0x9800 integer ATTRIB_NMC USR-Speed-Of-Connection 0x9801 integer ATTRIB_NMC USR-Max-Channels 0x9802 integer ATTRIB_NMC USR-Channel-Expansion 0x9803 integer ATTRIB_NMC USR-Channel-Decrement 0x9804 integer ATTRIB_NMC USR-Expansion-Algorithm 0x9805 integer ATTRIB_NMC USR-Compression-Algorithm 0x9806 integer ATTRIB_NMC USR-Receive-Acc-Map 0x9807 integer ATTRIB_NMC USR-Transmit-Acc-Map 0x9808 integer ATTRIB_NMC USR-Compression-Reset-Mode 0x980a integer ATTRIB_NMC USR-Min-Compression-Size 0x980b integer ATTRIB_NMC USR-IP 0x980c integer ATTRIB_NMC USR-IPX 0x980d integer ATTRIB_NMC USR-Filter-Zones 0x980e integer ATTRIB_NMC USR-Appletalk 0x980f integer ATTRIB_NMC USR-Bridging 0x9810 integer ATTRIB_NMC USR-Spoofing 0x9811 integer ATTRIB_NMC USR-Host-Type 0x9812 integer ATTRIB_NMC USR-Send-Name 0x9813 string ATTRIB_NMC USR-Send-Password 0x9814 string ATTRIB_NMC USR-Start-Time 0x9815 integer ATTRIB_NMC USR-End-Time 0x9816 integer ATTRIB_NMC USR-Send-Script1 0x9817 string ATTRIB_NMC USR-Reply-Script1 0x9818 string ATTRIB_NMC USR-Send-Script2 0x9819 string ATTRIB_NMC USR-Reply-Script2 0x981a string ATTRIB_NMC USR-Send-Script3 0x981b string ATTRIB_NMC USR-Reply-Script3 0x981c string ATTRIB_NMC USR-Send-Script4 0x981d string ATTRIB_NMC USR-Reply-Script4 0x981e string ATTRIB_NMC USR-Send-Script5 0x981f string ATTRIB_NMC USR-Reply-Script5 0x9820 string ATTRIB_NMC USR-Send-Script6 0x9821 string ATTRIB_NMC USR-Reply-Script6 0x9822 string ATTRIB_NMC USR-Terminal-Type 0x9823 string ATTRIB_NMC USR-Appletalk-Network-Range 0x9824 integer ATTRIB_NMC USR-Local-IP-Address 0x9825 string ATTRIB_NMC USR-Routing-Protocol 0x9826 integer ATTRIB_NMC USR-Modem-Group 0x9827 integer ATTRIB_NMC USR-Modem-Training-Time 0x9842 integer ATTRIB_NMC USR-Interface-Index 0x9843 integer ATTRIB_NMC USR-MP-MRRU 0x982f integer # Virtual Private Network Extensions # ATTRIB_NMC USR-VPN-ID 36870 integer ATTRIB_NMC USR-VPN-Name 36871 string ATTRIB_NMC USR-VPN-Neighbor 36872 ipaddr ATTRIB_NMC USR-RIPV2 36873 integer ATTRIB_NMC USR-VPN-Gateway 36874 string ATTRIB_NMC USR-VPN-Auth-Vector 36875 string ATTRIB_NMC USR-RQ_INDEX 36876 integer #USR_ATTRIBUTE User-Cutoff 36877 integer ATTRIB_NMC USR-PACKET 36878 string ATTRIB_NMC USR-IP-Filter-In 36864 string ATTRIB_NMC USR-IPX-Filter-In 36865 string ATTRIB_NMC USR-SAP-Filter-In 36866 string ATTRIB_NMC USR-IP-Filter-Out 36867 string ATTRIB_NMC USR-IPX-Filter-Out 36868 string ATTRIB_NMC USR-SAP-Filter-Out 36869 string ATTRIB_NMC USR-Syslog-Tap 36883 integer ATTRIB_NMC USR-MIC 36884 string ATTRIB_NMC USR-Log-Filter-Packets 36887 string ATTRIB_NMC USR-Chassis-Call-Slot 36889 integer ATTRIB_NMC USR-Chassis-Call-Span 36890 integer ATTRIB_NMC USR-Chassis-Call-Channel 36891 integer ATTRIB_NMC USR-Keypress-Timeout 36892 integer ATTRIB_NMC USR-Unauthenticated-Time 36893 integer ATTRIB_NMC USR-VPN-Encrypter 36894 integer ATTRIB_NMC USR-Re-Chap-Timeout 36896 integer ATTRIB_NMC USR-Tunnel-Switch-Endpoint 39016 string # End of VPN crap # # Integer Translations # #VALUE USR-Character-Echo Echo-On 0 #VALUE USR-Character-Echo Echo-Off 1 VALUE USR-RIPV2 Off 0 VALUE USR-RIPV2 On 1 VALUE USR-Syslog-Tap Off 0 VALUE USR-Syslog-Tap On-Raw 1 VALUE USR-Syslog-Tap On-Framed 2 VALUE USR-Syslog-Tap Unknown 4294967295 # Event Indentifiers VALUE USR-Event-Id Module-Inserted 6 VALUE USR-Event-Id Module-Removed 7 VALUE USR-Event-Id PSU-Voltage-Alarm 8 VALUE USR-Event-Id PSU-Failed 9 VALUE USR-Event-Id HUB-Temp-Out-of-Range 10 VALUE USR-Event-Id Fan-Failed 11 VALUE USR-Event-Id Watchdog-Timeout 12 VALUE USR-Event-Id Mgmt-Bus-Failure 13 VALUE USR-Event-Id In-Connection-Est 14 VALUE USR-Event-Id Out-Connection-Est 15 VALUE USR-Event-Id In-Connection-Term 16 VALUE USR-Event-Id Out-Connection-Term 17 VALUE USR-Event-Id Connection-Failed 18 VALUE USR-Event-Id Connection-Timeout 19 VALUE USR-Event-Id DTE-Transmit-Idle 20 VALUE USR-Event-Id DTR-True 21 VALUE USR-Event-Id DTR-False 22 VALUE USR-Event-Id Block-Error-at-Threshold 23 VALUE USR-Event-Id Fallbacks-at-Threshold 24 VALUE USR-Event-Id No-Dial-Tone-Detected 25 VALUE USR-Event-Id No-Loop-Current-Detected 26 VALUE USR-Event-Id Yellow-Alarm 27 VALUE USR-Event-Id Red-Alarm 28 VALUE USR-Event-Id Loss-Of-Signal 29 VALUE USR-Event-Id Rcv-Alrm-Ind-Signal 30 VALUE USR-Event-Id Timing-Source-Switch 31 VALUE USR-Event-Id Modem-Reset-by-DTE 32 VALUE USR-Event-Id Modem-Ring-No-Answer 33 VALUE USR-Event-Id DTE-Ring-No-Answer 34 VALUE USR-Event-Id Pkt-Bus-Session-Active 35 VALUE USR-Event-Id Pkt-Bus-Session-Congestion 36 VALUE USR-Event-Id Pkt-Bus-Session-Lost 37 VALUE USR-Event-Id Pkt-Bus-Session-Inactive 38 VALUE USR-Event-Id User-Interface-Reset 39 VALUE USR-Event-Id Gateway-Port-Out-of-Service 40 VALUE USR-Event-Id Gateway-Port-Link-Active 41 VALUE USR-Event-Id Dial-Out-Login-Failure 42 VALUE USR-Event-Id Dial-In-Login-Failure 43 VALUE USR-Event-Id Dial-Out-Restricted-Number 44 VALUE USR-Event-Id Dial-Back-Restricted-Number 45 VALUE USR-Event-Id User-Blacklisted 46 VALUE USR-Event-Id Attempted-Login-Blacklisted 47 VALUE USR-Event-Id Response-Attempt-Limit-Exceeded 48 VALUE USR-Event-Id Login-Attempt-Limit-Exceeded 49 VALUE USR-Event-Id Dial-Out-Call-Duration 50 VALUE USR-Event-Id Dial-In-Call-Duration 51 VALUE USR-Event-Id Pkt-Bus-Session-Err-Status 52 VALUE USR-Event-Id NMC-AutoRespnse-Trap 53 VALUE USR-Event-Id Acct-Server-Contact-Loss 54 VALUE USR-Event-Id Yellow-Alarm-Clear 55 VALUE USR-Event-Id Red-Alarm-Clear 56 VALUE USR-Event-Id Loss-Of-Signal-Clear 57 VALUE USR-Event-Id Rcv-Alrm-Ind-Signal-Clear 58 VALUE USR-Event-Id Incoming-Connection-Established 59 VALUE USR-Event-Id Outgoing-Connection-Established 60 VALUE USR-Event-Id Incoming-Connection-Terminated 61 VALUE USR-Event-Id Outgoing-Connection-Terminated 62 VALUE USR-Event-Id Connection-Attempt-Failure 63 VALUE USR-Event-Id Continuous-CRC-Alarm 64 VALUE USR-Event-Id Continuous-CRC-Alarm-Clear 65 VALUE USR-Event-Id Physical-State-Change 66 VALUE USR-Event-Id Gateway-Network-Failed 71 VALUE USR-Event-Id Gateway-Network-Restored 72 VALUE USR-Event-Id Packet-Bus-Clock-Lost 73 VALUE USR-Event-Id Packet-Bus-Clock-Restored 74 VALUE USR-Event-Id D-Channel-In-Service 75 VALUE USR-Event-Id D-Channel-Out-of-Service 76 VALUE USR-Event-Id DS0s-In-Service 77 VALUE USR-Event-Id DS0s-Out-of-Service 78 VALUE USR-Event-Id T1/T1PRI/E1PRI-Call-Event 79 VALUE USR-Event-Id Psu-Incompatible 80 VALUE USR-Card-Type SlotEmpty 1 VALUE USR-Card-Type SlotUnknown 2 VALUE USR-Card-Type NetwMgtCard 3 VALUE USR-Card-Type DualT1NAC 4 VALUE USR-Card-Type DualModemNAC 5 VALUE USR-Card-Type QuadModemNAC 6 VALUE USR-Card-Type TrGatewayNAC 7 VALUE USR-Card-Type X25GatewayNAC 8 VALUE USR-Card-Type DualV34ModemNAC 9 VALUE USR-Card-Type QuadV32DigitalModemNAC 10 VALUE USR-Card-Type QuadV32AnalogModemNAC 11 VALUE USR-Card-Type QuadV32DigAnlModemNAC 12 VALUE USR-Card-Type QuadV34DigModemNAC 13 VALUE USR-Card-Type QuadV34AnlModemNAC 14 VALUE USR-Card-Type QuadV34DigAnlModemNAC 15 VALUE USR-Card-Type SingleT1NAC 16 VALUE USR-Card-Type EthernetGatewayNAC 17 VALUE USR-Card-Type AccessServer 18 VALUE USR-Card-Type 486TrGatewayNAC 19 VALUE USR-Card-Type 486EthernetGatewayNAC 20 VALUE USR-Card-Type DualRS232NAC 22 VALUE USR-Card-Type 486X25GatewayNAC 23 VALUE USR-Card-Type ApplicationServerNAC 25 VALUE USR-Card-Type ISDNGatewayNAC 26 VALUE USR-Card-Type ISDNpriT1NAC 27 VALUE USR-Card-Type ClkedNetMgtCard 28 VALUE USR-Card-Type ModemPoolManagementNAC 29 VALUE USR-Card-Type ModemPoolNetserverNAC 30 VALUE USR-Card-Type ModemPoolV34ModemNAC 31 VALUE USR-Card-Type ModemPoolISDNNAC 32 VALUE USR-Card-Type NTServerNAC 33 VALUE USR-Card-Type QuadV34DigitalG2NAC 34 VALUE USR-Card-Type QuadV34AnalogG2NAC 35 VALUE USR-Card-Type QuadV34DigAnlgG2NAC 36 VALUE USR-Card-Type NETServerFrameRelayNAC 37 VALUE USR-Card-Type NETServerTokenRingNAC 38 VALUE USR-Card-Type X2524ChannelNAC 39 VALUE USR-Card-Type WirelessGatewayNac 42 VALUE USR-Card-Type EnhancedAccessServer 44 VALUE USR-Card-Type EnhancedISDNGatewayNAC 45 VALUE USR-Card-Type DualT1NIC 1001 VALUE USR-Card-Type DualAlogMdmNIC 1002 VALUE USR-Card-Type QuadDgtlMdmNIC 1003 VALUE USR-Card-Type QuadAlogDgtlMdmNIC 1004 VALUE USR-Card-Type TokenRingNIC 1005 VALUE USR-Card-Type SingleT1NIC 1006 VALUE USR-Card-Type EthernetNIC 1007 VALUE USR-Card-Type ShortHaulDualT1NIC 1008 VALUE USR-Card-Type DualAlogMgdIntlMdmNIC 1009 VALUE USR-Card-Type X25NIC 1010 VALUE USR-Card-Type QuadAlogNonMgdMdmNIC 1011 VALUE USR-Card-Type QuadAlogMgdIntlMdmNIC 1012 VALUE USR-Card-Type QuadAlogNonMgdIntlMdmNIC 1013 VALUE USR-Card-Type QuadLsdLiMgdMdmNIC 1014 VALUE USR-Card-Type QuadLsdLiNonMgdMdmNIC 1015 VALUE USR-Card-Type QuadLsdLiMgdIntlMdmNIC 1016 VALUE USR-Card-Type QuadLsdLiNonMgdIntlMdmNIC 1017 VALUE USR-Card-Type HSEthernetWithV35NIC 1018 VALUE USR-Card-Type HSEthernetWithoutV35NIC 1019 VALUE USR-Card-Type DualHighSpeedV35NIC 1020 VALUE USR-Card-Type QuadV35RS232LowSpeedNIC 1021 VALUE USR-Card-Type DualE1NIC 1022 VALUE USR-Card-Type ShortHaulDualE1NIC 1023 VALUE USR-Card-Type BellcoreLongHaulDualT1NIC 1025 VALUE USR-Card-Type BellcoreShrtHaulDualT1NIC 1026 VALUE USR-Card-Type SCSIEdgeServerNIC 1027 VALUE USR-Default-DTE-Data-Rate 110-BPS 1 VALUE USR-Default-DTE-Data-Rate 300-BPS 2 VALUE USR-Default-DTE-Data-Rate 600-BPS 3 VALUE USR-Default-DTE-Data-Rate 1200-BPS 4 VALUE USR-Default-DTE-Data-Rate 2400-BPS 5 VALUE USR-Default-DTE-Data-Rate 4800-BPS 6 VALUE USR-Default-DTE-Data-Rate 7200-BPS 7 VALUE USR-Default-DTE-Data-Rate 9600-BPS 8 VALUE USR-Default-DTE-Data-Rate 12K-BPS 9 VALUE USR-Default-DTE-Data-Rate 14.4K-BPS 10 VALUE USR-Default-DTE-Data-Rate 16.8-BPS 11 VALUE USR-Default-DTE-Data-Rate 19.2K-BPS 12 VALUE USR-Default-DTE-Data-Rate 38.4K-BPS 13 VALUE USR-Default-DTE-Data-Rate 75-BPS 14 VALUE USR-Default-DTE-Data-Rate 450-BPS 15 VALUE USR-Default-DTE-Data-Rate UNKNOWN-BPS 16 VALUE USR-Default-DTE-Data-Rate 57.6K-BPS 17 VALUE USR-Default-DTE-Data-Rate 21.6K-BPS 18 VALUE USR-Default-DTE-Data-Rate 24K-BPS 19 VALUE USR-Default-DTE-Data-Rate 26K-BPS 20 VALUE USR-Default-DTE-Data-Rate 28K-BPS 21 VALUE USR-Default-DTE-Data-Rate 115K-BPS 22 VALUE USR-Initial-Rx-Link-Data-Rate 110-BPS 1 VALUE USR-Initial-Rx-Link-Data-Rate 300-BPS 2 VALUE USR-Initial-Rx-Link-Data-Rate 600-BPS 3 VALUE USR-Initial-Rx-Link-Data-Rate 1200-BPS 4 VALUE USR-Initial-Rx-Link-Data-Rate 2400-XBPS 5 VALUE USR-Initial-Rx-Link-Data-Rate 4800-BPS 6 VALUE USR-Initial-Rx-Link-Data-Rate 7200-BPS 7 VALUE USR-Initial-Rx-Link-Data-Rate 9600-BPS 8 VALUE USR-Initial-Rx-Link-Data-Rate 12K-BPS 9 VALUE USR-Initial-Rx-Link-Data-Rate 14.4K-BPS 10 VALUE USR-Initial-Rx-Link-Data-Rate 16.8-BPS 11 VALUE USR-Initial-Rx-Link-Data-Rate 19.2K-BPS 12 VALUE USR-Initial-Rx-Link-Data-Rate 38.4K-BPS 13 VALUE USR-Initial-Rx-Link-Data-Rate 75-BPS 14 VALUE USR-Initial-Rx-Link-Data-Rate 450-BPS 15 VALUE USR-Initial-Rx-Link-Data-Rate UNKNOWN-BPS 16 VALUE USR-Initial-Rx-Link-Data-Rate 57.6K-BPS 17 VALUE USR-Initial-Rx-Link-Data-Rate 21.6K-BPS 18 VALUE USR-Initial-Rx-Link-Data-Rate 24K-BPS 19 VALUE USR-Initial-Rx-Link-Data-Rate 26K-BPS 20 VALUE USR-Initial-Rx-Link-Data-Rate 28K-BPS 21 VALUE USR-Initial-Rx-Link-Data-Rate 115K-BPS 22 VALUE USR-Initial-Rx-Link-Data-Rate 31K-BPS 23 VALUE USR-Initial-Rx-Link-Data-Rate 33K-BPS 24 VALUE USR-Initial-Rx-Link-Data-Rate 32K-BPS 25 VALUE USR-Initial-Rx-Link-Data-Rate 36K-BPS 26 VALUE USR-Initial-Rx-Link-Data-Rate 40K-BPS 27 VALUE USR-Initial-Rx-Link-Data-Rate 44K-BPS 28 VALUE USR-Initial-Rx-Link-Data-Rate 48K-BPS 29 VALUE USR-Initial-Rx-Link-Data-Rate 49333-BPS 30 VALUE USR-Initial-Rx-Link-Data-Rate 50666-BPS 31 VALUE USR-Initial-Rx-Link-Data-Rate 52K-BPS 32 VALUE USR-Initial-Rx-Link-Data-Rate 53333-BPS 33 VALUE USR-Initial-Rx-Link-Data-Rate 54666-BPS 34 VALUE USR-Initial-Rx-Link-Data-Rate 56K-BPS 35 VALUE USR-Initial-Rx-Link-Data-Rate 57333-BPS 36 VALUE USR-Initial-Rx-Link-Data-Rate 58666-BPS 37 VALUE USR-Initial-Rx-Link-Data-Rate 60K-BPS 38 VALUE USR-Initial-Rx-Link-Data-Rate 61333-BPS 39 VALUE USR-Initial-Rx-Link-Data-Rate 64K-BPS 40 VALUE USR-Final-Rx-Link-Data-Rate 110-BPS 1 VALUE USR-Final-Rx-Link-Data-Rate 300-BPS 2 VALUE USR-Final-Rx-Link-Data-Rate 600-BPS 3 VALUE USR-Final-Rx-Link-Data-Rate 1200-BPS 4 VALUE USR-Final-Rx-Link-Data-Rate 2400-BPS 5 VALUE USR-Final-Rx-Link-Data-Rate 4800-BPS 6 VALUE USR-Final-Rx-Link-Data-Rate 7200-BPS 7 VALUE USR-Final-Rx-Link-Data-Rate 9600-BPS 8 VALUE USR-Final-Rx-Link-Data-Rate 12K-BPS 9 VALUE USR-Final-Rx-Link-Data-Rate 14.4K-BPS 10 VALUE USR-Final-Rx-Link-Data-Rate 16.8-BPS 11 VALUE USR-Final-Rx-Link-Data-Rate 19.2K-BPS 12 VALUE USR-Final-Rx-Link-Data-Rate 38.4K-BPS 13 VALUE USR-Final-Rx-Link-Data-Rate 75-BPS 14 VALUE USR-Final-Rx-Link-Data-Rate 450-BPS 15 VALUE USR-Final-Rx-Link-Data-Rate UNKNOWN-BPS 16 VALUE USR-Final-Rx-Link-Data-Rate 57.6K-BPS 17 VALUE USR-Final-Rx-Link-Data-Rate 21.6K-BPS 18 VALUE USR-Final-Rx-Link-Data-Rate 24K-BPS 19 VALUE USR-Final-Rx-Link-Data-Rate 26K-BPS 20 VALUE USR-Final-Rx-Link-Data-Rate 28K-BPS 21 VALUE USR-Final-Rx-Link-Data-Rate 115K-BPS 22 VALUE USR-Final-Rx-Link-Data-Rate 31K-BPS 23 VALUE USR-Final-Rx-Link-Data-Rate 33K-BPS 24 VALUE USR-Final-Rx-Link-Data-Rate 32K-BPS 25 VALUE USR-Final-Rx-Link-Data-Rate 36K-BPS 26 VALUE USR-Final-Rx-Link-Data-Rate 40K-BPS 27 VALUE USR-Final-Rx-Link-Data-Rate 44K-BPS 28 VALUE USR-Final-Rx-Link-Data-Rate 48K-BPS 29 VALUE USR-Final-Rx-Link-Data-Rate 49333-BPS 30 VALUE USR-Final-Rx-Link-Data-Rate 50666-BPS 31 VALUE USR-Final-Rx-Link-Data-Rate 52K-BPS 32 VALUE USR-Final-Rx-Link-Data-Rate 53333-BPS 33 VALUE USR-Final-Rx-Link-Data-Rate 54666-BPS 34 VALUE USR-Final-Rx-Link-Data-Rate 56K-BPS 35 VALUE USR-Final-Rx-Link-Data-Rate 57333-BPS 36 VALUE USR-Final-Rx-Link-Data-Rate 58666-BPS 37 VALUE USR-Final-Rx-Link-Data-Rate 60K-BPS 38 VALUE USR-Final-Rx-Link-Data-Rate 61333-BPS 39 VALUE USR-Final-Rx-Link-Data-Rate 64K-BPS 40 VALUE USR-Initial-Tx-Link-Data-Rate 110-BPS 1 VALUE USR-Initial-Tx-Link-Data-Rate 300-BPS 2 VALUE USR-Initial-Tx-Link-Data-Rate 600-BPS 3 VALUE USR-Initial-Tx-Link-Data-Rate 1200-BPS 4 VALUE USR-Initial-Tx-Link-Data-Rate 2400-BPS 5 VALUE USR-Initial-Tx-Link-Data-Rate 4800-BPS 6 VALUE USR-Initial-Tx-Link-Data-Rate 7200-BPS 7 VALUE USR-Initial-Tx-Link-Data-Rate 9600-BPS 8 VALUE USR-Initial-Tx-Link-Data-Rate 12K-BPS 9 VALUE USR-Initial-Tx-Link-Data-Rate 14.4K-BPS 10 VALUE USR-Initial-Tx-Link-Data-Rate 16.8-BPS 11 VALUE USR-Initial-Tx-Link-Data-Rate 19.2K-BPS 12 VALUE USR-Initial-Tx-Link-Data-Rate 38.4K-BPS 13 VALUE USR-Initial-Tx-Link-Data-Rate 75-BPS 14 VALUE USR-Initial-Tx-Link-Data-Rate 450-BPS 15 VALUE USR-Initial-Tx-Link-Data-Rate UNKNOWN-BPS 16 VALUE USR-Initial-Tx-Link-Data-Rate 57.6K-BPS 17 VALUE USR-Initial-Tx-Link-Data-Rate 21.6K-BPS 18 VALUE USR-Initial-Tx-Link-Data-Rate 24K-BPS 19 VALUE USR-Initial-Tx-Link-Data-Rate 26K-BPS 20 VALUE USR-Initial-Tx-Link-Data-Rate 28K-BPS 21 VALUE USR-Initial-Tx-Link-Data-Rate 115K-BPS 22 VALUE USR-Initial-Tx-Link-Data-Rate 31K-BPS 23 VALUE USR-Initial-Tx-Link-Data-Rate 33K-BPS 24 VALUE USR-Initial-Tx-Link-Data-Rate 32K-BPS 25 VALUE USR-Initial-Tx-Link-Data-Rate 36K-BPS 26 VALUE USR-Initial-Tx-Link-Data-Rate 40K-BPS 27 VALUE USR-Initial-Tx-Link-Data-Rate 44K-BPS 28 VALUE USR-Initial-Tx-Link-Data-Rate 48K-BPS 29 VALUE USR-Initial-Tx-Link-Data-Rate 49333-BPS 30 VALUE USR-Initial-Tx-Link-Data-Rate 50666-BPS 31 VALUE USR-Initial-Tx-Link-Data-Rate 52K-BPS 32 VALUE USR-Initial-Tx-Link-Data-Rate 53333-BPS 33 VALUE USR-Initial-Tx-Link-Data-Rate 54666-BPS 34 VALUE USR-Initial-Tx-Link-Data-Rate 56K-BPS 35 VALUE USR-Initial-Tx-Link-Data-Rate 57333-BPS 36 VALUE USR-Initial-Tx-Link-Data-Rate 58666-BPS 37 VALUE USR-Initial-Tx-Link-Data-Rate 60K-BPS 38 VALUE USR-Initial-Tx-Link-Data-Rate 61333-BPS 39 VALUE USR-Initial-Tx-Link-Data-Rate 64K-BPS 40 VALUE USR-Final-Tx-Link-Data-Rate 110-BPS 1 VALUE USR-Final-Tx-Link-Data-Rate 300-BPS 2 VALUE USR-Final-Tx-Link-Data-Rate 600-BPS 3 VALUE USR-Final-Tx-Link-Data-Rate 1200-BPS 4 VALUE USR-Final-Tx-Link-Data-Rate 2400-BPS 5 VALUE USR-Final-Tx-Link-Data-Rate 4800-BPS 6 VALUE USR-Final-Tx-Link-Data-Rate 7200-BPS 7 VALUE USR-Final-Tx-Link-Data-Rate 9600-BPS 8 VALUE USR-Final-Tx-Link-Data-Rate 12K-BPS 9 VALUE USR-Final-Tx-Link-Data-Rate 14.4K-BPS 10 VALUE USR-Final-Tx-Link-Data-Rate 16.8-BPS 11 VALUE USR-Final-Tx-Link-Data-Rate 19.2K-BPS 12 VALUE USR-Final-Tx-Link-Data-Rate 38.4K-BPS 13 VALUE USR-Final-Tx-Link-Data-Rate 75-BPS 14 VALUE USR-Final-Tx-Link-Data-Rate 450-BPS 15 VALUE USR-Final-Tx-Link-Data-Rate UNKNOWN-BPS 16 VALUE USR-Final-Tx-Link-Data-Rate 57.6K-BPS 17 VALUE USR-Final-Tx-Link-Data-Rate 21.6K-BPS 18 VALUE USR-Final-Tx-Link-Data-Rate 24K-BPS 19 VALUE USR-Final-Tx-Link-Data-Rate 26K-BPS 20 VALUE USR-Final-Tx-Link-Data-Rate 28K-BPS 21 VALUE USR-Final-Tx-Link-Data-Rate 115K-BPS 22 VALUE USR-Final-Tx-Link-Data-Rate 31K-BPS 23 VALUE USR-Final-Tx-Link-Data-Rate 33K-BPS 24 VALUE USR-Final-Tx-Link-Data-Rate 32K-BPS 25 VALUE USR-Final-Tx-Link-Data-Rate 36K-BPS 26 VALUE USR-Final-Tx-Link-Data-Rate 40K-BPS 27 VALUE USR-Final-Tx-Link-Data-Rate 44K-BPS 28 VALUE USR-Final-Tx-Link-Data-Rate 48K-BPS 29 VALUE USR-Final-Tx-Link-Data-Rate 49333-BPS 30 VALUE USR-Final-Tx-Link-Data-Rate 50666-BPS 31 VALUE USR-Final-Tx-Link-Data-Rate 52K-BPS 32 VALUE USR-Final-Tx-Link-Data-Rate 53333-BPS 33 VALUE USR-Final-Tx-Link-Data-Rate 54666-BPS 34 VALUE USR-Final-Tx-Link-Data-Rate 56K-BPS 35 VALUE USR-Final-Tx-Link-Data-Rate 57333-BPS 36 VALUE USR-Final-Tx-Link-Data-Rate 58666-BPS 37 VALUE USR-Final-Tx-Link-Data-Rate 60K-BPS 38 VALUE USR-Final-Tx-Link-Data-Rate 61333-BPS 39 VALUE USR-Final-Tx-Link-Data-Rate 64K-BPS 40 # Value Connect Speed /* Added by Krish */ VALUE USR-Connect-Speed NONE 0 VALUE USR-Connect-Speed 300_BPS 1 VALUE USR-Connect-Speed 1200_BPS 2 VALUE USR-Connect-Speed 2400_BPS 3 VALUE USR-Connect-Speed 4800_BPS 4 VALUE USR-Connect-Speed 7200_BPS 5 VALUE USR-Connect-Speed 9600_BPS 6 VALUE USR-Connect-Speed 12000_BPS 7 VALUE USR-Connect-Speed 14400_BPS 8 VALUE USR-Connect-Speed 16800_BPS 9 VALUE USR-Connect-Speed 19200_BPS 10 VALUE USR-Connect-Speed 21600_BPS 11 VALUE USR-Connect-Speed 28800_BPS 12 VALUE USR-Connect-Speed 38400_BPS 13 VALUE USR-Connect-Speed 57600_BPS 14 VALUE USR-Connect-Speed 44000_BPS 27 VALUE USR-Connect-Speed 45333_BPS 28 VALUE USR-Connect-Speed 46666_BPS 29 VALUE USR-Connect-Speed 48000_BPS 30 VALUE USR-Connect-Speed 49333_BPS 31 VALUE USR-Connect-Speed 50666_BPS 32 VALUE USR-Connect-Speed 52000_BPS 33 VALUE USR-Connect-Speed 53333_BPS 34 VALUE USR-Connect-Speed 54666_BPS 35 VALUE USR-Connect-Speed 56000_BPS 36 VALUE USR-Connect-Speed 57333_BPS 37 VALUE USR-Connect-Speed 64000_BPS 38 VALUE USR-Connect-Speed 25333_BPS 39 VALUE USR-Connect-Speed 26666_BPS 40 VALUE USR-Connect-Speed 28000_BPS 41 VALUE USR-Connect-Speed 115200_BPS 15 VALUE USR-Connect-Speed 288000_BPS 16 VALUE USR-Connect-Speed 75_1200_BPS 17 VALUE USR-Connect-Speed 1200_75_BPS 18 VALUE USR-Connect-Speed 24000_BPS 19 VALUE USR-Connect-Speed 26400_BPS 20 VALUE USR-Connect-Speed 31200_BPS 21 VALUE USR-Connect-Speed 33600_BPS 22 VALUE USR-Connect-Speed 33333_BPS 23 VALUE USR-Connect-Speed 37333_BPS 24 VALUE USR-Connect-Speed 41333_BPS 25 VALUE USR-Connect-Speed 42666_BPS 26 VALUE USR-Connect-Speed 29333_BPS 42 VALUE USR-Connect-Speed 30666_BPS 43 VALUE USR-Connect-Speed 32000_BPS 44 VALUE USR-Connect-Speed 34666_BPS 45 VALUE USR-Connect-Speed 36000_BPS 46 VALUE USR-Connect-Speed 38666_BPS 47 VALUE USR-Connect-Speed 40000_BPS 48 VALUE USR-Connect-Speed 58666_BPS 49 VALUE USR-Connect-Speed 60000_BPS 50 VALUE USR-Connect-Speed 61333_BPS 51 VALUE USR-Connect-Speed 62666_BPS 52 # End of Connect-Speed / * Added by Krish */ # VALUE USR-Sync-Async-Mode Asynchronous 1 VALUE USR-Sync-Async-Mode Synchronous 2 VALUE USR-Originate-Answer-Mode Originate_in_Originate_Mode 1 VALUE USR-Originate-Answer-Mode Originate_in_Answer_Mode 2 VALUE USR-Originate-Answer-Mode Answer_in_Originate_Mode 3 VALUE USR-Originate-Answer-Mode Answer_in_Answer_Mode 4 VALUE USR-Modulation-Type usRoboticsHST 1 VALUE USR-Modulation-Type ccittV32 2 VALUE USR-Modulation-Type ccittV22bis 3 VALUE USR-Modulation-Type bell103 4 VALUE USR-Modulation-Type ccittV21 5 VALUE USR-Modulation-Type bell212 6 VALUE USR-Modulation-Type ccittV32bis 7 VALUE USR-Modulation-Type ccittV23 8 VALUE USR-Modulation-Type negotiationFailed 9 VALUE USR-Modulation-Type bell208b 10 VALUE USR-Modulation-Type v21FaxClass1 11 VALUE USR-Modulation-Type v27FaxClass1 12 VALUE USR-Modulation-Type v29FaxClass1 13 VALUE USR-Modulation-Type v17FaxClass1 14 VALUE USR-Modulation-Type v21FaxClass2 15 VALUE USR-Modulation-Type v27FaxClass2 16 VALUE USR-Modulation-Type v29FaxClass2 17 VALUE USR-Modulation-Type v17FaxClass2 18 VALUE USR-Modulation-Type v32Terbo 19 VALUE USR-Modulation-Type v34 20 VALUE USR-Modulation-Type vFC 21 VALUE USR-Modulation-Type v34plus 22 VALUE USR-Connect-Term-Reason dtrDrop 1 VALUE USR-Connect-Term-Reason escapeSequence 2 VALUE USR-Connect-Term-Reason athCommand 3 VALUE USR-Connect-Term-Reason carrierLoss 4 VALUE USR-Connect-Term-Reason inactivityTimout 5 VALUE USR-Connect-Term-Reason mnpIncompatible 6 VALUE USR-Connect-Term-Reason undefined 7 VALUE USR-Connect-Term-Reason remotePassword 8 VALUE USR-Connect-Term-Reason linkPassword 9 VALUE USR-Connect-Term-Reason retransmitLimit 10 VALUE USR-Connect-Term-Reason linkDisconnectMsgReceived 11 VALUE USR-Connect-Term-Reason noLoopCurrent 12 VALUE USR-Connect-Term-Reason invalidSpeed 13 VALUE USR-Connect-Term-Reason unableToRetrain 14 VALUE USR-Connect-Term-Reason managementCommand 15 VALUE USR-Connect-Term-Reason noDialTone 16 VALUE USR-Connect-Term-Reason keyAbort 17 VALUE USR-Connect-Term-Reason lineBusy 18 VALUE USR-Connect-Term-Reason noAnswer 19 VALUE USR-Connect-Term-Reason voice 20 VALUE USR-Connect-Term-Reason noAnswerTone 21 VALUE USR-Connect-Term-Reason noCarrier 22 VALUE USR-Connect-Term-Reason undetermined 23 VALUE USR-Connect-Term-Reason v42SabmeTimeout 24 VALUE USR-Connect-Term-Reason v42BreakTimeout 25 VALUE USR-Connect-Term-Reason v42DisconnectCmd 26 VALUE USR-Connect-Term-Reason v42IdExchangeFail 27 VALUE USR-Connect-Term-Reason v42BadSetup 28 VALUE USR-Connect-Term-Reason v42InvalidCodeWord 29 VALUE USR-Connect-Term-Reason v42StringToLong 30 VALUE USR-Connect-Term-Reason v42InvalidCommand 31 VALUE USR-Connect-Term-Reason none 32 VALUE USR-Connect-Term-Reason v32Cleardown 33 VALUE USR-Connect-Term-Reason dialSecurity 34 VALUE USR-Connect-Term-Reason remoteAccessDenied 35 VALUE USR-Connect-Term-Reason loopLoss 36 VALUE USR-Connect-Term-Reason ds0Teardown 37 VALUE USR-Connect-Term-Reason promptNotEnabled 38 VALUE USR-Connect-Term-Reason noPromptingInSync 39 VALUE USR-Connect-Term-Reason nonArqMode 40 VALUE USR-Connect-Term-Reason modeIncompatible 41 VALUE USR-Connect-Term-Reason noPromptInNonARQ 42 VALUE USR-Connect-Term-Reason dialBackLink 43 VALUE USR-Connect-Term-Reason linkAbort 44 VALUE USR-Connect-Term-Reason autopassFailed 45 VALUE USR-Connect-Term-Reason pbGenericError 46 VALUE USR-Connect-Term-Reason pbLinkErrTxPreAck 47 VALUE USR-Connect-Term-Reason pbLinkErrTxTardyACK 48 VALUE USR-Connect-Term-Reason pbTransmitBusTimeout 49 VALUE USR-Connect-Term-Reason pbReceiveBusTimeout 50 VALUE USR-Connect-Term-Reason pbLinkErrTxTAL 51 VALUE USR-Connect-Term-Reason pbLinkErrRxTAL 52 VALUE USR-Connect-Term-Reason pbTransmitMasterTimeout 53 VALUE USR-Connect-Term-Reason pbClockMissing 54 VALUE USR-Connect-Term-Reason pbReceivedLsWhileLinkUp 55 VALUE USR-Connect-Term-Reason pbOutOfSequenceFrame 56 VALUE USR-Connect-Term-Reason pbBadFrame 57 VALUE USR-Connect-Term-Reason pbAckWaitTimeout 58 VALUE USR-Connect-Term-Reason pbReceivedAckSeqErr 59 VALUE USR-Connect-Term-Reason pbReceiveOvrflwRNRFail 60 VALUE USR-Connect-Term-Reason pbReceiveMsgBufOvrflw 61 VALUE USR-Connect-Term-Reason rcvdGatewayDiscCmd 62 VALUE USR-Connect-Term-Reason tokenPassingTimeout 63 VALUE USR-Connect-Term-Reason dspInterruptTimeout 64 VALUE USR-Connect-Term-Reason mnpProtocolViolation 65 VALUE USR-Connect-Term-Reason class2FaxHangupCmd 66 VALUE USR-Connect-Term-Reason hstSpeedSwitchTimeout 67 VALUE USR-Failure-to-Connect-Reason dtrDrop 1 VALUE USR-Failure-to-Connect-Reason escapeSequence 2 VALUE USR-Failure-to-Connect-Reason athCommand 3 VALUE USR-Failure-to-Connect-Reason carrierLoss 4 VALUE USR-Failure-to-Connect-Reason inactivityTimout 5 VALUE USR-Failure-to-Connect-Reason mnpIncompatible 6 VALUE USR-Failure-to-Connect-Reason undefined 7 VALUE USR-Failure-to-Connect-Reason remotePassword 8 VALUE USR-Failure-to-Connect-Reason linkPassword 9 VALUE USR-Failure-to-Connect-Reason retransmitLimit 10 VALUE USR-Failure-to-Connect-Reason linkDisconnectMsgRec 11 VALUE USR-Failure-to-Connect-Reason noLoopCurrent 12 VALUE USR-Failure-to-Connect-Reason invalidSpeed 13 VALUE USR-Failure-to-Connect-Reason unableToRetrain 14 VALUE USR-Failure-to-Connect-Reason managementCommand 15 VALUE USR-Failure-to-Connect-Reason noDialTone 16 VALUE USR-Failure-to-Connect-Reason keyAbort 17 VALUE USR-Failure-to-Connect-Reason lineBusy 18 VALUE USR-Failure-to-Connect-Reason noAnswer 19 VALUE USR-Failure-to-Connect-Reason voice 20 VALUE USR-Failure-to-Connect-Reason noAnswerTone 21 VALUE USR-Failure-to-Connect-Reason noCarrier 22 VALUE USR-Failure-to-Connect-Reason undetermined 23 VALUE USR-Failure-to-Connect-Reason v42SabmeTimeout 24 VALUE USR-Failure-to-Connect-Reason v42BreakTimeout 25 VALUE USR-Failure-to-Connect-Reason v42DisconnectCmd 26 VALUE USR-Failure-to-Connect-Reason v42IdExchangeFail 27 VALUE USR-Failure-to-Connect-Reason v42BadSetup 28 VALUE USR-Failure-to-Connect-Reason v42InvalidCodeWord 29 VALUE USR-Failure-to-Connect-Reason v42StringToLong 30 VALUE USR-Failure-to-Connect-Reason v42InvalidCommand 31 VALUE USR-Failure-to-Connect-Reason none 32 VALUE USR-Failure-to-Connect-Reason v32Cleardown 33 VALUE USR-Failure-to-Connect-Reason dialSecurity 34 VALUE USR-Failure-to-Connect-Reason remoteAccessDenied 35 VALUE USR-Failure-to-Connect-Reason loopLoss 36 VALUE USR-Failure-to-Connect-Reason ds0Teardown 37 VALUE USR-Failure-to-Connect-Reason promptNotEnabled 38 VALUE USR-Failure-to-Connect-Reason noPromptingInSync 39 VALUE USR-Failure-to-Connect-Reason nonArqMode 40 VALUE USR-Failure-to-Connect-Reason modeIncompatible 41 VALUE USR-Failure-to-Connect-Reason noPromptInNonARQ 42 VALUE USR-Failure-to-Connect-Reason dialBackLink 43 VALUE USR-Failure-to-Connect-Reason linkAbort 44 VALUE USR-Failure-to-Connect-Reason autopassFailed 45 VALUE USR-Failure-to-Connect-Reason pbGenericError 46 VALUE USR-Failure-to-Connect-Reason pbLinkErrTxPreAck 47 VALUE USR-Failure-to-Connect-Reason pbLinkErrTxTardyACK 48 VALUE USR-Failure-to-Connect-Reason pbTransmitBusTimeout 49 VALUE USR-Failure-to-Connect-Reason pbReceiveBusTimeout 50 VALUE USR-Failure-to-Connect-Reason pbLinkErrTxTAL 51 VALUE USR-Failure-to-Connect-Reason pbLinkErrRxTAL 52 VALUE USR-Failure-to-Connect-Reason pbTransmitMasterTimeout 53 VALUE USR-Failure-to-Connect-Reason pbClockMissing 54 VALUE USR-Failure-to-Connect-Reason pbReceivedLsWhileLinkUp 55 VALUE USR-Failure-to-Connect-Reason pbOutOfSequenceFrame 56 VALUE USR-Failure-to-Connect-Reason pbBadFrame 57 VALUE USR-Failure-to-Connect-Reason pbAckWaitTimeout 58 VALUE USR-Failure-to-Connect-Reason pbReceivedAckSeqErr 59 VALUE USR-Failure-to-Connect-Reason pbReceiveOvrflwRNRFail 60 VALUE USR-Failure-to-Connect-Reason pbReceiveMsgBufOvrflw 61 VALUE USR-Failure-to-Connect-Reason rcvdGatewayDiscCmd 62 VALUE USR-Failure-to-Connect-Reason tokenPassingTimeout 63 VALUE USR-Failure-to-Connect-Reason dspInterruptTimeout 64 VALUE USR-Failure-to-Connect-Reason mnpProtocolViolation 65 VALUE USR-Failure-to-Connect-Reason class2FaxHangupCmd 66 VALUE USR-Failure-to-Connect-Reason hstSpeedSwitchTimeout 67 VALUE USR-Simplified-MNP-Levels none 1 VALUE USR-Simplified-MNP-Levels mnpLevel3 2 VALUE USR-Simplified-MNP-Levels mnpLevel4 3 VALUE USR-Simplified-MNP-Levels ccittV42 4 VALUE USR-Simplified-MNP-Levels usRoboticsHST 5 VALUE USR-Simplified-MNP-Levels synchronousNone 6 VALUE USR-Simplified-MNP-Levels mnpLevel2 7 VALUE USR-Simplified-MNP-Levels mnp10 8 VALUE USR-Simplified-MNP-Levels v42Etc 9 VALUE USR-Simplified-V42bis-Usage none 1 VALUE USR-Simplified-V42bis-Usage ccittV42bis 2 VALUE USR-Simplified-V42bis-Usage mnpLevel5 3 VALUE USR-Equalization-Type Long 1 VALUE USR-Equalization-Type Short 2 VALUE USR-Fallback-Enabled Disabled 1 VALUE USR-Fallback-Enabled Enabled 2 VALUE USR-Back-Channel-Data-Rate 450BPS 1 VALUE USR-Back-Channel-Data-Rate 300BPS 2 VALUE USR-Back-Channel-Data-Rate None 3 VALUE USR-Device-Connected-To None 1 VALUE USR-Device-Connected-To isdnGateway 2 VALUE USR-Device-Connected-To quadModem 3 VALUE USR-Call-Event-Code notSupported 1 VALUE USR-Call-Event-Code setup 2 VALUE USR-Call-Event-Code usrSetup 3 VALUE USR-Call-Event-Code telcoDisconnect 4 VALUE USR-Call-Event-Code usrDisconnect 5 VALUE USR-Call-Event-Code noFreeModem 6 VALUE USR-Call-Event-Code modemsNotAllowed 7 VALUE USR-Call-Event-Code modemsRejectCall 8 VALUE USR-Call-Event-Code modemSetupTimeout 9 VALUE USR-Call-Event-Code noFreeIGW 10 VALUE USR-Call-Event-Code igwRejectCall 11 VALUE USR-Call-Event-Code igwSetupTimeout 12 VALUE USR-Call-Event-Code noFreeTdmts 13 VALUE USR-Call-Event-Code bcReject 14 VALUE USR-Call-Event-Code ieReject 15 VALUE USR-Call-Event-Code chidReject 16 VALUE USR-Call-Event-Code progReject 17 VALUE USR-Call-Event-Code callingPartyReject 18 VALUE USR-Call-Event-Code calledPartyReject 19 VALUE USR-Call-Event-Code blocked 20 VALUE USR-Call-Event-Code analogBlocked 21 VALUE USR-Call-Event-Code digitalBlocked 22 VALUE USR-Call-Event-Code outOfService 23 VALUE USR-Call-Event-Code busy 24 VALUE USR-Call-Event-Code congestion 25 VALUE USR-Call-Event-Code protocolError 26 VALUE USR-Call-Event-Code noFreeBchannel 27 VALUE USR-Call-Event-Code inOutCallCollision 28

Thus spake Tatai SV Krishnan >On Sat, 13 Mar 1999, Jeff Mcadams wrote: >> Boy is *that* an oversimplification of the situation. Care to expound >> on *why* this occurs? Are we talking about broken path mtu discovery >> here or what? if so, where is it broken? if not, what else is causing >> this? >Some implementations are requried to accept a PPP information field of >atleast 1500 octets at all times, regardless of the negotiated value. >Some implementations caluculate this value based on connection speed, but >then again in case of speed greater than 14.4 K this is not worthwile. >Hiper arc is implemented in sucha a way that the value here should be >1500 buytes at all times. So how does the HiPer Arc respond if the MTU/MRU is set (either on the interface, default user, or whatever) is set to something other than 1500 (the default on the default user from what I've seen is 1514, so please comment on when its set higher than 1500 and lower). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Sat, 13 Mar 1999, Jeff Mcadams wrote: > Boy is *that* an oversimplification of the situation. Care to expound > on *why* this occurs? Are we talking about broken path mtu discovery > here or what? if so, where is it broken? if not, what else is causing > this? WebTV's proxy servers have broken path mtu (theyre running an old version of solaris and refuse to upgrade it) so if you lower the mtu then WebTV users break. -Dan

Thus spake Tatai SV Krishnan >On Sat, 13 Mar 1999, Jeff Mcadams wrote: >> So how does the HiPer Arc respond if the MTU/MRU is set (either on the >> interface, default user, or whatever) is set to something other than >> 1500 (the default on the default user from what I've seen is 1514, so >> please comment on when its set higher than 1500 and lower). >The default user is set to a value of 1514. Eventhough only 1500 is set >and used, the default user setup is still set to 1514. There is a >open issue where we have requested this value to be set at 1500. >If the radius server sends a MTU then the default user MTU is not >applied. Meaning - the default user is a template so when a user is >authenticated via radius - all values that are sent by radius are applied >to the user and other values that are not sent by the radius are taken >from the default user. So if you do not send a MTU then the default user >MTU is used. Right, I understand that...and I have a lot of users getting MTU's of 1514. Also, since the MTU is negotiated in LCP, before the RADIUS response is received in PAP, how is that handled? Does it go ahead and use the value set on the default user. I'm pretty sure it doesn't restart LCP. Does it set its own MTU down without restarting LCP? That would be in spec if the MTU was lowered from what was negotiated in LCP. Other questions...how does it behave if the default user has an MTU set of 576 (a common value), and isn't overridden in RADIUS? What happens when a 1500 byte packet comes at it? drop it? send it anyway? The reason I'm asking and trying to get a good answer here is that from what you're saying, it sounds like the implementation is broken. >I have never tried sending a MTU value greater than 1500 >from radius. I am not sure what will happen if this is done. Need to >get back to you on this issue. I'm *more* concerned about MTU's smaller than 1500. I would also be concerned if an MTU bigger than what was negotiated in LCP was received and used during PAP...that would be broken as well...but I doubt that's happening. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I just picked up a couple Total Control Units. Is the Total Control Manager software required for configuration of these units, of does it just make it easier? Any additional info as to what software I would need for configuration would be appreciated. Also, can you run your primary backbone t-1 line through a t-1 card on this chassis? If not, how would you recommend configuring for the backbone line (i.e. What kind of router / csu / Dsu) Thanks for the help in advance,,, Daniel V. vesledah@teleline.es

As an aside, I've always been confused on this point. On a Cisco, for example, you can set two different(?) mtu values. You have one setting at the IP level and one at the interface level... I guess that means a PPP (L2) value and an IP (L3) value??? Are dialup interfaces the same? Am I totally confused? Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Sat, 13 Mar 1999, Jeff Mcadams wrote: > Thus spake Tatai SV Krishnan > >On Sat, 13 Mar 1999, Jeff Mcadams wrote: > >> So how does the HiPer Arc respond if the MTU/MRU is set (either on the > >> interface, default user, or whatever) is set to something other than > >> 1500 (the default on the default user from what I've seen is 1514, so > >> please comment on when its set higher than 1500 and lower). > > >The default user is set to a value of 1514. Eventhough only 1500 is set > >and used, the default user setup is still set to 1514. There is a > >open issue where we have requested this value to be set at 1500. > > >If the radius server sends a MTU then the default user MTU is not > >applied. Meaning - the default user is a template so when a user is > >authenticated via radius - all values that are sent by radius are applied > >to the user and other values that are not sent by the radius are taken > >from the default user. So if you do not send a MTU then the default user > >MTU is used. > > Right, I understand that...and I have a lot of users getting MTU's of > 1514. Also, since the MTU is negotiated in LCP, before the RADIUS > response is received in PAP, how is that handled? Does it go ahead and > use the value set on the default user. I'm pretty sure it doesn't > restart LCP. Does it set its own MTU down without restarting LCP? That > would be in spec if the MTU was lowered from what was negotiated in LCP. > > Other questions...how does it behave if the default user has an MTU set > of 576 (a common value), and isn't overridden in RADIUS? What happens > when a 1500 byte packet comes at it? drop it? send it anyway? > > The reason I'm asking and trying to get a good answer here is that from > what you're saying, it sounds like the implementation is broken. > > >I have never tried sending a MTU value greater than 1500 > >from radius. I am not sure what will happen if this is done. Need to > >get back to you on this issue. > > I'm *more* concerned about MTU's smaller than 1500. I would also be > concerned if an MTU bigger than what was negotiated in LCP was received > and used during PAP...that would be broken as well...but I doubt that's > happening. >

Thus spake Mark R. Lindsey >: The ISDN GW is the card(s) that the PRI card hands off ISDN calls to in >: order to handle the ISDN data signaling. The NETServer can do this >: because of the Munich daughter card, you're better off letting the quads >: handle it though (indicate this by setting the gw to 0) >Aha. The console interface won't let you configure this to 0, so I >set it to `None'. OK...that should work too. I do it through SNMP/TCM. >Should the DS0 status (Main Menu -> 2 -> 6 or 8) show modem cards >together with slots? Uhm...don't think so...(dredging out of memory here). DS0 status is in reference to the b channels on the PRI, not having anything to do with the modems. >This may be related: When I try to change the slot devices from Qbch-I_mdm >to Qbch-Mdm, I get a bunch of errors. That's proly cause you don't want to do that. If you have any halfway recent code on the quads, you have qbch-i-mdm's. Basically, that indicates quad, b channel, I-modems. I think that designation showed up in version...uhm...5.7/5.8 of the quads? Basically means that they can handle ISDN or analog calls...executive summary, leave it at i-mdm. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Dan Hollis >On Sat, 13 Mar 1999, Jeff Mcadams wrote: >> Boy is *that* an oversimplification of the situation. Care to expound >> on *why* this occurs? Are we talking about broken path mtu discovery >> here or what? if so, where is it broken? if not, what else is causing >> this? >WebTV's proxy servers have broken path mtu (theyre running an old version >of solaris and refuse to upgrade it) so if you lower the mtu then WebTV >users break. Well, that's assuming you even *CAN* lower the MTU. FWIW...I did some experimenting this afternoon. Only place I found to set the MTU on the Arc is: set network user default Mtu <x> Apparently, 3Com, in their infinite wisdom, decided not to even look at the default user settings until the RADIUS Access-Accept packet is received. What does this mean? Well, if you're using PPP based authentication (like PAP, CHAP, whatever) it means you can't set the MTU for your PPP links on your Arc *at all*. Since the default user values aren't looked at until the RADIUS Access-Accept packet is received, the MTU and MRU have already been set during LCP, and the Arc refuses to revisit that subject in any way...even if it doesn't require restarting LCP. So, the *only* way I've found to set the MTU, and this won't work for us, is to use a text based login, so the Access-Accept is returned before PPP is even started up so the value can be used (either from the default user, or from the RADIUS server) during LCP initially. Come on 3Com, this stuff isn't exactly rocket science here. How about using a little bit of thought in how you do things? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I use a different radius authentication and accounting package, Steel Belted Radius v2.1 for NT and have been using its concurrent logon tracking for a while now without too many problems. Most users are flawlessly removed from the list no problem. I've never seen a problem with the HARCs in the same office and same lan as the authentication box but have noticed an occasional missed STOP from a remote POP. The number of dropped STOPs don't seem to differ from NETServer to HARC (there's one of each at the remote POP). I'm actually surprised it works as well as it does given that the remote POP is roughly 14 router hops away (another wretched story altogether). I did evaluate the 3Com S&A server and it left a bad taste in my mouth so I continued on with Steel Belted. It can apparently use an ODBC database for authentication and accounting but I haven't attempted that yet. Service has been exceptional so far. Any questions I've sent to them via email have been answered quite competently within 24 hours - usually if I send them email in the morning I will have an answer in the afternoon. They have also partnered with other developers who make billing packages in order to insure compatibility in that area. No, I don't sell the stuff, I just really like the product. :-) -----Original Message----- Sent: 3/12/99 6:51 PM As long as you don't run it as a service you won't be faced with the cpu problem. I put it in the startup group and it works fine. Concurrency checking, that's another issue/problem. I honestly believe it's i the HiPerArc because they had it fixed once but since the accounting record changes that were added around the 4.1 code, it's never worked since. As was mentioned, it will miss stop records and then folks will try to reauthenticate and poof, it thinks they are logged in. Makes for some nasty tech support phone calls. It's #1 on my wish list for them to fix (aside from being able to port the backend to an SQL type of server). Jeff Binkley ASA Network Computing u>I would also recommend staying away. Use Emerald or Cistron or u>something else. 3Com claims the 100% cpu thing is a MS bug u>(surprised?) and i somewhat believe them because the machine we ran it u>on did not behave like it was stressed. also i you look at the you u>look at the password in the access database will notice the u>"encryption" is nothing more than a constant added to the ASCII value u>of the character in the password. i may be totally ignorant on this u>type of encryption but it looks like you only need your Cap'n Crunch u>decoder ring, the access file, half a brain and your in! when we u>realized this we turned white with fear. IOW stay away from 3com's SA u>server. we went with emerald a while ago and although there is a bit u>of a learning curve it was well worth it. contact me privately if you u>want more reasons to stay away. u>blake u> u>> -----Original Message----- u>> From: Tony Loosle [mailto:tony@tcsourceone.com] u>> Sent: Friday, March 12, 1999 12:01 PM u>> To: usr-tc@lists.xmission.com u>> Subject: Re: (usr-tc) V5.0 Security and Accounting Radius Server u>> Software u>> stay away from it at ALL costs. stay far away!! u>> they acutally have a version 6.??, but it's full of bugs, u>> use's access, run's your cpu to 100% all the time. You can't u>> use port restrictions in every other version, it forgets who u>> is logged in, then won't log them out and won't let them back in. u>> There is of couse NO support whatsoever from USR! u>> tony u>> Marlo Montanaro wrote: u>> > Does anyone know where I can find detailed information on u>> 3COM V5.0 Security and Accounting Radius Server Software for u>> Windows NT? u>> > u>> > I've searched the 3COM website and can't seem to locate u>> anything other than the basic "this is what it is" product u>> info. I would like to find part numbers, detailed specs, u>> pricing info, etc. and there are no links to more detailed u>> information. u>> > u>> > Also, I would like comments from anyone using this u>> software- how easy is it to install and configure, etc.? u>> > u>> > Thanks! u>> > Regards... u>> > Marlo Montanaro u>> > - u>> > To unsubscribe to usr-tc, send an email to u>> > "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of u>> > the message. For information on digests or retrieving files and u>> old messages send u>> > "help" to the same address. Do not use quotes in your message. u>> - u>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u>> with "unsubscribe usr-tc" in the body of the message. u>> For information on digests or retrieving files and old messages u>> send "help" to the same address. Do not use quotes in your u>> message. u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. 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.

> Thus spake Dan Hollis > >On Sat, 13 Mar 1999, Jeff Mcadams wrote: > >> Boy is *that* an oversimplification of the situation. Care to expound > >> on *why* this occurs? Are we talking about broken path mtu discovery > >> here or what? if so, where is it broken? if not, what else is causing > >> this? > > >WebTV's proxy servers have broken path mtu (theyre running an old version > >of solaris and refuse to upgrade it) so if you lower the mtu then WebTV > >users break. > > Well, that's assuming you even *CAN* lower the MTU. > > FWIW...I did some experimenting this afternoon. > > Only place I found to set the MTU on the Arc is: > set network user default Mtu <x> > > Apparently, 3Com, in their infinite wisdom, decided not to even look at > the default user settings until the RADIUS Access-Accept packet is > received. The default user is a template - if the options are not sent by radius then this template is applied. > > What does this mean? Well, if you're using PPP based authentication > (like PAP, CHAP, whatever) it means you can't set the MTU for your PPP > links on your Arc *at all*. Since the default user values aren't looked > at until the RADIUS Access-Accept packet is received, the MTU and MRU > have already been set during LCP, and the Arc refuses to revisit that > subject in any way...even if it doesn't require restarting LCP. > > So, the *only* way I've found to set the MTU, and this won't work for > us, is to use a text based login, so the Access-Accept is returned > before PPP is even started up so the value can be used (either from the > default user, or from the RADIUS server) during LCP initially. > No you can change the default user setup or use radius - then again make sure that you have your clients also change their mru. krish > Come on 3Com, this stuff isn't exactly rocket science here. How about > using a little bit of thought in how you do things? > -- > 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. >

On Sat, 13 Mar 1999, Jeff Mcadams wrote: > Thus spake Tatai SV Krishnan > >On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote: > >> What version of the codes are you running on the ARC, DSP's and Quads? > >> > >> Also can anyone else confirm that we're _not_ supposed to be shooting the > >> MTU value in radius? > >> > > >This has nothing to do with HiPer arc code or DSP or Quad code. For all > >HiPer arcs you either set the MTU to 1500 or do not set any value. > >Setting the MTU to a lower value other than 1500 will cause users unable > >to browse certain websites. > > Boy is *that* an oversimplification of the situation. Care to expound > on *why* this occurs? Are we talking about broken path mtu discovery > here or what? if so, where is it broken? if not, what else is causing > this? Broken MTU path discovery. Lots of people are now starting to block *ALL* ICMP at their routers, because of security paranoia. MTU Path Discovery needs ICMP of course... so, if your MTU is less than 1500, you lose if you try to browse a web site behind such a paranoid router. This isn't a 3com problem at all. This is a much-too-paranoid network admin problem. I had this happen at home, using a combo of Ascend and Cisco stuff (no 3com hardware anywhere) that cut the MTU down to 1460 for a while (because we were tunneling IP in IP for a while). You'd be surprised how many major web sites block all ICMP... Altavista was one... maybe still is. Sun was another. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

Thus spake Tatai SV Krishnan >> Only place I found to set the MTU on the Arc is: >> set network user default Mtu <x> >No you can change the default user setup or use radius - then again make >sure that you have your clients also change their mru. Well, all I know is that I did the set network user default mtu 576, save all, mon ppp, and monitored the next ppp session that started up (we don't do any text based logins at all), and the very first conf req that went out had an MRU value of 1514. I could find no way to effectively change the MTU/MRU values of the link from the Arc side. If the default user value is supposed to be used for this, then something is broken and a bug report needs to be filed, if this value isn't supposed to be used for this, then I guess a rfe should be filed asking for an effective way to do this. BTW, I'm using 4.1.59-2. Also, changing the MTU/MRU value on the client side should *not* be necessary. Changing it on the client side avoids a conf-nak theoretically, but that's about it wins you, and that's assuming there aren't other values that have to be 'naked anyway. That's the nice thing about PPP negotiation. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Tatai SV Krishnan >On Sat, 13 Mar 1999, Jeff Mcadams wrote: >> I'm *more* concerned about MTU's smaller than 1500. I would also be >> concerned if an MTU bigger than what was negotiated in LCP was received >> and used during PAP...that would be broken as well...but I doubt that's >> happening. >Well you first have to make sure that your client is happy with this. Well, that's what PPP negotiation is for. :) >The client PC should understand this MRU also - You have to go and change >the setup on win95/98 in the registry for proper functioning. Win95/98 brokeness is another thread entirely, and potentially quite a long one, but that's irrelevant to what we're talking about here. >If you are >doing PAP or CHAP - No clear text login then there are quite a few LCP >options that are negotiated. I agree...another is MRRU if using MP, which is just as significant really. >The lcp options chage the framing level >details and also imply changes in authentication methods etc. Yeah, I'm aware of that. I've never seen PAP have trouble fitting into the MRU, though, so that's really not significant to this particular issue. >The option 1 in lcp is your mru- which would be your mtu on the other >side. Not necessarily. Your MTU does not *have* to be the same as the remote's MRU, or even MRRU. Meaning, if the MTU value received during PAP is smaller than that negotiated during LCP, it could still be used without any other changes being made. >MRU negotiated should be atleast as large as the largest >negotiation message or the user datagram sent. If MRU is small it may >need to be altered. To send a confiure nak for this option may seem >illogical unless the message itself is corrupted. If the message is corrupted because the peer can't handle LCP packets up to at least 1500, then *they* are broken by the RFC, but that's not really relevant here. Again, I'm aware of the details of the PPP negotiation process and the implications of MRU/MTU settings, and the requirements that the RFC's (most significantly 1661 here, though 1990 plays in on MP links). >So make sure that your client understands this. This isn't an issue of a single client here. >As far as the value of >the default user itself is considered., yes you can change it - changing >it does apply this templte to the users who do ppp via chap/pap staring >lcp options - unless radius specifies the same. Ack...just went back to make sure I wasn't going crazy on looking at this...I was. *sheepish grin* I guess my excuse is that I'm not fully used to the Arc interface yet as I'm not sure what I was looking at earlier today, but the MTU (even gotten from RADIUS) was actually used on the link. Can I at least get away with complaining that this information isn't all available in the same place? I think earlier I only did show ppp on int slot:1/mod:10, which shows local and remote MRU's (and MRRU's), but the MTU isn't available there, only in show connection slot:1/mod:10. It would be nice to have all these values in one place. My apologies, and my previous messages were not all correct then. I haven't gone back and checked that the default user MTU settings are applied, but I would assume they would be, since the RADIUS value is used as well. >Also you will need all >the routers in any path to be able to send proper ICMP info to make sure >that the NAS/Client can change this value based on the path discovery. Yeah, broken pmtud is another question entirely and not one that I'm faulting 3Com for. >So the answer to your question is the default user is set at 1514 - you >can set it to 1500 or lower, but make sure the routers in all your path >support icmp and that no one blocks such icmp info - And also tell all >the clients to change their MRU. OK, that's really the answer I was *hoping* for, and it seems to be on track with what the arcs are doing (pardon me for not taking answers received from tech support at face value, but I've been told wrong info from tech support, and not just 3Com's, too many times to do that). Again, my apologies for looking at the wrong values, but it really would be nice if all of that information was available in the same location rather than having to look at 8 different screens (an exaggeration, but not much). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Sat, 13 Mar 1999, MegaZone wrote: >Once upon a time Ricky Beam shaped the electrons to say... >>Seimens is the ones who payed for the development of VoIP in the TC. >>(Maybe I want to move to Chicago after all :-)) > >Not if what I heard from a number of people at ISPF is true, that there is >heavy downsizing in Chicago. Look back through the list... the Seimens VoIP stuff was done a year ago??? I'd love to get my hands on the low-level interface specs within the TC chassis itself. There are so many brilliant things that _could_ be done with that platform if someone would just write it. (well, write it *effeciently*) --Ricky

On Sat, 13 Mar 1999, Mike Andrews wrote: >On Sat, 13 Mar 1999, Jeff Mcadams wrote: >> Boy is *that* an oversimplification of the situation. Care to expound >> on *why* this occurs? Are we talking about broken path mtu discovery >> here or what? if so, where is it broken? if not, what else is causing >> this? > >Broken MTU path discovery. Lots of people are now starting to block *ALL* >ICMP at their routers, because of security paranoia. MTU Path Discovery >needs ICMP of course... so, if your MTU is less than 1500, you lose if >you try to browse a web site behind such a paranoid router. > >This isn't a 3com problem at all. This is a much-too-paranoid network >admin problem. I prefer to call it "fucking incompetant stupidity". Any IP security professional should have enough understanding of how TCP/IP works to know damn well why ICMP is part of TCP/IP and exactly what the f*** it's there to do. There are lots of "bugs" in TCP/IP -- some are expressly unfixed (the RFC says, "this is a bug. do not fix it."; ICMP ain't one of them. This kind of stupidity is one of the many stupidities behind me not working for Interpath any more. I've had this kind of discussion with people before upon blocking all ICMP into/out of their network -- I make them fully aware of how much they are about to break in doing this. Usually, the ICMP block is only a "fast fix" to an attack or something along those lines. (I once "talked" with a network technician -- who now works for Cisco, btw -- for several hours about why blocking all ICMP is A Very Bad Thing (tm)) I won't waste my time detailing how screwed up an FTP gets when all ICMP is block to/from it... >I had this happen at home, using a combo of Ascend and Cisco stuff (no >3com hardware anywhere) that cut the MTU down to 1460 for a while (because >we were tunneling IP in IP for a while). You'd be surprised how many >major web sites block all ICMP... Altavista was one... maybe still is. >Sun was another. Actually, I'm not... I'd guess the problem with Sun was problems wrt PMTU. --Ricky

While perusing the documents on the Totalservice website, I noticed a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be newer than the 1.2.59 I am currently using. Is 1.2.46 a good release? I looked all over the place for it, but couldn't find it... anybody know where it is? ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

On Sun, 14 Mar 1999, Stephen Amadei wrote: > > While perusing the documents on the Totalservice website, I noticed > a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be > newer than the 1.2.59 I am currently using. Is 1.2.46 a good release? > I looked all over the place for it, but couldn't find it... anybody know > where it is? 1.2.46 is a Engineering Release code. This code is not a general/service release code. To get this code you would have to call support, and if this code would resolve your problem - you can get the same. regards krish > > ----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. >

Is this the new code that will allow us to get the session stats from the console too? Or is that still in the future. Thanks, Steve On Sun, 14 Mar 1999, Jamie Orzechowski wrote: > does 1.2.46 resolve Windows 3.1 users (trumpet winsock 2.0) ... or Acer Open > peoople? or Rockwell v.90 people?? if so I would like a copy of the code so > I can try it ... > > We have a terrible problem with Acer Open and rockwell v.90's ... AcerOpen's > will not even connect and everyone knows about the rockwell's ... I send > these users to quad modems and they have no problems ... > > -----Original Message----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Stephen Amadei <amadei@dandy.net> > Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Sunday, March 14, 1999 10:21 AM > Subject: Re: (usr-tc) DSP 1.2.46? > > > >On Sun, 14 Mar 1999, Stephen Amadei wrote: > > > >> > >> While perusing the documents on the Totalservice website, I noticed > >> a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be > >> newer than the 1.2.59 I am currently using. Is 1.2.46 a good release? > >> I looked all over the place for it, but couldn't find it... anybody know > >> where it is? > > > >1.2.46 is a Engineering Release code. This code is not a general/service > >release code. To get this code you would have to call support, and if > >this code would resolve your problem - you can get the same. > > > >regards > > > >krish > > > >> > >> ----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. > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

does 1.2.46 resolve Windows 3.1 users (trumpet winsock 2.0) ... or Acer Open peoople? or Rockwell v.90 people?? if so I would like a copy of the code so I can try it ... We have a terrible problem with Acer Open and rockwell v.90's ... AcerOpen's will not even connect and everyone knows about the rockwell's ... I send these users to quad modems and they have no problems ... -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >On Sun, 14 Mar 1999, Stephen Amadei wrote: > >> >> While perusing the documents on the Totalservice website, I noticed >> a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be >> newer than the 1.2.59 I am currently using. Is 1.2.46 a good release? >> I looked all over the place for it, but couldn't find it... anybody know >> where it is? > >1.2.46 is a Engineering Release code. This code is not a general/service >release code. To get this code you would have to call support, and if >this code would resolve your problem - you can get the same. > >regards > >krish > >> >> ----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. >> > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

On Sun, 14 Mar 1999, Jamie Orzechowski wrote: > does 1.2.46 resolve Windows 3.1 users (trumpet winsock 2.0) ... or Acer Open > peoople? or Rockwell v.90 people?? if so I would like a copy of the code so > I can try it ... 1.2.46 does resolve some isses, I am not sure on any fixes to Rockwell in particular - This code has some fixes to v.8 problems. There are ER that were released after 1.2.46 also. Again if you open a ticket and have support look at it - they sure could give you this code. regards krish > > We have a terrible problem with Acer Open and rockwell v.90's ... AcerOpen's > will not even connect and everyone knows about the rockwell's ... I send > these users to quad modems and they have no problems ... > > -----Original Message----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Stephen Amadei <amadei@dandy.net> > Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Sunday, March 14, 1999 10:21 AM > Subject: Re: (usr-tc) DSP 1.2.46? > > > >On Sun, 14 Mar 1999, Stephen Amadei wrote: > > > >> > >> While perusing the documents on the Totalservice website, I noticed > >> a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be > >> newer than the 1.2.59 I am currently using. Is 1.2.46 a good release? > >> I looked all over the place for it, but couldn't find it... anybody know > >> where it is? > > > >1.2.46 is a Engineering Release code. This code is not a general/service > >release code. To get this code you would have to call support, and if > >this code would resolve your problem - you can get the same. > > > >regards > > > >krish > > > >> > >> ----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. > >> > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

CC:'ing this back to the list since hopefully there will be some educational content here. Thus spake Tatai SV Krishnan >On Sun, 14 Mar 1999, Jeff Mcadams wrote: >> I agree...another is MRRU if using MP, which is just as significant really. >MRRU - rather MP adds more to it. For example some SGI implementatioins >if MP will set the MRU on their side to 1505 and if no MP it will set it >or 1500. This implementation changes from one OS to the other. Certainly, it adds EDO and such to the negotiation as well (RFC1990), but MRRU is the only one added that really has an impact on what was being discussed (MTU/MRU/MRRU) >> Not necessarily. Your MTU does not *have* to be the same as the >> remote's MRU, or even MRRU. Meaning, if the MTU value received during >> PAP is smaller than that negotiated during LCP, it could still be used >> without any other changes being made. >This is where I have to disagree, if you look at the PPP rfc only MRU is >defined. And based on MRU the other side NAS/Client set up the MTU. I >may be wrong here but after going through the RFC this is what I >understand. I have not looked into our code yet to fingure out what we >do, but I am sure this is what we setup to. The NAS MTU is actually the >MRU for the client. Again I may be wrong. Indeed, the RFC (1661) only discusses MRU, there's no mention of MTU at all. There is however a comment in there regarding receiving an MRU that's higher that the local system needs. (let me paste the comment in here) This option is used to indicate an implementation capability. The peer is not required to maximize the use of the capacity. For example, when a MRU is indicated which is 2048 octets, the peer is not required to send any packet with 2048 octets. The peer need not Configure-Nak to indicate that it will only send smaller packets, since the implementation will always require support for at least 1500 octets. While this doesn't explicitly mention MTU, it certainly seems to indicate (and common interpretation I believe supports this) that one peers MTU can be set lower than the remote peers MRU, without the remote peer needing to be notified. >> >So make sure that your client understands this. >> This isn't an issue of a single client here. >Well it is - because the MTU on our side should be equal to the MRU on >the client side. I was bringing this up as a discussion of the overall behavior of the HiPer Arc, we don't have any specific issue with any specific clients. Ideally (and this is what I found last night with further experimentation that this *is* working), I want to be able to set the MTU on our side and have that value be used. Indeed it is, even coming from RADIUS, apparently the HiPer Arc does unilaterally lower its MTU, as IMO, it should. So consider this a message with kudos in it for 3Com getting something right. :) I have *not* played with setting MTU higher in RADIUS than what's negotiated in LCP, so I don't know how it behaves in that instance, but I suspect that will happen very rarely, so its probably not as big of a problem. >> Can I at least get away with complaining that this information isn't all >> available in the same place? I think earlier I only did show ppp on int >> slot:1/mod:10, which shows local and remote MRU's (and MRRU's), but the >> MTU isn't available there, only in show connection slot:1/mod:10. It >> would be nice to have all these values in one place. >Sure - Thats no problem at all. I have been complaing about this for >atleast a year. I have even asked our guys to help me out to give me the >snmp values of the cli commands in a list so that we can write a small >app to get these for those people like me. I may go in and do just that. I've done some snmpwalks of what SNMP info is available from the HiPer Arc, so I'm vaguely familiar with what's there. Unfortunately, I *suck* at programming, so it will be some time before I would be able to have a tool available in any decent shape for distribution to anyone else. If anyone else that is halfway decent at programming would like to help out, I'll work out the pseudo-code of what needs to be done (and even include output examples from the Arc of what would need to be parsed or whatever), so all that would really need to be done is take that, and write a perl script or whatever that actually does in and implements my pseudo-code. :) I should be able to have the pseudo-code done (in between other stuff I'm working on) by the end of the week. If anyone wants to take a shot at converting my pseudo-code into working code, let me know (of if anyone else has done this already let me know so I don't have to reinvent the wheel :). Also, any specific requests for info that should be included (certainly MTU, MRU, and MRRU will be included since that's the crux of this whole discussion) is welcome. >> Yeah, broken pmtud is another question entirely and not one that I'm >> faulting 3Com for. >pmtud is not completely broken It does work but not in all networks. Indeed, the HiPer Arc handles the ICMP correctly...its just stupid network operators that filter out fragmentation needed messages that break it. Plenty of discussion of this has already occured. Again, that's not 3Com's fault. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Sun, 14 Mar 1999, Ricky Beam wrote: > I prefer to call it "fucking incompetant stupidity". Any IP security > professional should have enough understanding of how TCP/IP works to know damn > well why ICMP is part of TCP/IP and exactly what the f*** it's there to do. > There are lots of "bugs" in TCP/IP -- some are expressly unfixed (the RFC > says, "this is a bug. do not fix it."; ICMP ain't one of them. Yessir. The problem is laziness, there are so many sub-types, and people just don't know which to block. I found this post on the ipfilter mailing list, and it has a nice list of what does what in the world of icmp. This should apply to other fw products as well. Check out http://world.inch.com/info/icmp.html Charles

I have a lot of chassis that I upgraded from Netserver to HiperARC so they have 12 quad modems in them. I am wondering if I replaced one of the quad modems in a chassis with a DSP if I would run into problems due to there being 46 channels coming into the T1/PRI controller card and there being less than 46 quad modems for it to map to? Would the T1/PRI controller card 'busy' those channels out in some way so that telco skipped them and placed the calls on the next span? I'm aware of the quad modem prom going on, but I'm thinking long term if I will be able to replace the quads one at a time of it they have to go 6 at a time. -Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700

I currently have 7 chassis in one of my POPs and I am only running 1 MPIP server. (All HiperARC running 4.1.59 -6 and 1.2.59) This makes it difficult to do a code upgrade on the box without multilink connections (over multiple chassis) breaking for the duration of the upgrade so I am considering setting up a second MPIP server. I am correct that if I setup a second chassis as a server with all 7 clients authorized and I add a second MPIP server entry to all chassis with the priority one notch lower that the 1st MPIP server configured will be used by default but if that chassis goes down the clients will all work off of the secondary MPIP server? If the above occurs and the primary MPIP server comes back online will the bundles setup on the secondary still work? -Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700

Thus spake Mark Lemmert >I am wondering if I replaced one of the quad modems in a chassis >with a DSP if I would run into problems due to there being 46 channels >coming into the T1/PRI controller card and there being less than 46 quad >modems for it to map to? Would the T1/PRI controller card 'busy' those >channels out in some way so that telco skipped them and placed the calls >on the next span? It won't auto-busy the channels out, but if you put at least two of the channels on the PRI's in localoutofservice, that will do what you need. Be sure to save the pri card to nvram so if it gets rebooted, it remembers to put those two or more channels localoutofservice. Oh, yeah, and this won't work for NI-2 translation since the people that designed that were brain-dead and didn't include any method, like service messages, for one side to inform the other to not send calls down specific channels. >I'm aware of the quad modem prom going on, but I'm thinking long term >if I will be able to replace the quads one at a time of it they have to >go 6 at a time. Well, if you pop a DSP in the chassis and move a PRI from the dual-pri card over to it rather than putting a new PRI on it, then you wouldn't have to worry about busying out channels. At that point, you could take out 6 of your quad cards and have 5 free slots for further DSP's before you had to remove any more quads. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Mark Lemmert >I am correct that if I setup a second chassis as a server >with all 7 clients authorized and I add a second MPIP server >entry to all chassis with the priority one notch lower that >the 1st MPIP server configured will be used by default but >if that chassis goes down the clients will all work off of >the secondary MPIP server? Yes. >If the above occurs and the primary MPIP server comes back >online will the bundles setup on the secondary still work? Yes, if you have multiple MPIP servers and they have each other set up as MPIP servers in their own setups, then they will synchronize thier information with each other. This is a mixed blessing for those of us still dealing with the phantom MPIP bundle issue since with multiple MPIP servers, you can't just reboot the server and clear out the phantom bundles, you would have to reboot both at once. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I had been seeing the 'network stall' problem with webramp customers where after 10-15 minutes no traffic would go across the link. I put on the 4.1.59 -6 code and it fixed it, thanks Kirsh! That problem was fixed but a new one arose in it's place. Now when the webramp connects the network portions seems to stay intact, however after a short period of time I will loose communication on everything but ICMP. I.e. no traffic will move across the link on port 80, 25 etc, but pings go across just fine (the pings weren't working before I put the 4.1.59 -6 code on). It occured to me that this might be a more webramp based problem however I can have the webramp connect to a Livingston PM2 /w a BRI card and this problem does not occur. Has anybody else seen this? -Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700

--0__=HZcjclJuYi4kNQ6IxlGhIr4R58tE66WJMTbbr2aHn6uMub4uWtOeSEIJ Content-type: text/plain; charset=us-ascii Content-Disposition: inline Mike, Call us at 888-373-7367 and we'll see if we can help you with this problem. "Mike Hamrich" <mhamrich@drfast.net> on 03/09/99 08:37:12 PM Please respond to usr-tc@lists.xmission.com cc: (Christina Raeber/MW/US/3Com) disconnects. Hi all, We just upgraded from Netserver based code relase 2.5.1 to HyperArc release 3.3.3 And now we are getting tons of disconnects. Within 30 seconds or less of logging on. 90% of the quickly disconnected users show V42Disconect(42) command while 10% show GatewayDisconnect(62) Mostly USR modems Sportsters a few Courier and few Sportster Winmodems. ISDN clients work great. We have the latest code on the Quads, they were running 5.1.7 now 5.10.9 ,NMC is 5.5.5 with the inculded mem upgrade. and the HyperArc is the latest 4.1.59 -6, though on chassiy inventory the -6 is missing. Before we upgraded we put the PRI's out of service, onhooked offhooked the modem's and set all the Quads to "default" then saved to NVRAM and rebooted. Any Ideas? --0__=HZcjclJuYi4kNQ6IxlGhIr4R58tE66WJMTbbr2aHn6uMub4uWtOeSEIJ Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PXRleHQvaHRtbDtjaGFyc2V0PWlzby04ODU5LTEgaHR0 cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSciTVNIVE1MIDQuNzIuMjEwNi42 IicgbmFtZT1HRU5FUkFUT1I+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElW PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPkhpIGFsbCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG T05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPldlIGp1c3QgdXBncmFkZWQgZnJvbSBOZXRzZXJ2ZXIgYmFzZWQgY29kZSByZWxhc2Ug Mi41LjEgdG8gDQpIeXBlckFyYyByZWxlYXNlIDMuMy4zIEFuZCBub3cgd2UgYXJlIGdldHRpbmcg dG9ucyBvZiBkaXNjb25uZWN0cy4gV2l0aGluIDMwIA0Kc2Vjb25kcyBvciBsZXNzIG9mIGxvZ2dp bmcgb24uIDkwJSBvZiB0aGUgcXVpY2tseSBkaXNjb25uZWN0ZWQmbmJzcDsgdXNlcnMgc2hvdyAN ClY0MkRpc2NvbmVjdCg0MikgY29tbWFuZCB3aGlsZSAxMCUgc2hvdyBHYXRld2F5RGlzY29ubmVj dCg2MikgTW9zdGx5IFVTUiBtb2RlbXMgDQpTcG9ydHN0ZXJzIGEgZmV3IENvdXJpZXIgYW5kIGZl dyBTcG9ydHN0ZXIgV2lubW9kZW1zLiBJU0ROIGNsaWVudHMgd29yayANCmdyZWF0LjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg c2l6ZT0yPldlIGhhdmUgdGhlIGxhdGVzdCBjb2RlIG9uIHRoZSBRdWFkcywgdGhleSB3ZXJlIHJ1 bm5pbmcgNS4xLjcgDQpub3cgNS4xMC45ICxOTUMgaXMgNS41LjUgd2l0aCB0aGUgaW5jdWxkZWQg bWVtIHVwZ3JhZGUuIGFuZCB0aGUgSHlwZXJBcmMgaXMgdGhlIA0KbGF0ZXN0IDQuMS41OSAtNiwg dGhvdWdoIG9uIGNoYXNzaXkgaW52ZW50b3J5IHRoZSAtNiBpcyBtaXNzaW5nLjwvRk9OVD48L0RJ Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPkJl Zm9yZSB3ZSB1cGdyYWRlZCB3ZSBwdXQgdGhlIFBSSSdzIG91dCBvZiANCnNlcnZpY2UsIG9uaG9v a2VkIG9mZmhvb2tlZCB0aGUgbW9kZW0ncyBhbmQgc2V0IGFsbCB0aGUgUXVhZHMgdG8gDQomcXVv dDtkZWZhdWx0JnF1b3Q7IHRoZW4gc2F2ZWQgdG8gTlZSQU0gYW5kIHJlYm9vdGVkLiBBbnkgSWRl YXM/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+ Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo= --0__=HZcjclJuYi4kNQ6IxlGhIr4R58tE66WJMTbbr2aHn6uMub4uWtOeSEIJ--

As has been noted here before, the USR Radius server scarcely works. I've been looking at alternatives - in particular Cistron, Merit, and Radiator - and am looking for advice. What's the best bet in terms of cost, performance, reliability, ease of maintenance, etc.? Thanks, Chris Hanes

I have an annoying problem that doesn't seem to be related to my equipment, but I hope someone on the list will be able to shed some light. When I do anything to my TC boxes that requires me to take down a T1, the telco switch takes some of my trunks out of service. I have to call USWest to get them to "release" the trunks again. I can find no rhyme or reason as to which lines get taken out of service. Sometimes it's just one trunk, sometimes a few, sometimes most of a span. A few questions: 1. Is there a way I can "tell" the switch (Lucent 5ESS) to restore the lines through the HDM or T1 card? 2. Is there a way USWest can set up the switch to automatically "poll" our equipment on a regular basis after an outage and auto-restore if it's there? 3. Can anyone give me any background information on the switches to explain why it might be taking trunks out of service? No one I've talked to at USWest knows of a way to do #2. I'm sure there are people on this list with more switch knowledge than most of the testers have. In case this does happen to be equipment related, I am running the latest HiperDSP, T1 and Quad releases/ER's, with HiperARCs. Thanks, Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com

Charles Sprickman said once upon a time: >Does this mean anything? Looking at this about 10% of calls fall into >this class... No, it is noise from the ARC. >Ideas? What exactly classifies as an "unauthenticated call"? Plug this into your configuration: set accounting log_UNAUTHENTICATED_CALLS false

All of a sudden we're getting many immediate disconnect requests. The only odd thing I noticed was that my logfile has alot (??) of "unauthenticated" requests. Does this mean anything? Looking at this about 10% of calls fall into this class... root@util[/usr/local/etc/radius/db-analog]# cat logfile | wc -l 18623 root@util[/usr/local/etc/radius/db-analog]# grep unauth logfile | wc -l 1824 If I go back a few days, there's alot less: root@util[/usr/local/etc/radius/db-analog]# zcat logfile.990311.gz | wc -l 34528 root@util[/usr/local/etc/radius/db-analog]# zgrep unauth logfile.990311.gz | wc -l 1620 Ideas? What exactly classifies as an "unauthenticated call"? Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

http://www.cableone.net/ebilleter/hiperdsp.pl or the scripts are included in the contrib directory with mrtg now. Thanks Eric T. Billeter Cable One Internet Engineer 1314 North 3rd Street ebilleter@cableone.net Phoenix, AZ 85004 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Robert J. Adams Sent: Monday, March 15, 1999 3:12 PM Hello, A while back someone posted a URL to perl scripts (used with MRTG) to chart the number of users on.. anyone have that URL handy? -Jason --- Robert J. Adams radams@siscom.net http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 937-222-8150 FAX: 937-222-8153 - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Mon, 15 Mar 1999, Chris Hanes wrote: >As has been noted here before, the USR Radius server scarcely works. >I've been looking at alternatives - in particular Cistron, Merit, and >Radiator - and am looking for advice. What's the best bet in terms of >cost, performance, reliability, ease of maintenance, etc.? Yes, people have noted that before. The USR radius server, as it comes from USR, is a very poor excuse for a RADIUS server. HOWEVER, if you spend some time working on replacing the script, the core server part of the system is very powerful. I look at it like buying "perl" and getting some bad "example" code with it. Chris, et. al., drop me a note directly if you are interested in seeing what magic I've done to the script and database schema. It doesn't take 5k per user anymore; you can limit access for ISDN, MLPPP, X2/V.90, and analog/digital call enforcement as well as the usual DNIS/ANI/portgroup stuff. As for speed... using SA4.3.11 (143Mhz sparc 10 / solaris 2.5.1) + postgres v6.3.2 (dual PII-300 / linux), the system could handle over 30 authentication requests _per_ _second_. (Imagine what that would be if I were to use Oracle or even flat files.) (BTW, SA4 will compile and run perfectly under linux -- with one small change to the select() handling.) I will say this again: The script is designed for SA4. It can be dropped into SA5 with minor modifications. If will not work for SA6 with extensive changes. And, as hiper hardware didn't exist when I designed the script, there is no specific handling for hiper hardware. IF there is interest, I can finish work already in progress in updating the SA4 script for SA6 (with full hiper support.) If I still had access to the source code (and some access hardware), I could do some beautiful things to that server... faster client auth checks, true duplicate packet handling, full multithreaded processing... --Ricky

Charles, Logs for Unauthenticated calls means that Hiper Arc logs the calls which failed prior to authentication. You can disable this by set accounting log_unauthenticated_calls false. Regards Sanjay On Mon, 15 Mar 1999, Charles Sprickman wrote: > All of a sudden we're getting many immediate disconnect requests. The > only odd thing I noticed was that my logfile has alot (??) of > "unauthenticated" requests. > > Does this mean anything? Looking at this about 10% of calls fall into > this class... > > root@util[/usr/local/etc/radius/db-analog]# cat logfile | wc -l > 18623 > root@util[/usr/local/etc/radius/db-analog]# grep unauth logfile | wc -l > 1824 > > If I go back a few days, there's alot less: > > root@util[/usr/local/etc/radius/db-analog]# zcat logfile.990311.gz | wc -l > 34528 > root@util[/usr/local/etc/radius/db-analog]# zgrep unauth logfile.990311.gz > | wc -l 1620 > > Ideas? What exactly classifies as an "unauthenticated call"? > > 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. >

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown |Sent: Monday, March 15, 1999 3:54 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) "unauthenticated" users + drops | | |Charles Sprickman said once upon a time: | |>Does this mean anything? Looking at this about 10% of calls fall into |>this class... | |No, it is noise from the ARC. More of a din than a noise. It is usefull for some. |>Ideas? What exactly classifies as an "unauthenticated call"? | Any call that did not progress past authentication phase gets logged this way. Either call drop or incorrect passwords. -M

Recently I've been getting sporadic complaints of busy signals from customers during times when our modem usage is signaficantly lower than 100%. This is also not normally following a period in which most or all modems were in use. After talking in depth with some of these customers, the bsuies seem to be normally generated busy signals, not fast busies. I have PRIs coming into HiPer DSP 1.2.60, ARC 4.1.72, NMC 5.5.5. Is this a DSP/SRC issue, or possibly telco? Any suggestions/ideas appreciated. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Hello, A while back someone posted a URL to perl scripts (used with MRTG) to chart the number of users on.. anyone have that URL handy? -Jason --- Robert J. Adams radams@siscom.net http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 937-222-8150 FAX: 937-222-8153

On Sat, 13 Mar 1999, MegaZone wrote: > This is the current Cistron 3Com dictionary - I don't know of the OS/2 port > has the full 3Com VSA support, it was added fairly recently. Thanx, MegaZone. I'll give this a try. The Cistron I ported was current about two/three months ago... I think a minor version has been released since. If worse comes to worse, I'll just report and newest version again... it only took me a day or so to port it, and a week to catch one nasty bug. Works great now... after I ported last, sort and sac, too... Gotta love those EMX libraries... ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

On Mon, 15 Mar 1999, Robert J. Adams wrote: > Hello, > > A while back someone posted a URL to perl scripts (used with MRTG) to chart > the number of users on.. anyone have that URL handy? I don't have a URL handy, but I can share the script and cfg I use below. This was seriously hacked up from the Portmaster scripts, so you'll see a lot of references to 'portmaster'... just pretend they say 'total control'... ;-) The first file is tcmgather... the script which actually checks the TC's for users and writes the data files. You'll notice I have three physical boxes in this script... two are full 12 Quad systems... one is a Hiper chassis with 3 DSP cards in slots 13,14,15. The second file is the config file MRTG needs to run with. Basically it tells MRTG where the data files are and how you want the graphs to look. Have fun... ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ #!/bin/csh # tcmgather # run this script ever 5 minutes via cron with a crontab something like: # 1,6,11,16,21,26,31,36,41,46,51,56 * * * * /home/admin/pmgraph/bin/getstats # note that this script calls MRTG # set the names or IP's of your Portmasters set TC1="moo.nmc.xxx.net" set TC2="acy.nmc.xxx.net" set TC3="pvl.nmc.xxx.net" # set the SNMP read community of your Portmasters set TC1comm="public" set TC2comm="public" set TC3comm="public" # Grab a user count for each Portmaster via the snmpwalk command # You may need to use "snmpwalk -v 1" depending on your version of snmpwalk # You may also need to grep for something other than "23" set OID=".1.3.6.1.4.1.429.1.6.9.1.1.2" set MLID="429.1.6.9.1.1.2.13" set OCID1="429.1.6.9.1.1.2.15" set OCID2="429.1.6.9.1.1.2.14" set OCY1=`snmpwalk $TC1 $TC1comm $OID | grep ': 8' | grep $OCID1 | wc -l` set OCY2=`snmpwalk $TC1 $TC1comm $OID | grep ': 8' | grep $OCID2 | wc -l` set MIL=`snmpwalk $TC1 $TC1comm $OID | grep ': 8' | grep $MLID | wc -l` set ACY=`snmpwalk $TC2 $TC2comm $OID | grep ': 8' | wc -l` set PVL=`snmpwalk $TC3 $TC3comm $OID | grep ': 8' | wc -l` # Get a grand total of users online set TOTAL=`expr ${PVL} + ${OCY1} + ${OCY2} + ${MIL} + ${ACY}` set OCYT=`expr $OCY1 + $OCY2` # MRTG needs 4 lines of input to be happy, we're only interested in the 2nd # line and possibly the first so we fill the others with junk # write out the various logs # grand total of all your Portmasters echo $TOTAL > /var/lib/httpd/htdocs/dandynet/statistics/allports echo $TOTAL >> /var/lib/httpd/htdocs/dandynet/statistics/allports echo "ever" >> /var/lib/httpd/htdocs/dandynet/statistics/allports echo "everything" >> /var/lib/httpd/htdocs/dandynet/statistics/allports # Portmaster #1 echo $PVL > /var/lib/httpd/htdocs/dandynet/statistics/pville echo $PVL >> /var/lib/httpd/htdocs/dandynet/statistics/pville echo "time" >> /var/lib/httpd/htdocs/dandynet/statistics/pville echo "PVL" >> /var/lib/httpd/htdocs/dandynet/statistics/pville # Portmaster #2 echo $OCYT > /var/lib/httpd/htdocs/dandynet/statistics/ocy echo $OCYT >> /var/lib/httpd/htdocs/dandynet/statistics/ocy echo "time" >> /var/lib/httpd/htdocs/dandynet/statistics/ocy echo "OCY" >> /var/lib/httpd/htdocs/dandynet/statistics/ocy # Portmaster #3 echo $MIL > /var/lib/httpd/htdocs/dandynet/statistics/milmay echo $MIL >> /var/lib/httpd/htdocs/dandynet/statistics/milmay echo "time" >> /var/lib/httpd/htdocs/dandynet/statistics/milmay echo "MIL" >> /var/lib/httpd/htdocs/dandynet/statistics/milmay # Portmaster #4 echo $ACY > /var/lib/httpd/htdocs/dandynet/statistics/acy echo $ACY >> /var/lib/httpd/htdocs/dandynet/statistics/acy echo "time" >> /var/lib/httpd/htdocs/dandynet/statistics/acy echo "ACY" >> /var/lib/httpd/htdocs/dandynet/statistics/acy # and finally, run MRTG specifying our customized .cfg file eval `/usr/bin/mrtg/mrtg /usr/bin/mrtg/tcs.cfg` WorkDir: /var/lib/httpd/htdocs/dandynet/statistics Refresh: 600 Target[allports]: `cat /var/lib/httpd/htdocs/dandynet/statistics/allports` Title[allports]: Modem Traffic for Smart Online Solutions PageTop[allports]: <center><H1>Modem Traffic for Smart Online Solutions</H1></center> This page shows the total modem use at Smart Online Solutions. Our four dial-ups are USR TotalControl PRIs that each control 24 modems, of which 23 are usable at a time, giving us a grand total of 161 dial-in lines. We also graph each TotalControl out separately, See:<UL> <LI><FONT Size=+2></FONT><A HREF="./pville.html">TotalControl Pleasantville</A><BR> <LI><FONT Size=+2></FONT><A HREF="./ocy.html">TotalControl Ocean City</A><BR> <LI><FONT Size=+2></FONT><A HREF="./milmay.html">TotalControl Milmay</A> <LI><FONT Size=+2></FONT><A HREF="./acy.html">TotalControl Atlantic City</A> </UL> MaxBytes[allports]: 161 AbsMax[allports]: 161 Options[allports]: absolute, gauge Ylegend[allports]: Total lines in use RouterUptime[allports]: ShortLegend[allports]: Modems Online Unscaled[allports]: mwy LegendI[allports]: Total LegendO[allports]: Total Legend2[allports]: <FONT Size=+2></FONT>Total count of all modems online at <A HREF="http://www.dandy.net">Smart Online Solutions</A> Target[pville]: `cat /var/lib/httpd/htdocs/dandynet/statistics/pville` PageTop[pville]: <center><H1>Modem Traffic on TotalControl PRI Pleasantville</H1></center> MaxBytes[pville]: 46 AbsMax[pville]: 46 Options[pville]: absolute, gauge Title[pville]: Modem Traffic on TotalControl PRI Pleasantville Ylegend[pville]: Lines in use RouterUptime[pville]:them@pvl.nmc.dandy.net ShortLegend[pville]: Modems Online Unscaled[pville]: dmwy LegendI[pville]: Total LegendO[pville]: Total Legend2[pville]: Total count of modems used on TotalControl PRI Pleasantville Target[ocy]: `cat /var/lib/httpd/htdocs/dandynet/statistics/ocy` PageTop[ocy]: <center><H1>Modem Traffic on TotalControl PRI Ocean City</H1></center> MaxBytes[ocy]: 46 AbsMax[ocy]: 46 Options[ocy]: absolute, gauge Title[ocy]: Modem Traffic on TotalControl PRI Ocean City Ylegend[ocy]: Lines in use RouterUptime[ocy]:them@moo.nmc.dandy.net ShortLegend[ocy]: Modems Online Unscaled[ocy]: dmwy LegendI[ocy]: Total LegendO[ocy]: Total Legend2[ocy]: Total count of modems used on TotalControl PRI Ocean City Target[milmay]: `cat /var/lib/httpd/htdocs/dandynet/statistics/milmay` PageTop[milmay]: <center><H1>Modem Traffic on TotalControl PRI Milmay</H1></center> MaxBytes[milmay]: 23 AbsMax[milmay]: 23 Options[milmay]: absolute, gauge Title[milmay]: Modem Traffic on TotalControl PRI Milmay Ylegend[milmay]: Lines in use RouterUptime[milmay]:them@moo.nmc.dandy.net ShortLegend[milmay]: Modems Online Unscaled[milmay]: dmwy LegendI[milmay]: Total LegendO[milmay]: Total Legend2[milmay]: Total count of modems used on TotalControl PRI Milmay Target[acy]: `cat /var/lib/httpd/htdocs/dandynet/statistics/acy` PageTop[acy]: <center><H1>Modem Traffic on TotalControl PRI Atlantic City</H1></center> MaxBytes[acy]: 46 AbsMax[acy]: 46 Options[acy]: absolute, gauge Title[acy]: Modem Traffic on TotalControl PRI Atlantic City Ylegend[acy]: Lines in use RouterUptime[acy]: them@acy.nmc.dandy.net ShortLegend[acy]: Modems Online Unscaled[acy]: dmwy LegendI[acy]: Total LegendO[acy]: Total Legend2[acy]: Total count of modems used on TotalControl PRI Atlantic City

On Tue, 16 Mar 1999, Brett Murphy wrote: > Hi All, > Far too regularly I am finding that when I telnet to my HyperARC > it drops the connection immediately. The problem remains until I > powercycle the chassis. Has anyone seen this before? Need to know the version of code you are using - some version of 4.0 and some versions of 4.1 did have some memory problems. 4.1.59 -6 - the latest one in the web site http://totalservice.usr.com does fix a lot of issues. If you are seeing this problem with 4.1.59 -6 then we need more info - like syslogs krish > > -- > > All the best, > Brett Murphy > System Administrator, Alphalink (Australia) PTY LTD > ph: +61 3 9486-8844 fax: +61 3 9486-6822 > email: sysadmin@alphalink.com.au > > The contents of this message may not be quoted, > copied, reproduced or published in part or in whole, > without the written authorization of Brett Murphy, > Director, Alphalink (Australia) Pty Ltd. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

> > On Tue, 16 Mar 1999, Brett Murphy wrote: > > > Hi All, > > Far too regularly I am finding that when I telnet to my HyperARC > > it drops the connection immediately. The problem remains until I > > powercycle the chassis. Has anyone seen this before? > > > Need to know the version of code you are using - some version of 4.0 and > some versions of 4.1 did have some memory problems. 4.1.59 -6 - the > latest one in the web site http://totalservice.usr.com > does fix a lot of issues. > > If you are seeing this problem with 4.1.59 -6 then we need more info - > like syslogs > > krish I have seen it on 4.1.59-0 and 4.1.67-*. But only on hubs used for DIALOUT. When I get on the console I see out of memory errors. All I can do is reboot. Again, I only see this on a hub used for DIALOUT, never seen it on hiperarcs used for dialin. -- Douglas Rabe UUnet Technologies, Inc. darabe@ans.net

At 11:46 AM 3/16/99 +1100, Brett Murphy <sysadmin@alphalink.com.au> wrote: >We have had these problems occasionally, using E1 in Australia. >Definitely a Telco problem in our case. That's my first guess as well, but I need to; a) Be able to conclusively determine that it is, and b) Let them know what the problem is and what might need fixing. I'm dealing with Bell Atlantic here and the clue level is highly inconsistant at best. Thanks, Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

I seem to be having ALOT of PPP authentication problems! ... I am running that latest ARC code ... 4.1.59-6 .. anyone have any ideas how to fix this???? People will connect and get dropped right away. When I dial in with a term program I will dial and immediatly I will get a authentication failure text come up before I have even typed anything ... here is a cut & paste atdtXXX-XXXX CONNECT 115200 Welcome to 3Com Total Control HiPer ARC (TM) Networks That Go The Distance (TM) UserName: Authentication failure UserName: Sometimes PPP starts at the same prompt before I type anything ... here is a message an advanced linux user of our system has sent me. --start hi... it's me again. i've been doing some more playing around trying to figure out why the linux 2.2.x series won't allow me to connect. i booted into 2.0.36 yesterday, and i ran minicom (you know, the unix term app?) anyway... i found that after i dialed, the first prompt for authentication would automatically fail, even though i hadn't typed in anything yet... on other times (specifically if i got connected at 44000) it would start sending PPP garbage like ?~?~?~?~?~... etc... at the authentication prompt um... i have a GVC 56k X2 modem... and as far as i know it still uses the v.42 protocol. (upgrade to v.90 requires a chip replacement)... does that bring anything to mind as to why maybe i can't get connected? i think it at least shows why i've been getting the "unsupported protocol" errors from pppd.... thanks. --stop Have a Great Day! Jamie Orzechowski RipNET System Admin Tel.: 613-342-3946 ext 293 Tel.: 800-267-4434 ext 293 Page.: 613-341-0883 EMail.: mhz@ripnet.com Web.: http://www.ripnet.com Personal.: http://www.moonchilli.com

We deal with Ameritech here but have had the same problem. I'll try to answer your questions based upon my experience and their responses to the questions. Steve On Mon, 15 Mar 1999, Randy Cosby wrote: > > A few questions: > > 1. Is there a way I can "tell" the switch (Lucent 5ESS) to restore the lines > through the HDM or T1 card? Not with the Ameritech switch(I think Northern Telecom). > 2. Is there a way USWest can set up the switch to automatically "poll" our > equipment on a regular basis after an outage and auto-restore if it's there? Not with Ameritech, it's a real person that has to restore it to service. > 3. Can anyone give me any background information on the switches to explain > why it might be taking trunks out of service? > From what I understand, when we work on something that has to take a T1 out of service, an alarm will go on at Ameritech. After 1 hour with that alarm on, someone will switch it to out of service. We then have to call to get them turned back on, much like yourself. To get around it we have a small workaround that works for us. We have an incoming channelized DS3 so I go into the mux and Unequip the channels(T1's) that I'm going to be working on. The Equipped/Unequipped status doesn't actually turn the service on or off but rather turns off the alarm status(it doesn't send the alarm if it's unequipped). Again that's what worked for us, but it is a special situation. Steve

I've seen this occasionally when a trunk group has been down for quite a while. According to our telco guys it automatically takes the trunks out of service after a period of time. However, I think what the original poster was talking about seeing some ds0's in an "out of service" state after a chassis power cycle or a NAC reset. I've seen that lots too and sometimes putting the channels "local out of service" and then "in service" will bring them back up. Other times I have to get the telco to post the trunks from the switch. Other than that, I don't know.. -----Original Message----- Sent: 3/15/99 11:07 PM From what I understand, when we work on something that has to take a T1 out of service, an alarm will go on at Ameritech. After 1 hour with that alarm on, someone will switch it to out of service. We then have to call to get them turned back on, much like yourself. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

A couple of days ago, I was inquiring about the LED status on the USR's... I'd like to thank everyone who responded, and as I promised, I am sharing the fruits of my labor... Someone else has probably already done this, but since I couldn't find any code like it, I wrote my own... A "Total Control Virtual Display Program" What this does is create Gif files that represent your TC units. This is an early edition... I plan on prettying it up later, but it's mostly functional now, but I need to write a few other useless toys for my company. ;-) Some limitations: - It creates FOUR gif files for each of your Total Controls. This is in order to create an animated Gif file in the future, to provide for blinking LEDs. Disregard the extra GIFs. - It does not support the NetServer... I didn't have one handy when I built this... if someone gives me readonly access to a NetServer equipped TC, I will add it. - It does support the T1 card, Digital Quads, Analog Quads, D-A Quads, Hiper DSP, Hiper ARC, NMC and NMC with clock. For added cards, see note above about NetServer. - Requires CMU-SNMP, SNMPWALK, the GD library, GD perl library things and parts of MRTG. - It's absolutely not guarenteed to work anywhere... ;-) If you are feeling lucky, you can get the script at http://www.dandy.net/~amadei/tcview and see a live demo at http://www.dandy.net/statistics/tc.html Let me know what you think, and any suggestions. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

This is a multi-part message in MIME format. ------=_NextPart_000_0534_01BE6F79.72872CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do any of you fine list members know what the attribute codes 38978 & = 38979 refer to. I suspect they have something to do with the HIPER = cards, but can't find this info anywhere. TIA. Samuel S. Lowe Director, Data Network Services UniversalCom, Inc. slowe@universalcom.net ------=_NextPart_000_0534_01BE6F79.72872CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> <HTML><HEAD> <META content=3Dtext/html;charset=3Diso-8859-1 = http-equiv=3DContent-Type> <STYLE></STYLE> <META content=3D'"MSHTML 5.00.0910.1309"' name=3DGENERATOR></HEAD> <BODY bgColor=3D#ffffff> <DIV>&nbsp;</DIV> <DIV><FONT size=3D2>Do any of you fine list members know what the = attribute codes=20 38978 &amp; 38979 refer to.&nbsp; I suspect they have something to do = with the=20 HIPER cards, but can't find this info anywhere.</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2>TIA.</FONT></DIV> <DIV><FONT size=3D2></FONT>&nbsp;</DIV> <DIV><FONT size=3D2><BR>Samuel S. Lowe<BR>Director, Data Network=20 Services<BR>UniversalCom,=20 Inc.<BR>slowe@universalcom.net<BR><BR></FONT></DIV></BODY></HTML> ------=_NextPart_000_0534_01BE6F79.72872CE0--

On Mon, 15 Mar 1999, Douglas Rabe wrote: > I have seen it on 4.1.59-0 and 4.1.67-*. But only on hubs used for > DIALOUT. When I get on the console I see out of memory errors. All > I can do is reboot. Again, I only see this on a hub used for DIALOUT, > never seen it on hiperarcs used for dialin. 4.1.59 - 0 - Ans - You need to contact Bill or Mathew. Please refer to my other email krish > > -- > Douglas Rabe UUnet Technologies, Inc. darabe@ans.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. >

On Tue, 16 Mar 1999, Brett Murphy wrote: > How emarrasing! > I am using 4.1.11 > I'll install the latest one asap. Install the latest - that does have some good fixes. What I did say was that 4.1.x - certain version has some memory issues. So that does not means that every version of 4.1.x has problems. regards krish > > Tatai SV Krishnan wrote: > > > On Tue, 16 Mar 1999, Brett Murphy wrote: > > > > > Hi All, > > > Far too regularly I am finding that when I telnet to my HyperARC > > > it drops the connection immediately. The problem remains until I > > > powercycle the chassis. Has anyone seen this before? > > > > Need to know the version of code you are using - some version of 4.0 and > > some versions of 4.1 did have some memory problems. 4.1.59 -6 - the > > latest one in the web site http://totalservice.usr.com > > does fix a lot of issues. > > > > If you are seeing this problem with 4.1.59 -6 then we need more info - > > like syslogs > > > > krish > > > > > > > > -- > > > > > > All the best, > > > Brett Murphy > > > System Administrator, Alphalink (Australia) PTY LTD > > > ph: +61 3 9486-8844 fax: +61 3 9486-6822 > > > email: sysadmin@alphalink.com.au > > > > > > The contents of this message may not be quoted, > > > copied, reproduced or published in part or in whole, > > > without the written authorization of Brett Murphy, > > > Director, Alphalink (Australia) Pty Ltd. > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > -- > > All the best, > Brett Murphy > System Administrator, Alphalink (Australia) PTY LTD > ph: +61 3 9486-8844 fax: +61 3 9486-6822 > email: sysadmin@alphalink.com.au > > The contents of this message may not be quoted, > copied, reproduced or published in part or in whole, > without the written authorization of Brett Murphy, > Director, Alphalink (Australia) Pty Ltd. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Mon, 15 Mar 1999, Jamie Orzechowski wrote: > I seem to be having ALOT of PPP authentication problems! ... I am running > that latest ARC code ... 4.1.59-6 .. anyone have any ideas how to fix > this???? Do please refer to the release notes and make sure that ppp offloading is enabled disable ppp receive accm > > People will connect and get dropped right away. When I dial in with a term > program I will dial and immediatly I will get a authentication failure text > come up before I have even typed anything ... > > here is a cut & paste > > atdtXXX-XXXX > CONNECT 115200 > > Welcome to 3Com Total Control HiPer ARC (TM) > Networks That Go The Distance (TM) > UserName: Authentication failure > > UserName: > > This is something wrong here - I would suspect config. Either the client or the modem_group is configured wrong. you can do a tap on the port and find out what is happening. krish > > Sometimes PPP starts at the same prompt before I type anything ... > > here is a message an advanced linux user of our system has sent me. > > --start > > hi... it's me again. i've been doing some more playing around trying to > figure out why the linux 2.2.x series won't allow me to connect. i > booted into 2.0.36 yesterday, and i ran minicom (you know, the unix term > app?) anyway... i found that after i dialed, the first prompt for > authentication would automatically fail, even though i hadn't typed in > anything yet... on other times (specifically if i got connected at > 44000) it would start sending PPP garbage like ?~?~?~?~?~... etc... at > the authentication prompt um... i have a GVC 56k X2 modem... and as far > as i know it still uses the v.42 protocol. (upgrade to v.90 requires a > chip replacement)... does that bring anything to mind as to why maybe i > can't get connected? i think it at least shows why i've been getting the > "unsupported protocol" errors from pppd.... thanks. > > --stop > > > > --------------------------------------------------- > Have a Great Day! > > Jamie Orzechowski > RipNET System Admin > > Tel.: 613-342-3946 ext 293 > Tel.: 800-267-4434 ext 293 > Page.: 613-341-0883 > EMail.: mhz@ripnet.com > Web.: http://www.ripnet.com > Personal.: http://www.moonchilli.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. >

Is there a way to stop S&A manager from authenticating a user who adds @domain.com or @anything.com to their correct user name from being authenticated? Some users get confused and instead using just their user name they use their email address, or something that looks like it. As long as the name in front of the @ is a valid user name, they get authenticated. The problem is that an entry is made in the CALLS table for each unique name they enter and their actual usage is spread out over all the names they have used. Thanks. David __________________________________________________ David Swearingin (david@carolnet.com) CARROLLTON INTERNET SERVICE (www.carolnet.com) First Financial Group, Inc. 11 N. Folger, Carrollton, MO 64633 816-542-3002 Fax 816-542-3003

David Swearingin said once upon a time: > >Is there a way to stop S&A manager from authenticating a user who adds >@domain.com or @anything.com to their correct user name from being >authenticated? Some users get confused and instead using just their user >name they use their email address, or something that looks like it. As >long as the name in front of the @ is a valid user name, they get >authenticated. The problem is that an entry is made in the CALLS table for >each unique name they enter and their actual usage is spread out over all >the names they have used. Get a RADIUS with the source code. It wouldn't take much to modify it to do this.

This is a multi-part message in MIME format. ------=_NextPart_000_0007_01BE6F8D.B9354320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit > As has been noted here before, the USR Radius server scarcely works. > I've been looking at alternatives - in particular Cistron, Merit, and > Radiator - and am looking for advice. What's the best bet in terms of > cost, performance, reliability, ease of maintenance, etc.? Blowing my own trumpet, I'm afraid, but you might be interested to know that we're thinking of launching an extensible RADIUS server that we've recently written for in house use as a commercial product. The core server would be supplied as Java compiled code which can be run on any system capable of running a Java 1.1.x runtime, but the special feature is a Java API which system managers can use to write simple pluggable extensions which can be chained together to provide sophisticated authentication and accounting mechanisms. I've already used the API to implement o Access control based on DNIS and JDBC o GRIC roaming proxy o Unix password authentication (uses JNI to access getpwnam) o JDBC password authentication o JDBC attribute setting o JDBC accounting I'd be interested in getting feedback from other RADIUS users on whether an easily extensible RADIUS server would have any demand (commercial or otherwise). thanks, Ray. -- Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ UK Telephone: +44-1865-856000 Fax: +44-1865-856001 Email: ray.bellis@community.net.uk URL: http://www.community.co.uk/ ------=_NextPart_000_0007_01BE6F8D.B9354320 Content-Type: text/x-vcard; name="Ray Bellis.vcf" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="Ray Bellis.vcf" BEGIN:VCARD VERSION:2.1 N:Bellis;Ray;; FN:Ray Bellis ORG:Oxford CommUnity Internet plc; TITLE:Technical Director TEL;WORK;VOICE:+44 (1865) 856000 TEL;WORK;FAX:+44 (1865) 856001 ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Windsor House=3D0D=3D0A12 High = Street;Kidlington;Oxfordshire;OX5 2PJ;United Ki=3D ngdom LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Windsor House=3D0D=3D0A12 High = Street=3D0D=3D0AKidlington, Oxfordshire OX5 2PJ=3D0D=3D =3D0AUnited Kingdom URL: URL:http://www.community.co.uk/ EMAIL;PREF;INTERNET:rpb@community.net.uk EMAIL;INTERNET:rpb@community.net.uk EMAIL;INTERNET:rpb@community.co.uk REV:19990205T105103Z END:VCARD ------=_NextPart_000_0007_01BE6F8D.B9354320--

Brett Murphy said once upon a time: > >Hi All, >Has anyone got some sample filters or FAQ's for filtering on >the HyperARC? >For example, blocking the BO port on 31337 etc Here's what I use for email-only dialup. It also allows them to access our web server. I'd be curious as to anyone coming up with a "default" filter for dialup that does block things like BackOrifice. mail.in: #filter IP: 010 AND dst-addr = 198.060.022.022/32; 020 ACCEPT tcp-dst-port = 106; 030 AND dst-addr = 198.060.022.022/32; 040 ACCEPT tcp-dst-port = 109; 050 AND dst-addr = 198.060.022.022/32; 060 ACCEPT tcp-dst-port = 110; 070 AND dst-addr = 198.060.022.022/32; 080 ACCEPT tcp-dst-port = 143; 090 AND dst-addr = 198.060.022.022/32; 100 ACCEPT tcp-dst-port = 25; 110 AND dst-addr = 198.060.022.022/32; 120 ACCEPT udp-dst-port = 53; 130 AND dst-addr = 198.060.022.002/32; 140 ACCEPT udp-dst-port = 53; 150 AND dst-addr = 198.060.022.000/26; 160 ACCEPT tcp-dst-port = 80; 170 AND dst-addr = 198.060.022.000/26; 180 ACCEPT tcp-dst-port = 8000; 190 AND dst-addr = 198.060.022.000/26; 200 ACCEPT tcp-dst-port = 443; 210 ACCEPT protocol = icmp; 220 DENY; mail.out: #filter IP: 010 AND src-addr = 198.060.022.0/26; 020 ACCEPT protocol = tcp; 030 AND src-addr = 198.060.022.002/32; 040 ACCEPT udp-src-port = 53; 050 AND src-addr = 198.060.022.022/32; 060 ACCEPT udp-src-port = 53; 070 ACCEPT protocol = icmp; 080 DENY;

K Mitchell said once upon a time: > > Recently I've been getting sporadic complaints of busy signals from >customers during times when our modem usage is signaficantly lower than >100%. This is also not normally following a period in which most or all >modems were in use. After talking in depth with some of these customers, >the bsuies seem to be normally generated busy signals, not fast busies. I >have PRIs coming into HiPer DSP 1.2.60, ARC 4.1.72, NMC 5.5.5. Is this a >DSP/SRC issue, or possibly telco? Any suggestions/ideas appreciated. We have this problem, and it is mainly due to the fact that our current PRIs (soon to change) are in a sequential hunt. That is, it fills up bottom to top, rather than using the more desired "least-used channel" algorithm. What will periodically happen is that a channel on a DSP will get stuck in a weird state, and it won't allow calls to go past it. The callers will then receive "out-of-order" or fast busies. Thankfully, in this situation, the "calls failed" will still increment for each busy signal generated. My solution has been to use a script that will run the "calls failed" vs. the "calls connected" stat and busy out the PRI when it reaches a certain threshold. Then it waits for the calls to disconnect and it hardware resets the card. Keeping the DSP's happy is like spinning plates. Once they all get into the right mindset, this doesn't happen very often. However, if power gets cut to your rack, you have to start all over again.

>ie, let's say I want a pool with approximately 30 addresses in it...I'd >like it advertised as a single /27, do I do: >add ip pool dialup initial_pool_address x.y.z.32 size 32 state public > route aggregate >or: >add ip pool dialup initial_pool_address x.y.z.33 size 30 state public > route aggregate > >Which of those would result in the correct behavior? I'm hoping the >first since that would result in fewer wasted IP addresses, but so far I >can't seem to get that to aggregate and I'm not sure what I'm missing. Theoretically, this should work, since your router sees it as a subnet and your ARC sees them as host-routes. However, it is still illegal to have a device on the subnet number. I suspect that the ARC is simply trying to keep you out of trouble. It would definitely be bad for the person connecting up with the broadcast address.

Are there different flavors of the DSP and Hiper Code in the 4.1.59 release and the 1.2.59 release. If there are how do you tell? TCM only reports 1.2.59 not 1.2.59-6 -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >On Mon, 15 Mar 1999, Jamie Orzechowski wrote: > >> I seem to be having ALOT of PPP authentication problems! ... I am running >> that latest ARC code ... 4.1.59-6 .. anyone have any ideas how to fix >> this???? > >Do please refer to the release notes and make sure that > >ppp offloading is enabled >disable ppp receive accm > >> >> People will connect and get dropped right away. When I dial in with a term >> program I will dial and immediatly I will get a authentication failure text >> come up before I have even typed anything ... >> >> here is a cut & paste >> >> atdtXXX-XXXX >> CONNECT 115200 >> >> Welcome to 3Com Total Control HiPer ARC (TM) >> Networks That Go The Distance (TM) >> UserName: Authentication failure >> >> UserName: >> >> > >This is something wrong here - I would suspect config. Either the client >or the modem_group is configured wrong. > >you can do a tap on the port and find out what is happening. > >krish > > >> >> Sometimes PPP starts at the same prompt before I type anything ... >> >> here is a message an advanced linux user of our system has sent me. >> >> --start >> >> hi... it's me again. i've been doing some more playing around trying to >> figure out why the linux 2.2.x series won't allow me to connect. i >> booted into 2.0.36 yesterday, and i ran minicom (you know, the unix term >> app?) anyway... i found that after i dialed, the first prompt for >> authentication would automatically fail, even though i hadn't typed in >> anything yet... on other times (specifically if i got connected at >> 44000) it would start sending PPP garbage like ?~?~?~?~?~... etc... at >> the authentication prompt um... i have a GVC 56k X2 modem... and as far >> as i know it still uses the v.42 protocol. (upgrade to v.90 requires a >> chip replacement)... does that bring anything to mind as to why maybe i >> can't get connected? i think it at least shows why i've been getting the >> "unsupported protocol" errors from pppd.... thanks. >> >> --stop >> >> >> >> --------------------------------------------------- >> Have a Great Day! >> >> Jamie Orzechowski >> RipNET System Admin >> >> Tel.: 613-342-3946 ext 293 >> Tel.: 800-267-4434 ext 293 >> Page.: 613-341-0883 >> EMail.: mhz@ripnet.com >> Web.: http://www.ripnet.com >> Personal.: http://www.moonchilli.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. >

S&A uses a scripting language. You can edit the script to crop off the domain information for all logins.. -M |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Swearingin |Sent: Tuesday, March 16, 1999 8:45 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc)How to turn off @anything.com | | |Is there a way to stop S&A manager from authenticating a user who adds |@domain.com or @anything.com to their correct user name from being |authenticated? Some users get confused and instead using just their user |name they use their email address, or something that looks like it. As |long as the name in front of the @ is a valid user name, they get |authenticated. The problem is that an entry is made in the CALLS table for |each unique name they enter and their actual usage is spread out over all |the names they have used. | |Thanks. | |David |__________________________________________________ |David Swearingin (david@carolnet.com) |CARROLLTON INTERNET SERVICE (www.carolnet.com) |First Financial Group, Inc. |11 N. Folger, Carrollton, MO 64633 |816-542-3002 Fax 816-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. |

If I set the Radius Attributes to Ascend, what are the attributes that change?? Specifically, I'm trying to generate the next accounting attributes: 190 Ascend-Pre-Input-Octects 191 Ascend-Pre-Output-Octects 192 Ascend-Pre-Input-Packets 193 Ascend-Pre-Output-Packets 195 Ascend-Disconnect-Cause 196 Ascend-Connect-Progress 197 Ascend-Data-Rate 198 Ascend-PreSession-Time Thank you in advance, Best Regards, Erick Mancera

Hi All, Has anyone got some sample filters or FAQ's for filtering on the HyperARC? For example, blocking the BO port on 31337 etc -- All the best, Brett Murphy System Administrator, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: sysadmin@alphalink.com.au The contents of this message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.

Jeff Mcadams said once upon a time: >We're on point-to-point links routed as /32's though, there's no concept >of broadcast address. However, when you go to anything larger than /32 with an aggregate, the devices in the same subnet you are routing to will recognize the top and bottom as broadcast/subnet. There is no exception. Your ARC is trying to follow the rules, and in this case you're asking to have your cake and eat it too. If you want to use all 32 addresses, you can't use an aggregate.

Pete's assessment of the ARC behavior is correct. The ARC does not allow the lowest and highest address of a subnet to be used for the user as these are not legal addresses on the subset defined by the pool. It enforces these rules so that users don't end up with bizzare behavior. -- Matt Pete Ashdown <pashdown@xmission.com> on 03/16/99 10:32:25 AM Please respond to usr-tc@lists.xmission.com cc: (Matt Harper/MW/US/3Com) >ie, let's say I want a pool with approximately 30 addresses in it...I'd >like it advertised as a single /27, do I do: >add ip pool dialup initial_pool_address x.y.z.32 size 32 state public > route aggregate >or: >add ip pool dialup initial_pool_address x.y.z.33 size 30 state public > route aggregate > >Which of those would result in the correct behavior? I'm hoping the >first since that would result in fewer wasted IP addresses, but so far I >can't seem to get that to aggregate and I'm not sure what I'm missing. Theoretically, this should work, since your router sees it as a subnet and your ARC sees them as host-routes. However, it is still illegal to have a device on the subnet number. I suspect that the ARC is simply trying to keep you out of trouble. It would definitely be bad for the person connecting up with the broadcast address. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Hi All, Far too regularly I am finding that when I telnet to my HyperARC it drops the connection immediately. The problem remains until I powercycle the chassis. Has anyone seen this before? -- All the best, Brett Murphy System Administrator, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: sysadmin@alphalink.com.au The contents of this message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.

On Tue, 16 Mar 1999, Jamie Orzechowski wrote: > anyone know how to fix this? > > when a user dials into the system via a tem program and they type their > userID and password they will ALWAYS get a authenticaton faliure. Their > username is stored in /etc/passwd and radius is told that the DEFAULT user > is Unix-PW. > > They can login fine with PAP .... > If you are using /etc/passwd for users - then you will get authenticated only using PAP. you have to set the hiper arc to have the authentication preference as PAP krish > > now if the user has an entry in the radius users file and the type in their > name and password via hyperterm they will get the PPP session start. > > What I would like to know is how can I make it so that ALL users will get a > PPP session start even if they are stored in /etc/passwd ... I believe this > is a radius problem .. any ideas?? > > here is my DEFAULT radius user > > DEFAULT Authentication-Type= Unix-PW, Framed-Protocol= PPP, > Simultaneous-use= 2 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

--0__=CGI2djvzSJsm5vPsT8wsqqG2xN3bVMRZql0pOrx5P9doHoi8tqwbPvxU Content-type: text/plain; charset=us-ascii Content-Disposition: inline RAD_MODEM_TRAINING_TIME 0x9842 - Modem training time RAD_IF_INDEX 0x9843 - SNMP MIB-II interface # (not RADIUS port #) -- Matt "Sam Lowe" <slowe@universalcom.net> on 03/16/99 06:51:41 AM Please respond to usr-tc@lists.xmission.com cc: (Matt Harper/MW/US/3Com) Do any of you fine list members know what the attribute codes 38978 & 38979 refer to. I suspect they have something to do with the HIPER cards, but can't find this info anywhere. TIA. Samuel S. Lowe Director, Data Network Services UniversalCom, Inc. slowe@universalcom.net --0__=CGI2djvzSJsm5vPsT8wsqqG2xN3bVMRZql0pOrx5P9doHoi8tqwbPvxU Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-transfer-encoding: base64 Content-Description: Internet HTML PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD48 SEVBRD4NCjxNRVRBIGNvbnRlbnQ9dGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSBodHRwLWVx dWl2PUNvbnRlbnQtVHlwZT4NCjxTVFlMRT48L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSciTVNI VE1MIDUuMDAuMDkxMC4xMzA5IicgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmdDb2xv cj0jZmZmZmZmPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRvIGFueSBv ZiB5b3UgZmluZSBsaXN0IG1lbWJlcnMga25vdyB3aGF0IHRoZSBhdHRyaWJ1dGUgY29kZXMgDQoz ODk3OCAmYW1wOyAzODk3OSByZWZlciB0by4mbmJzcDsgSSBzdXNwZWN0IHRoZXkgaGF2ZSBzb21l dGhpbmcgdG8gZG8gd2l0aCB0aGUgDQpISVBFUiBjYXJkcywgYnV0IGNhbid0IGZpbmQgdGhpcyBp bmZvIGFueXdoZXJlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJz cDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRJQS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48QlI+U2FtdWVs IFMuIExvd2U8QlI+RGlyZWN0b3IsIERhdGEgTmV0d29yayANClNlcnZpY2VzPEJSPlVuaXZlcnNh bENvbSwgDQpJbmMuPEJSPnNsb3dlQHVuaXZlcnNhbGNvbS5uZXQ8QlI+PEJSPjwvRk9OVD48L0RJ Vj48L0JPRFk+PC9IVE1MPg0K --0__=CGI2djvzSJsm5vPsT8wsqqG2xN3bVMRZql0pOrx5P9doHoi8tqwbPvxU--

OK folks... latest question. If I want to set up my IP Pools on arcs to aggregate, does the initial_pool_address need to be the network address of the aggregate route? or does it need to be the initial host address in the "subnet"? ie, let's say I want a pool with approximately 30 addresses in it...I'd like it advertised as a single /27, do I do: add ip pool dialup initial_pool_address x.y.z.32 size 32 state public route aggregate or: add ip pool dialup initial_pool_address x.y.z.33 size 30 state public route aggregate Which of those would result in the correct behavior? I'm hoping the first since that would result in fewer wasted IP addresses, but so far I can't seem to get that to aggregate and I'm not sure what I'm missing. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Hi Jeff, Perhaps you could/should use proxy arp instead - that will allow you to use all 32 addresses from the calass C in the scenareo you list below. Simply add a pool on the ARC for the range you want and then you don't have to use an aggrigate route enabled for the pool. -- Matt Jeff Mcadams <jeffm@iglou.com> on 03/16/99 11:05:18 AM Please respond to usr-tc@lists.xmission.com cc: (Matt Harper/MW/US/3Com) Thus spake Pete Ashdown >>ie, let's say I want a pool with approximately 30 addresses in it...I'd >>like it advertised as a single /27, do I do: >>add ip pool dialup initial_pool_address x.y.z.32 size 32 state public >> route aggregate >>or: >>add ip pool dialup initial_pool_address x.y.z.33 size 30 state public >> route aggregate >> >>Which of those would result in the correct behavior? I'm hoping the >>first since that would result in fewer wasted IP addresses, but so far I >>can't seem to get that to aggregate and I'm not sure what I'm missing. >Theoretically, this should work, since your router sees it as a subnet and >your ARC sees them as host-routes. However, it is still illegal to have a >device on the subnet number. I suspect that the ARC is simply trying to >keep you out of trouble. It would definitely be bad for the person >connecting up with the broadcast address. We're on point-to-point links routed as /32's though, there's no concept of broadcast address. Here's the scenario. eth:1 on the arc is x.y.z.3/24 eth 1/1/2 on the cisco is x.y.z.1/24 with the ip pool as above, none of the addresses in the pool are on the network or broadcast address of the ethernet, so no problem. The Cisco would see the route as x.y.z.32/27 with a next hop of x.y.z.3. The Cisco handles this with no problem. Then internally, the arc sees the addresses in the pool as /32's. Long and short of it is that there's nothing illegal about this setup. The Cisco doesn't know what the ultimate subnet'ing of the end networks are like, so if forwards to the next hop of the route even the all zeros address. This is confirmed BTW. The Cisco has to assume that the ultimate addresses might be "subnetted" down to /32 possibly (in this case they are) so it forwards even all-zeros and all-ones for the routes it has. -- 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.

At 10:22 AM 3/16/99 -0600, you wrote: >S&A uses a scripting language. You can edit the script to crop off the domain >information for all logins.. > >-M Sounds easy enough. Do you know the name of the script file? Has anyone else already done this? Thanks. David > > >|-----Original Message----- >|From: owner-usr-tc@lists.xmission.com >|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Swearingin >|Sent: Tuesday, March 16, 1999 8:45 AM >|To: usr-tc@lists.xmission.com >|Subject: (usr-tc)How to turn off @anything.com >| >| >|Is there a way to stop S&A manager from authenticating a user who adds >|@domain.com or @anything.com to their correct user name from being >|authenticated? Some users get confused and instead using just their user >|name they use their email address, or something that looks like it. As >|long as the name in front of the @ is a valid user name, they get >|authenticated. The problem is that an entry is made in the CALLS table for >|each unique name they enter and their actual usage is spread out over all >|the names they have used. >| >|Thanks. >| >|David >|__________________________________________________ >|David Swearingin (david@carolnet.com) >|CARROLLTON INTERNET SERVICE (www.carolnet.com) >|First Financial Group, Inc. >|11 N. Folger, Carrollton, MO 64633 >|816-542-3002 Fax 816-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. >| > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 816-542-3002 Fax 816-542-3003

anyone know how to fix this? when a user dials into the system via a tem program and they type their userID and password they will ALWAYS get a authenticaton faliure. Their username is stored in /etc/passwd and radius is told that the DEFAULT user is Unix-PW. They can login fine with PAP .... now if the user has an entry in the radius users file and the type in their name and password via hyperterm they will get the PPP session start. What I would like to know is how can I make it so that ALL users will get a PPP session start even if they are stored in /etc/passwd ... I believe this is a radius problem .. any ideas?? here is my DEFAULT radius user DEFAULT Authentication-Type= Unix-PW, Framed-Protocol= PPP, Simultaneous-use= 2

We have had these problems occasionally, using E1 in Australia. Definitely a Telco problem in our case. K Mitchell wrote: > Recently I've been getting sporadic complaints of busy signals from > customers during times when our modem usage is signaficantly lower than > 100%. This is also not normally following a period in which most or all > modems were in use. After talking in depth with some of these customers, > the bsuies seem to be normally generated busy signals, not fast busies. I > have PRIs coming into HiPer DSP 1.2.60, ARC 4.1.72, NMC 5.5.5. Is this a > DSP/SRC issue, or possibly telco? Any suggestions/ideas appreciated. > > Kirk > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- All the best, Brett Murphy System Administrator, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: sysadmin@alphalink.com.au The contents of this message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.

How emarrasing! I am using 4.1.11 I'll install the latest one asap. Tatai SV Krishnan wrote: > On Tue, 16 Mar 1999, Brett Murphy wrote: > > > Hi All, > > Far too regularly I am finding that when I telnet to my HyperARC > > it drops the connection immediately. The problem remains until I > > powercycle the chassis. Has anyone seen this before? > > Need to know the version of code you are using - some version of 4.0 and > some versions of 4.1 did have some memory problems. 4.1.59 -6 - the > latest one in the web site http://totalservice.usr.com > does fix a lot of issues. > > If you are seeing this problem with 4.1.59 -6 then we need more info - > like syslogs > > krish > > > > > -- > > > > All the best, > > Brett Murphy > > System Administrator, Alphalink (Australia) PTY LTD > > ph: +61 3 9486-8844 fax: +61 3 9486-6822 > > email: sysadmin@alphalink.com.au > > > > The contents of this message may not be quoted, > > copied, reproduced or published in part or in whole, > > without the written authorization of Brett Murphy, > > Director, Alphalink (Australia) Pty Ltd. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- All the best, Brett Murphy System Administrator, Alphalink (Australia) PTY LTD ph: +61 3 9486-8844 fax: +61 3 9486-6822 email: sysadmin@alphalink.com.au The contents of this message may not be quoted, copied, reproduced or published in part or in whole, without the written authorization of Brett Murphy, Director, Alphalink (Australia) Pty Ltd.

Thus spake Pete Ashdown >>ie, let's say I want a pool with approximately 30 addresses in it...I'd >>like it advertised as a single /27, do I do: >>add ip pool dialup initial_pool_address x.y.z.32 size 32 state public >> route aggregate >>or: >>add ip pool dialup initial_pool_address x.y.z.33 size 30 state public >> route aggregate >> >>Which of those would result in the correct behavior? I'm hoping the >>first since that would result in fewer wasted IP addresses, but so far I >>can't seem to get that to aggregate and I'm not sure what I'm missing. >Theoretically, this should work, since your router sees it as a subnet and >your ARC sees them as host-routes. However, it is still illegal to have a >device on the subnet number. I suspect that the ARC is simply trying to >keep you out of trouble. It would definitely be bad for the person >connecting up with the broadcast address. We're on point-to-point links routed as /32's though, there's no concept of broadcast address. Here's the scenario. eth:1 on the arc is x.y.z.3/24 eth 1/1/2 on the cisco is x.y.z.1/24 with the ip pool as above, none of the addresses in the pool are on the network or broadcast address of the ethernet, so no problem. The Cisco would see the route as x.y.z.32/27 with a next hop of x.y.z.3. The Cisco handles this with no problem. Then internally, the arc sees the addresses in the pool as /32's. Long and short of it is that there's nothing illegal about this setup. The Cisco doesn't know what the ultimate subnet'ing of the end networks are like, so if forwards to the next hop of the route even the all zeros address. This is confirmed BTW. The Cisco has to assume that the ultimate addresses might be "subnetted" down to /32 possibly (in this case they are) so it forwards even all-zeros and all-ones for the routes it has. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Jamie Orzechowski >DEFAULT Authentication-Type= Unix-PW, Framed-Protocol= PPP, >Simultaneous-use= 2 ^^^^^^^^^^^^^^^^^^^^ There's your problem...you're saying, only allow them to log in if they have a Framed-Protocol of PPP. At the time that they're typing in their userid and password to the login prompt, they *aren't* running PPP, so it rightly denies them. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Tatai SV Krishnan >On Tue, 16 Mar 1999, Jamie Orzechowski wrote: >> anyone know how to fix this? >> >> when a user dials into the system via a tem program and they type their >> userID and password they will ALWAYS get a authenticaton faliure. Their >> username is stored in /etc/passwd and radius is told that the DEFAULT user >> is Unix-PW. >> >> They can login fine with PAP .... >> >If you are using /etc/passwd for users - then you will get authenticated >only using PAP. A bit of a misstatement...you can't use CHAP because CHAP requires clear-text password storage...which /etc/passwd doesn't have. You *can* login from a clear-text login prompt which I believe is what Jamie was asking. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Matt Harper >Pete's assessment of the ARC behavior is correct. The ARC does not allow the >lowest and >highest address of a subnet to be used for the user as these are not legal >addresses on the subset >defined by the pool. Not true, since the Arc, once the users are logged in on PPP connections, is going to see them as /32's where there is no concept of network address, broadcast address, all ones address and all zeros address. The Cisco handles this correctly, if it has a route to: x.y.z.32/27 with a next hop of x.y.z.3, (which is what I want my situation to be) and it gets a packet with a dest address of x.y.z.32, it correctly forwards the packet on to x.y.z.3. Again, this is because the Cisco doesn't know what the ultimate network mask is for the user, if its /32, the address *is* legal, so it forwards it on. >It enforces these rules so that users don't end up with >bizzare behavior. And ends up making people eat up more IP addresses if they want to aggregate their IP pools. For me to set up this chassis then (a double-up chassis basically, 12 quads, 2 dsp's and an arc) I'm gonna have to eat up another 10 or so IP addresses, just to end up with a useable pool of 92 addresses if I want to aggregate (PRI's, only 92 B-channels, not 96). So much for the benefits of classless addressing. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Matt Harper >Perhaps you could/should use proxy arp instead - that will allow you to use all >32 addresses from the calass C >in the scenareo you list below. Simply add a pool on the ARC for the range you >want and then you don't have >to use an aggrigate route enabled for the pool. I can do that, but that only works if I'm pulling addresses out of the same class C that eth:1 is on...which limits scaleability, and also wastes IP addresses. Besides, that doesn't address the issue that the "all-zeros" address of the route advertisement is (at least potentially) a valid IP address for use, regardless of whether its in the same /24 as eth:1 or not. Might I suggest that 3Com make it so that the configuration of route aggregation is seperate from the configuration of the IP Pools in the HiPer Arc. Personally, the way its behaving now, I consider it at least borderline broken. If you really think about the concepts, aggregation of routes is a seperate (related, but seperate) concept from defining dialin pools. Particularly when you start getting multiple routing protocols (OSPF is coming, BGP is eventually coming I believe, as well as others), and start redistributing between them, more precise control of aggregation and summarization is going to be needed. Aggregation really shouldn't be tied to the definition of ip pools...that's very limiting. Essentially, that makes the Arc limited to being an access server, and a limiting one at that, instead of really being a full router, which seems to be how 3Com wants to place it (and understandably so), with full control over routing advertisements. As it is, its really not feasible for me to do route aggregation because of the extra IP addresses that it chews up. File this under the category "short-sighted designs". >Thus spake Pete Ashdown >>>ie, let's say I want a pool with approximately 30 addresses in it...I'd >>>like it advertised as a single /27, do I do: >>>add ip pool dialup initial_pool_address x.y.z.32 size 32 state public >>> route aggregate >>>or: >>>add ip pool dialup initial_pool_address x.y.z.33 size 30 state public >>> route aggregate >>> >>>Which of those would result in the correct behavior? I'm hoping the >>>first since that would result in fewer wasted IP addresses, but so far I >>>can't seem to get that to aggregate and I'm not sure what I'm missing. >>Theoretically, this should work, since your router sees it as a subnet and >>your ARC sees them as host-routes. However, it is still illegal to have a >>device on the subnet number. I suspect that the ARC is simply trying to >>keep you out of trouble. It would definitely be bad for the person >>connecting up with the broadcast address. >We're on point-to-point links routed as /32's though, there's no concept >of broadcast address. >Here's the scenario. >eth:1 on the arc is x.y.z.3/24 >eth 1/1/2 on the cisco is x.y.z.1/24 >with the ip pool as above, none of the addresses in the pool are on the >network or broadcast address of the ethernet, so no problem. The Cisco >would see the route as x.y.z.32/27 with a next hop of x.y.z.3. The >Cisco handles this with no problem. Then internally, the arc sees the >addresses in the pool as /32's. >Long and short of it is that there's nothing illegal about this setup. >The Cisco doesn't know what the ultimate subnet'ing of the end networks >are like, so if forwards to the next hop of the route even the all zeros >address. This is confirmed BTW. The Cisco has to assume that the >ultimate addresses might be "subnetted" down to /32 possibly (in this >case they are) so it forwards even all-zeros and all-ones for the routes >it has. >-- >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. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Jeff Mcadams said once upon a time: >The Cisco router handles forwarding a packet with an "all-zeros host" >address on that route correctly and forwards it on to the next-hop, even >though it sees it as the network address for that route. It does this >because it doesn't know if the next-hop, or perhaps some hop on down the >line might be routing this block as /32's. Will classless addressing >and routing, this is the correct thing to do. We're not talking about multihop aggregation here though. We're talking about an ARC advertising to a subnet with RIP. Picture this problem: ARC is broadcasting /27 for a group of modem clients to subnet A. Device on subnet A sees /27, which indicates a block of IPs and and broadcast address and a subnet address. Device on subnet A desires to send a broadcast to the clients in /27, it sends it to the broadcast address. What is proper behavior of the ARC at this point? 1. Under broadcast rules, it then copies the broadcast to all /32's in the subnet? 2. Under subnet rules, it sends it to the broadcast address, which then gets discarded? 3. Under Mcadams rules, it sends the broadcast to the /32 using the broadcast address? I'm not trying to be sarcastic here, I'm just presenting a problem to your desired behavior. Personally, I'd pick #2, which I believe is what happens. Under your proposed scheme, how is the "Device" supposed to distinguish broadcast traffic from regular traffic for the IP using the broadcast address?

Hello Everyone, I'm new to this list but from the few days i've been on it looks like someone here might have the answer i need. I have 3 TC chassis with the configuration shown below. I have been having a problem with customers calling up and getting dropped immediately. Some users finish the handshake and get disconnected during authentication others never get past the handshake stage many users report messages saying "error 631" or "a connection could not be established please check you network configuration and try again" (something like that). Anyways the people complaining have been long standing customers who have never reported trouble then suddenly about a month ago everyone started having this trouble(about the time i put in a usr update). The only real pattern i see is that it mostly affects Kflex users and V.90 users and users with pc's(Compaq and Gateway) less that 3 months old. USR support told me to update the code to the version you see listed below and that all the V.90 problems would be resolved. I saw no difference with the new code except that WebTv users work great now. I have managed to get the real angry customers back online by turning off 56k/v.90 in thier modems with an init string but it's not a real solution because the problem is still there. Is anyone else seeing this problem? Is there a known bug with V.90/56k? Can anyone give me some advice on resolving this problem.....The USRTechs i have spoken with say that my customers have to go get thier modems updated to the latest code. Some of my customers have tried doing this and they are told by their vendors that there code is solid and their ISP (me) is the one with the problem.... any help or adice will be greatly appreciated Rudy Ferguson cygnus@vsta.com 1 3COM DUAL T1 NAC BBB6NZTY 11C 3.0.0 512 512 0000000000000101 3.5.0 2 3COM Quad V.34 Digital Modem NAC BCI6XI90 19U000 2.0.0 0 0 0000000110001000 5.10.9 3 3COM Quad V.34 Digital Modem NAC BCF6WXM6 19U000 2.0.0 0 0 0000000110001000 5.10.9 4 3COM Quad V.34 Digital Modem NAC BCL6Y9MA 19U000 2.0.0 0 0 0000000110001000 5.10.9 5 3COM Quad V.34 Digital Modem NAC BCG6X1OR 19U000 2.0.0 0 0 0000000110001000 5.10.9 6 3COM Quad V.34 Digital Modem NAC BCE6WRHG 19U000 2.0.0 0 0 0000000110001000 5.10.9 7 3COM Quad V.34 Digital Modem NAC BCI6XIG5 19U000 2.0.0 0 0 0000000110001000 5.10.9 8 3COM Quad V.34 Digital Modem NAC BCI6XI8M 19U000 2.0.0 0 0 0000000110001000 5.10.9 9 3COM Quad V.34 Digital Modem NAC BCG6X1UB 19U000 2.0.0 0 0 0000000110001000 5.10.9 10 3COM Quad V.34 Digital Modem NAC BCL6Y9NM 19U000 2.0.0 0 0 0000000110001000 5.10.9 11 3COM Quad V.34 Digital Modem NAC BCG6X1OL 19U000 2.0.0 0 0 0000000110001000 5.10.9 12 3COM Quad V.34 Digital Modem NAC BCG6X1KL 19U000 2.0.0 0 0 0000000110001000 5.10.9 13 3COM Quad V.34 Digital Modem NAC BCH6XGZI 19U000 2.0.0 0 0 0000000110001000 5.10.9 14 3COM High-Density 24 Channel NAC BC77B0TF 1OQ 0.49.0 8192 2048 0000000000000000 1.2.59 15 3COM High-Density 24 Channel NAC B1C8DPRE 1OQ 0.49.0 8192 2048 0000000000000000 1.2.59 16 3COM HiPer ARC NAC B648VNPZ 20C 19.0.0 65536 8192 0000000000000000 4.1.59 17 3COM Network Management Card with clock BCI6XJ5M 11I00000 3.0 20480 8192 0000000000000000 5.5.5 1 3COM Bellcore Approved Long Haul Dual T1 NIC 512 512 0000000000000101 14 3COM T1/E1 HDM NIC 8192 2048 0000000000000000 15 3COM T1/E1 HDM NIC 8192 2048 0000000000000000 16 3COM Dual 10/100 Ethernet NIC - PCI based 65536 8192 0000000000000000 17 3COM Ethernet NIC ???????? ?? 0 0 0000000000000000

Thus spake Pete Ashdown >Jeff Mcadams said once upon a time: >>We're on point-to-point links routed as /32's though, there's no concept >>of broadcast address. >However, when you go to anything larger than /32 with an aggregate, the >devices in the same subnet you are routing to will recognize the top and >bottom as broadcast/subnet. There is no exception. Your ARC is trying to >follow the rules, and in this case you're asking to have your cake and eat >it too. If you want to use all 32 addresses, you can't use an aggregate. Not true... For example...this from our cisco router: O E2 204.255.234.192/27 [110/1] via 204.255.229.254, 01:26:41, Serial1/0/4:0 [110/1] via 204.255.229.242, 01:26:41, Serial1/0/6:0 (two next hops because we have 2 parallel t1's to that remote city) Then this traceroute: ceroute to 204.255.234.192 (204.255.234.192): 1-30 hops, 38 byte packets 1 gator (192.107.41.4) 2.1 ms 0.810 ms 1.3 ms 2 lou2-fe4-1-0.lou.iglou.com (204.252.74.6) 148 ms 98.1 ms 206 ms 3 lex1-s0.lex.iglou.com (204.255.229.254) 21.0 ms 19.3 ms 20.7 ms The Cisco router handles forwarding a packet with an "all-zeros host" address on that route correctly and forwards it on to the next-hop, even though it sees it as the network address for that route. It does this because it doesn't know if the next-hop, or perhaps some hop on down the line might be routing this block as /32's. Will classless addressing and routing, this is the correct thing to do. Again, as I mentioned in another post, the real brokenness in the HiPer Arc is that it ties up the definition of route aggregation with the definition of the ip pools. This is very limiting, and dare I say, truly broken, as it leads to situation such as this where the Arc doesn't handle things really quite like it should. 3Com has put some really good thought into some stuff in the Arc's, but some design considerations leave a *lot* lacking. The control of routing information through aggregation and stuff being a big one. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Tue, 16 Mar 1999, David Swearingin wrote: >Is there a way to stop S&A manager from authenticating a user who adds >@domain.com or @anything.com to their correct user name from being >authenticated? Some users get confused and instead using just their user >name they use their email address, or something that looks like it. As >long as the name in front of the @ is a valid user name, they get >authenticated. The problem is that an entry is made in the CALLS table for >each unique name they enter and their actual usage is spread out over all >the names they have used. (you didn't say which version of SA you were using, so I'll assume SA6) The accounting server is recording whatever username that got authenticated. You can go into the radserv.scp within the Accounting_Request function and have it remove the [@foo] part... (from Accounting_Request) ; Is the User-Name attribute in the request? if(User_Name inList Request) thisUser = Request.User_Name ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;; Is there a @ symbol in the username? ;;;;; If so then proxy the accounting request ;;;;; if there is a domain in the domains table. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; if(instr(Request.User_Name, "@") > 0) ; For Proxy requests we need to be able to ; differentiate between Accounting and Security ; messages. So, set a flag indicating that this ; is an Accounting message ; bAcctingProxy = True Call Check-RADIUS-Proxy ; If we reach this point then the ; accounting request has NOT been proxied endif ; proxying accounting ... The stub "Check-RADIUS-Proxy" is the magic that actually sends the request to another RADIUS server. Basically what you want is the username only: (from Check-RADIUS-Proxy) ; Isolate the <User_Name>@<Domain-Name> AtPos = instr(Request.User_Name, "@") if(AtPos > 0) n = AtPos - 1 UserNameOnly = Mid$(Request.User_Name, 1, n) n = AtPos + 1 domainname = Mid$(Request.User_Name, n) else ; no domain or realm in user_name attribute ; so return return endif If you need any help, just ask. For me, this is a 30 second "hack". --Ricky

On Tue, 16 Mar 1999, Pete Ashdown wrote: >Get a RADIUS with the source code. It wouldn't take much to modify it to >do this. If you've ever even looked at the USR RADIUS server... you have the "source." There is a tcl/perl like script that the server loads to control the authentication process. The user/administrator has complete control over what the script does. It's really a powerful engine. (if programmed efficiently) --Ricky

Jeff Mcadams said once upon a time: >Thus spake Paul Oster >> Anyone know of a device that'll let me hook a modem up to it and >>"switch" a dialin between numerious serial ports (which will be connected >>to the above equipent) Something CHEAP would be preferable... any >>suggestions? > >Get an old terminal server. We use a PM-25 or two to do this, works >pretty well for us. We've also got some old Xyplex equipment around >that we could use if necessary (or sell if that's the route you want to >go...it would fit the requirement mentioned in all caps above :) No please, buy my 32 port Xylogics Annex 3. I'll sell it to you CHEAP!!

Anyone know of a device that'll let me hook a modem up to it and "switch" a dialin between numerious serial ports (which will be connected to the above equipent) Something CHEAP would be preferable... any suggestions? Paul M. Oster <devious@minot.com> http://www.minot.com/ Magic Internet Services (701) 838-1265 Minots FIRST Internet Connection -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=- "I might not agree with what you have to say but I will defend, to my death, your right to say it." - Voltaire

Thus spake Pete Ashdown >Jeff Mcadams said once upon a time: >>The Cisco router handles forwarding a packet with an "all-zeros host" >>address on that route correctly and forwards it on to the next-hop, even >>though it sees it as the network address for that route. It does this >>because it doesn't know if the next-hop, or perhaps some hop on down the >>line might be routing this block as /32's. Will classless addressing >>and routing, this is the correct thing to do. >We're not talking about multihop aggregation here though. But we are. >We're talking >about an ARC advertising to a subnet with RIP. Picture this problem: >ARC is broadcasting /27 for a group of modem clients to subnet A. >Device on subnet A sees /27, which indicates a block of IPs and and > broadcast address and a subnet address. >Device on subnet A desires to send a broadcast to the clients in /27, it >sends it to the broadcast address. That's just it though, Device on subnet A *can't* know whether its sending to a broadcast address or a /32. Under classless rules, its sending it to a destination IP address, that IP address might be a broadcast, it might be a host address in a larger block, or it might be a host address (/32). >What is proper behavior of the ARC at this point? >1. Under broadcast rules, it then copies the broadcast to all /32's in the > subnet? >2. Under subnet rules, it sends it to the broadcast address, which then > gets discarded? >3. Under Mcadams rules, it sends the broadcast to the /32 using the > broadcast address? Well, let me reword #3 to what the option really is (same could be done on the others) 3. Under Classless rules, it sends the packet to the next-hop or destination based on the longest-match netmask in its routing table. There is no concept of a packet being inherently a broadcast packet. Its sent to a destination IP address, nothing more. Again, that destination IP address *might* end up being a broadcast address, but its not necessarily just because some system along the way sees it as the "all-ones" address of one of its routes. *IF* the device finds that the destination address is a broadcast address on a directly connected network, *then* it gets to decide if its going to translate that directed broadcast, to a layer 2 broadcast. My personal preference on that decision is not to do that (no ip directed-broadcast :). >I'm not trying to be sarcastic here, I'm just presenting a problem to your >desired behavior. Its not a problem. You're assuming that a device two hops away from the destination gets to decide whether the packet is a broadcast packet or not, and there's just no way for that device to know that under classless rules. >Personally, I'd pick #2, which I believe is what >happens. Under your proposed scheme, how is the "Device" supposed to >distinguish broadcast traffic from regular traffic for the IP using the >broadcast address? If you've got a device with a /32 route for the same IP address as a broadcast address for a directly connected broadcast-capable medium, then that's configuration error. That's why we, as network admins, get paid the big bucks (if my boss is reading this, "hint, hint"). However, my example I originally gave, didn't involve any broadcast addresses on any broadcast-capable media, and yet the HiPer Arc forced me to waste IP addresses to avoid a situation that doesn't exist! -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

My HiperARC doesn't seem to be sending Nas-Identifer to radius. All of my NetServers send this info, but the HiPer doesn't. Do I have to set anything in the ARC besides system name and system transmit_authentication_name? Anyone else having this problem? I'm running 4.1.72. Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

What version of NMC are you using? I'm getting the card names/types right, but no lights. Randy > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stephen Amadei > Sent: Tuesday, March 16, 1999 3:47 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) My latest toy TC script... > > > > A couple of days ago, I was inquiring about the LED status on the USR's... > I'd like to thank everyone who responded, and as I promised, I am sharing > the fruits of my labor... > > Someone else has probably already done this, but since I couldn't find any > code like it, I wrote my own... > > A "Total Control Virtual Display Program" What this does is create > Gif files that represent your TC units. This is an early edition... I > plan on prettying it up later, but it's mostly functional now, but I need > to write a few other useless toys for my company. ;-) > > Some limitations: > > - It creates FOUR gif files for each of your Total Controls. This is in > order to create an animated Gif file in the future, to provide for > blinking LEDs. Disregard the extra GIFs. > - It does not support the NetServer... I didn't have one handy when I > built this... if someone gives me readonly access to a NetServer > equipped TC, I will add it. > - It does support the T1 card, Digital Quads, Analog Quads, D-A Quads, > Hiper DSP, Hiper ARC, NMC and NMC with clock. For added cards, see > note above about NetServer. > - Requires CMU-SNMP, SNMPWALK, the GD library, GD perl library things and > parts of MRTG. > - It's absolutely not guarenteed to work anywhere... ;-) > > If you are feeling lucky, you can get the script at > http://www.dandy.net/~amadei/tcview > and see a live demo at > http://www.dandy.net/statistics/tc.html > > Let me know what you think, and any suggestions. > > ----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. >

Thus spake Peter D. Mayer >My HiperARC doesn't seem to be sending Nas-Identifer to radius. All of my >NetServers send this info, but the HiPer doesn't. Do I have to set anything in >the ARC besides system name and system transmit_authentication_name? >Anyone else having this problem? I'm running 4.1.72. We've noticed the same thing. Not really sure I'd term it a "problem" as such. To my knowledge NAS-Identifier is not required, so its just a difference in implementation. I almost considered using that as a way to distinguish accounting records coming from a NETServer as opposed to accounting records coming from an Arc, but decided that probably wouldn't be a good thing to rely on. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Paul Oster > Anyone know of a device that'll let me hook a modem up to it and >"switch" a dialin between numerious serial ports (which will be connected >to the above equipent) Something CHEAP would be preferable... any >suggestions? Get an old terminal server. We use a PM-25 or two to do this, works pretty well for us. We've also got some old Xyplex equipment around that we could use if necessary (or sell if that's the route you want to go...it would fit the requirement mentioned in all caps above :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I have a question concerning Netserver. How do you secure the access to the Ethernet port from intruders? Do you use add snmp host writer <ip> command (wich doesn't seem to do anything in my environment? How do you secure Telnet access? Thanks for the input Ralph

I would be interested in looking at what you have done with the script. I have seen it there, but never really paid attention to it. I am using ver 6.0.8 on an nt?? I wonder if it will still work? tony Ricky Beam wrote: > On Mon, 15 Mar 1999, Chris Hanes wrote: > >As has been noted here before, the USR Radius server scarcely works. > >I've been looking at alternatives - in particular Cistron, Merit, and > >Radiator - and am looking for advice. What's the best bet in terms of > >cost, performance, reliability, ease of maintenance, etc.? > > Yes, people have noted that before. The USR radius server, as it comes from > USR, is a very poor excuse for a RADIUS server. HOWEVER, if you spend some > time working on replacing the script, the core server part of the system is > very powerful. I look at it like buying "perl" and getting some bad "example" > code with it. > > Chris, et. al., drop me a note directly if you are interested in seeing what > magic I've done to the script and database schema. It doesn't take 5k per > user anymore; you can limit access for ISDN, MLPPP, X2/V.90, and > analog/digital call enforcement as well as the usual DNIS/ANI/portgroup > stuff. As for speed... using SA4.3.11 (143Mhz sparc 10 / solaris 2.5.1) + > postgres v6.3.2 (dual PII-300 / linux), the system could handle over 30 > authentication requests _per_ _second_. (Imagine what that would be if I > were to use Oracle or even flat files.) (BTW, SA4 will compile and run > perfectly under linux -- with one small change to the select() handling.) > > I will say this again: The script is designed for SA4. It can be dropped into > SA5 with minor modifications. If will not work for SA6 with extensive > changes. And, as hiper hardware didn't exist when I designed the script, > there is no specific handling for hiper hardware. > > IF there is interest, I can finish work already in progress in updating the > SA4 script for SA6 (with full hiper support.) > > If I still had access to the source code (and some access hardware), I could > do some beautiful things to that server... faster client auth checks, true > duplicate packet handling, full multithreaded processing... > > --Ricky > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Paul Oster wrote: > > Anyone know of a device that'll let me hook a modem up to it and > "switch" a dialin between numerious serial ports (which will be connected > to the above equipent) Something CHEAP would be preferable... any > suggestions? BayTech sells a out of band remote site management systems. Check out http://www.baytechdcd.com/product_cat.html#3 You might want to look for an old PM2 used, probably can get one for a few hundred dollars. It will use up more space in a rack than the BayTech box, but might cost less. -Ron GLISnet, Inc. +1 810/939.9885

> Jeff Mcadams said once upon a time: > No please, buy my 32 port Xylogics Annex 3. I'll sell it to you CHEAP!! We've got both a 64 port annex 3 and a 72 port annex 4 as well. Not super-duper cheap, but pretty cheap. All cables, recent SW. Did you know each octupus cable cost $100 way back when??? Actually, we've got lots of old stuff for sale... I know this isn't the right forum, but other than usenet, where's a good place to sell ISP-like equipment? Thanks, Charles > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Tue, 16 Mar 1999, Charles Sprickman wrote: >Actually, we've got lots of old stuff for sale... I know this isn't the >right forum, but other than usenet, where's a good place to sell ISP-like >equipment? <grin> Start a museum. (I've got enough junk in the warehouse^Wapartment to build a small computer evolution museum.) --Ricky

I had that error once. Are you importing accounting information? If so, I would uncheck that box in the appropriate window. One other problem I ran in to with 6.0.9 is our two session users would not get logged in. Strange thing is I didn't even see them hitting the hub via "mon ppp" or "mon radius". After I changed the "maximum number of concurrent sessions" from 2 to 0 they got right in. (a two channel ISDN user). blake > -----Original Message----- > From: Rick [mailto:rickyz@mindspring.com] > Sent: Tuesday, March 16, 1999 5:54 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) 3Com Security and Accounting upgrade from 6.0.8 to > 6.0.90 > > > I did a test install of 6.0.9. It installs to a different > directory from > the previous 6.0.8 -- c:\3comsuite vs. c:\usrsuite. If > c:\usrsuite exists, > the installation routine apparently renames (or copies) the existing > usradius.mdb to old.mdb in preparation for importing the records. > > There is a database import utility under Server Setup / > Advanced Options / > Database Maintenance. There are options for importing from > various other > versions, including 6.0.8. > > So far, so good. > > However, when I try to import the database, I get the following error > message: > > 3COM Security and Accounting Database Manager can't append > all the records > in the append query. > 3COM Security and Accounting Database Manager set 0 > field(s) to Null > due to a type > conversion failure, and it didn't add 3476 record(s) to > the table due > to key violations, 0 > record(s) due to lock violations, and 0 record(s) due to > validation > rule violations. > Do you want to run the action query anyway? > To ignore the error(s) and run the query, click Yes. > For an explanation of the causes of the violations, click Help. > > If I tell it to continue on with the import, I get several more error > messages, then when I check the users database, there are > only about 200 > records. > > What do I need to do to get this straightened out? > > ricky@mindspring.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. >

I did a test install of 6.0.9. It installs to a different directory from the previous 6.0.8 -- c:\3comsuite vs. c:\usrsuite. If c:\usrsuite exists, the installation routine apparently renames (or copies) the existing usradius.mdb to old.mdb in preparation for importing the records. There is a database import utility under Server Setup / Advanced Options / Database Maintenance. There are options for importing from various other versions, including 6.0.8. So far, so good. However, when I try to import the database, I get the following error message: 3COM Security and Accounting Database Manager can't append all the records in the append query. 3COM Security and Accounting Database Manager set 0 field(s) to Null due to a type conversion failure, and it didn't add 3476 record(s) to the table due to key violations, 0 record(s) due to lock violations, and 0 record(s) due to validation rule violations. Do you want to run the action query anyway? To ignore the error(s) and run the query, click Yes. For an explanation of the causes of the violations, click Help. If I tell it to continue on with the import, I get several more error messages, then when I check the users database, there are only about 200 records. What do I need to do to get this straightened out? ricky@mindspring.com

Me tooo..... Get the hubs cards, but no LIGHTS! I do get the Hub name in the NMC! 8-) ============================================================================== 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, 16 Mar 1999, Randy Cosby wrote: > What version of NMC are you using? I'm getting the card names/types right, > but no lights. > > Randy > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stephen Amadei > > Sent: Tuesday, March 16, 1999 3:47 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) My latest toy TC script... > > > > > > > > A couple of days ago, I was inquiring about the LED status on the USR's... > > I'd like to thank everyone who responded, and as I promised, I am sharing > > the fruits of my labor... > > > > Someone else has probably already done this, but since I couldn't find any > > code like it, I wrote my own... > > > > A "Total Control Virtual Display Program" What this does is create > > Gif files that represent your TC units. This is an early edition... I > > plan on prettying it up later, but it's mostly functional now, but I need > > to write a few other useless toys for my company. ;-) > > > > Some limitations: > > > > - It creates FOUR gif files for each of your Total Controls. This is in > > order to create an animated Gif file in the future, to provide for > > blinking LEDs. Disregard the extra GIFs. > > - It does not support the NetServer... I didn't have one handy when I > > built this... if someone gives me readonly access to a NetServer > > equipped TC, I will add it. > > - It does support the T1 card, Digital Quads, Analog Quads, D-A Quads, > > Hiper DSP, Hiper ARC, NMC and NMC with clock. For added cards, see > > note above about NetServer. > > - Requires CMU-SNMP, SNMPWALK, the GD library, GD perl library things and > > parts of MRTG. > > - It's absolutely not guarenteed to work anywhere... ;-) > > > > If you are feeling lucky, you can get the script at > > http://www.dandy.net/~amadei/tcview > > and see a live demo at > > http://www.dandy.net/statistics/tc.html > > > > Let me know what you think, and any suggestions. > > > > ----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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Just trying to find out how all of you are dealing with the ARC only being able to do RIP (4.1.x). We take in RIP at our router, and redistribute via OSPF.........is this what alot of you do, or do you do something else? I am setting up some POPs with total controls that are tied back to our main site via serial links (t1's). My plan is to redistribute rip into ospf and get it back to our main router. I thought of just distributing it via rip, but wasn't having much luck. Since its going over a serial link, I would have to use "neighbor" in my rip statment etc, and I don't like how I can't just delcare a "network a.b.c.d mask a.b.c.d" and how you have to just use a classfull mask. If someone who has some pops connected via RIP and/or OSPF could post their config (for just the router rip/router ospf) that would be great. Also tell me ip of router and arc. Shouldn't something like this work for say a RIP only config: Main Router (208.206.76.1/24) ============================== router rip version 2 timers basic 30 30 2 60 300 network 208.206.76.0 no auto-summary neighbor 208.242.79.1 neighbor 208.242.79.16 POP 1 (208.242.79.1/28) ======================= router rip version 2 timers basic 30 30 2 60 300 network 208.242.79.0 no auto-summary neighbor 208.206.76.1 POP 3 (208.242.79.16/28) ======================== router rip version 2 timers basic 30 30 2 60 300 network 208.242.79.0 no auto-summary neighbor 208.206.76.1 A few questions: 1. ip directed broadcasts would have to be "enabled" (not disabled) for RIP information to cross the serial links? 2. The pops are just /28's because thats just for the switch, arc's, router eth interface. The IP pools are seperate /24's that will be routed to those pops. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Hi, way back with Quads it was sometimes needed to change country codes on modems. What about HDM's? How can you change that on HDM? ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ----------------------------------------------------------------------

Once upon a time Ray Bellis shaped the electrons to say... >simple pluggable extensions which can be chained together to provide >sophisticated authentication and accounting mechanisms. > >I've already used the API to implement > >o Access control based on DNIS and JDBC >o GRIC roaming proxy >o Unix password authentication (uses JNI to access getpwnam) >o JDBC password authentication >o JDBC attribute setting >o JDBC accounting > >I'd be interested in getting feedback from other RADIUS users on >whether an easily extensible RADIUS server would have any demand >(commercial or otherwise). Seeing as Lucent currently markets *2* extensible 100% Java RADIUS servers - RADIUS ABM and Port Authority (though they are merging them into one server with the features of both, keeping the PA name (it goes with PM)) - I think you could safely assume the answer is *yes*. Radiator is also extremely popular because it is extremely easy to extend - being all Perl. (And it performs well too - especially if you pre-compile it with the Perl Compiler.) -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Sam Lowe shaped the electrons to say... >Do any of you fine list members know what the attribute codes 38978 & 38979 refer to. I suspect they have something to do with the HIPER cards, but can't find this info anywhere. Sounds like a couple of VSAs: ATTRIB_NMC USR-Modem-Training-Time 0x9842 integer ATTRIB_NMC USR-Interface-Index 0x9843 integer -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Thus spake Brian >We take in RIP at our router, and redistribute via OSPF.........is this >what alot of you do, or do you do something else? I think that's pretty much standard procedure. :) >I am setting up some POPs with total controls that are tied back to our >main site via serial links (t1's). My plan is to redistribute rip into >ospf and get it back to our main router. >I thought of just distributing it via rip, but wasn't having much luck. >Since its going over a serial link, I would have to use "neighbor" in my >rip statment etc, and I don't like how I can't just delcare a "network >a.b.c.d mask a.b.c.d" and how you have to just use a classfull mask. Nope, and nope. You can use a network statement for serial links. Assuming you've assigned /30's to your serial links, you can just put a network statement on there for that /30, works like a charm. As far as the mask. It doesn't have to be classful for RIPv2. Keep in mind that its a wildcard mask, not a netmask...in other word, invert all your bits. Personally, I just assign all of our /30's for our internal t1's out of the same /24, and since I run OSPF across all of them, just put the network statement in the OSPF config for the whole /24. That way if I add a t1 to a POP (one of our POPs just got a second t1 back to the main city) I don't have to remember to add another network statement for it. The previous network statement for the /24 covers it already. >A few questions: >1. ip directed broadcasts would have to be "enabled" (not disabled) for >RIP information to cross the serial links? Nope, RIP uses direct broadcasts, it never directs it. RIP only advertises information hop by hop, it never directed broadcasts routing information to a remote network broadcast's address (ref. my recent posting about classless routing as to why it really isn't feasible for it to know what the remote broadcast addresses really are) >2. The pops are just /28's because thats just for the switch, arc's, >router eth interface. The IP pools are seperate /24's that will be routed >to those pops. Should work fine. If the NETServers/Arcs will be advertising the /24's to the Cisco's, the Cisco's will pass on that routing information, no problem. You could do the whole thing using just RIP if you want...that's how I started out with us, advertising everything all the way around with RIP, eventually switched over to OSPF since RIP just really doesn't scale very well. The transition was actually not too bad with some careful route-maps. Was actually done gradually (over the course of a whole day) without any loss of service in the process. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Once upon a time Jamie Orzechowski shaped the electrons to say... >here is my DEFAULT radius user > >DEFAULT Authentication-Type= Unix-PW, Framed-Protocol= PPP, >Simultaneous-use= 2 Looks like Merit - correct? First off, you have Framed-Protocol as a Check Item, not a Reply Item. So it only matches PAP/CHAP users. Remove it as a Check Item and make it a Reply Item. As for Simultaneous-Use - well, that's non-standard, server specific so I don't know if you really want it as a Check Item (as you have it) or a Reply Item. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Paul Oster shaped the electrons to say... > Anyone know of a device that'll let me hook a modem up to it and >"switch" a dialin between numerious serial ports (which will be connected >to the above equipent) Something CHEAP would be preferable... any >suggestions? Aka a console server. PortMaster-2, PortMaster-25, Cisco 2511, Remote Annex 2000, etc, etc. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Pete Ashdown shaped the electrons to say... >No please, buy my 32 port Xylogics Annex 3. I'll sell it to you CHEAP!! What did Paul ever do to you to deserve such a fate? ;-) -MZ, who used to work for Xylo... -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Charles Sprickman shaped the electrons to say... >Actually, we've got lots of old stuff for sale... I know this isn't the >right forum, but other than usenet, where's a good place to sell ISP-like >equipment? isp-equipment@isp-equipment.com and isp-services@ispc.org And eBay of course. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

On Tue, 16 Mar 1999, Randy Cosby wrote: > What version of NMC are you using? I'm getting the card names/types right, > but no lights. I have two physical NMC's... one comes up as a "Network Management Card", and one comes up as a "Network Management Card with Clock"... both are running the lastest firmware, 5.5.5. Unless there is a difference in the locations of the LEDs MIBs, the NMC shouldn't matter. Anyway, I have posted a newer version that includes a debug feature. Edit the tcview file and set debug=1 on line 37. Run the script: "./tcview your.nmc.here.net yourcommunity test 2> output" and email me the output, and I will check to see what's going on. I have had _many_ reports that the cards are being drawn, but the LEDs are all coming in dark. At this point, I'm not sure if this is a hardware difference or a software difference, but I didn't see anthing like this with my equipment. ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Once upon a time Chris Hanes shaped the electrons to say... >As has been noted here before, the USR Radius server scarcely works. >I've been looking at alternatives - in particular Cistron, Merit, and >Radiator - and am looking for advice. What's the best bet in terms of >cost, performance, reliability, ease of maintenance, etc.? You can't beat the price on Cistron - it is free. And you get all of the source, so you can tweak it as you like. It includes simultaneous use controls for all the popular platforms, including 3Com, can call external programs during the auth process, can cascade entries, etc. And there are a number of SQL patches available. Cistron is becoming the focus of a growing open source RADIUS effort, lots of interesting things happening there. Radiator is probably the most bang for the buck - I believe pricing runs in the $600-$1000 range. It has a TON of features, and is all Perl so it is incredibly customizable. Now, some people think Perl means poor performance - bullshit. There are ISPs using Radiator ith tens of thousands of users. It is intepreted/compiled when you start it and once running it is in memory. If you want ever better performance you can pre-compile it with the Perl Compiler. Since it is Perl it can talk to most every database you could want. If you're on NT then IEA's RadiusNT is probably the best thing going. They were the first with an effecting NT RADIUS server, and they likely have the largest market share for RADIUS on NT. Nice product. At the 'high end' - in terms of performance, features, and price - are the major commercial servers such as Lucent's RADIUS ABM and Port Authority (both 100% Java, feature laden, high performance, with APIs for extensions), and Funk's Steel-Belted RADIUS. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Welp, I tested the plan outlined in previous threads, and have some excellent news. (: RECAP: The problem to be solved is having to tell customers who typically have lame modems [how] to turn off [some feature like v42bis] so they can connect to your ultracoolhightech gear. First, telling them that makes you sound lame. Second, for a high percentage of customers, the act of telling them how is, umm, problematic. The solution to it is simple on your HDSP (maybe quads too, I dunno about them), and makes you look like the ultracoolguru that you are. (: OVERVIEW: The idea is to have two different modem configurations: one is set up for maximum performance on modern modems with good code. 56k stuff and fancy compression and the like. The other configuration is designed to connect with anything...sacrificing some of the bells and whistles that freak out lame modems. You then get another number pointed to your huntgroup, and configure the modems differently based on what number the customer called. At that point, when a customer can't connect, you can just tell 'em to try the other number. HOWTO: Ensure that the telco is providing you with DNIS digits; use the performance monitor in TCM to see if they're coming in. If you don't see 'em or they don't look right, verify the setting of 'DNIS-Based Incoming Call Digits' in the modem and/or template configuration under the 'Call Control' group. If you are unsure of what to set it to, you can either experiment or call your telco and ask how many they send, whichever is easier in your circumstance. If you're on T1's instead of PRI's there's probably other configuration items that need verification, [mftones or dtmftones??] I don't know. Call your telco and get another phone number pointed to the head of your huntgroup. When they get around to doing it, give it a quick call while watching the modems' performance monitor and verify that the DNIS numbers are what you think they are. [I do my HDSP configuration via templates, so that's how I'll explain it] In TCM, select your HDSP cards and hit 'Configure'. Select the Template(s) you're using. Go to 'Call Control Options'. Scroll down and make sure that 'Call Init String' is set to 'enable', and 'ANI/DNIS Call Init Strings' is set to 'dnisBase'. Also note the 'DNIS-Based Incoming Call' value if you didn't do it in the first step above. Then go to the 'DNIS Access Codes' parameter group. For the 'DNIS Group 1' parameter, enter the DNIS number (as seen on your TCM Performance Monitor) for your newly added second phone number. For the 'DNIS Init String 1' parameter, enter in the AT command string which will switch the modem from your normal configuration to your connect-with-anything configuration (discussed below). Hit 'Ok'. Then go to 'Commands', select 'Software' and 'Refresh Template 1 Config Channels', and then hit 'Execute'. Close the window when you're done, and you're ready to test it. Fire up TCM's performance monitor. Call in to your rack using your normal phone number and note the stuff negiotiated. Then call in using the new phone number, and check again. If it works for you like it worked here, you'll see appropriate changes (my test string turned off compression and disabled x2 & v90....and I see that no compression gets negiotiated and 'x2 status' is 'x2v90disabledLocal'). Save everything to NVRAM and tell your tech support people the good news. (: THE INIT STRING: Here, I want to default to my max performance settings, so that's how I config everything in my templates and set the modems to by default. Since that's how the modem is set, my 'secondary' init string only has to reflect the differences, i.e. the turning off of various features. At the moment, I'm using 'AT&K0S27.3=1S76.1=1S81.5=1': &K0: turns off compression S27.3=1: turns off 2100Hz answer tone S76.1=1: turns off x2 S81.5=1: turns off v90 Any insight anyone can give regarding the 'perfect' string to use for this would be helpful. I'm sure there are other things that probably should be included here but just haven't played with it enough to find out. v42 Selective reject, maybe? Enjoy!!! Lon Stockton MoonStar

-> I had the exact same situation, except my modem cards were HiperDSPs. -> 3com support told me the same thing about users upgrading their winmodem -> software. Well, the Rockwell/Conexant HCF modems with older version driver are buggy and need update badly.... these modems are now being used by Compaq, IBM, HP, Sony, and many more vendors - in place of the much better (with updated firmware) Lucent LT.... See my HCF page at http://808hi.com/56k/rockhcf.htm and Lucent LT at http://808hi.com/56k/x2-lucent.htm There are getting to be so many versions of client and server firmware, combined with varying telco digital impairments, that in some ways 56k connectivity is getting worse, not better. Some 3Com client versions are having trouble with some 3Com server versions! And 3Com doesn't make it easy if the customer 'upgrades' their firmware and 'downgrades' their connection. V.90 Interoperability status - http://808hi.com/56k/x2-interop.htm New Pages & Recent updates at the 56k=v.Unreliable site http://808hi.com/56k/ [mirrored at http://808news.com/56k] Rockwell/Conexant HCF modems info- http://808hi.com/56k/rockhcf.htm The Main Troubleshooting Page has been updated with a section on frequent disconnects, and the list of ISP access numbers has been updated to reflect the type of server modem used by the ISP. http://808hi.com/56k/r-rnut-x2-3.htm - Main Troubleshooting Page What's a 56k-compatible line? - http://808hi.com/56k/56kline.htm Modems & Call Waiting - http://808hi.com/56k/callwait.htm RBS & 56k update - http://808hi.com/56k/rbs2.htm Inexpensive, Decent 56k modems - http://808hi.com/56k/buy56k.htm Useful Links - http://808hi.com/56k/links.htm How to Flashback 3Com/USR modems - http://808hi.com/56k/flashback.htm 56k TROUBLESHOOTING - Check Your Throughput - http://808hi.com/56k/x2-thru.htm Limiting Your Connect Speed - http://808hi.com/56k/x2-linklimit.htm Who Manufactured Your Modem? - http://808hi.com/56k/whomadeit.htm 3Com Diagnostic Screens - http://808hi.com/56k/diag3com.htm If you get 115.2k connects - http://808hi.com/56k/x2-inf1.htm LUCENT LT Winmodem / latest driver/firmware http://808hi.com/56k/x2-lucent.htm NEWS & UPDATES - http://808hi.com/56k/news.htm LATEST UPDATES - http://808hi.com/56k/latest.htm Why 56k=v.Unreliable - http://808hi.com/56k/why56kis.htm From the guestbook - http://808hi.com/56k/guestbook.htm "AWESOME site...." "Your page on limiting connection speed put me on the right track..." "When you are totally frustrated this is a great place to go see that you aren't alone!!!" "This site was very helpful to me, in finding out about my Rockwell HCF 56k PCI modem. I located my modem, and the newest upgrade driver, downloaded and installed it. It is now working great. Thanks." "Excellent page. I am the administrator for a regional cable/dialup ISP and this is one of the most informative pages on 56k I have ever read. I have gleaned much more useful information from your pages in 30 minutes than I have ever received from 3Com (and that's having direct access to one of their SE's). Thanks!" Note - my site is copyrighted; many ISP help pages link to one or more of my pages - no permission is needed to do this; however, if you want to COPY info & place on your site, you need to get my permission. Thanks. Aloha, Richard

On Wed, 17 Mar 1999, Jeff Mcadams wrote: > Thus spake Brian > >We take in RIP at our router, and redistribute via OSPF.........is this > >what alot of you do, or do you do something else? > > I think that's pretty much standard procedure. :) > > >I am setting up some POPs with total controls that are tied back to our > >main site via serial links (t1's). My plan is to redistribute rip into > >ospf and get it back to our main router. > > >I thought of just distributing it via rip, but wasn't having much luck. > >Since its going over a serial link, I would have to use "neighbor" in my > >rip statment etc, and I don't like how I can't just delcare a "network > >a.b.c.d mask a.b.c.d" and how you have to just use a classfull mask. > > Nope, and nope. You can use a network statement for serial links. > Assuming you've assigned /30's to your serial links, you can just put a > network statement on there for that /30, works like a charm. As far as But I don't assign 30's, I use ip unnumbered..........can RIP broadcasts traverse an ip unnumbered link without a neighbor statment? > the mask. It doesn't have to be classful for RIPv2. Keep in mind that > its a wildcard mask, not a netmask...in other word, invert all your bits. > Personally, I just assign all of our /30's for our internal t1's out of > the same /24, and since I run OSPF across all of them, just put the > network statement in the OSPF config for the whole /24. That way if I > add a t1 to a POP (one of our POPs just got a second t1 back to the main > city) I don't have to remember to add another network statement for it. > The previous network statement for the /24 covers it already. nod. > > >A few questions: > > >1. ip directed broadcasts would have to be "enabled" (not disabled) for > >RIP information to cross the serial links? > > Nope, RIP uses direct broadcasts, it never directs it. RIP only > advertises information hop by hop, it never directed broadcasts routing > information to a remote network broadcast's address (ref. my recent > posting about classless routing as to why it really isn't feasible for > it to know what the remote broadcast addresses really are) I thought that using the "neighbor" statment in a RIP config forced a directed broadcast. > >2. The pops are just /28's because thats just for the switch, arc's, > >router eth interface. The IP pools are seperate /24's that will be routed > >to those pops. > > Should work fine. If the NETServers/Arcs will be advertising the /24's > to the Cisco's, the Cisco's will pass on that routing information, no > problem. > > You could do the whole thing using just RIP if you want...that's how I > started out with us, advertising everything all the way around with RIP, > eventually switched over to OSPF since RIP just really doesn't scale > very well. The transition was actually not too bad with some careful > route-maps. Was actually done gradually (over the course of a whole > day) without any loss of service in the process. Brian > -- > 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)

> Nope, and nope. You can use a network statement for serial links. > Assuming you've assigned /30's to your serial links, you can just put a > network statement on there for that /30, works like a charm. As far as > the mask. It doesn't have to be classful for RIPv2. Keep in mind that > its a wildcard mask, not a netmask...in other word, invert all your bits. > Personally, I just assign all of our /30's for our internal t1's out of > the same /24, and since I run OSPF across all of them, just put the > network statement in the OSPF config for the whole /24. That way if I > add a t1 to a POP (one of our POPs just got a second t1 back to the main > city) I don't have to remember to add another network statement for it. > The previous network statement for the /24 covers it already. > What do you think about using 192.168.x.x space for the /30's? Do you think that is a good idea? I am considering using like 192.168.1.0/24 and assign all the serial /30's from that, then I can just do "network 192.168.1.0 mask 0.0.0.255" and get everything talking. > You could do the whole thing using just RIP if you want...that's how I > started out with us, advertising everything all the way around with RIP, > eventually switched over to OSPF since RIP just really doesn't scale > very well. The transition was actually not too bad with some careful > route-maps. Was actually done gradually (over the course of a whole > day) without any loss of service in the process. hmm, going from unnumberd to numbered shouldn't you be able to do, on a live link: int sX/X ip address 192.168.1.5 255.255.255.252 no ip unnumbered eX/X exit or is their more to defusing the situation :)? Brian > -- > 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)

Paul Oster wrote: > > umm, well, my call with 3com seems to have solved this, they told me not > to set MTU in radius.... Who do I call to make this into an official bug > report. > > Paul M. Oster <devious@minot.com> http://www.minot.com/ > Magic Internet Services (701) 838-1265 > Minots FIRST Internet Connection > Dealt with something like this before, but not TC related. I'll assume that you were setting the MTU at lower then 1500. Anyways, I'm not sure about the first two sites, but many sites on the net block ICMP from entering into their network. Anyways, any sites that have this implemented (Microsoft is another one) will fail to communicate if the size of the file is larger the the size of the MTU. ICMP is involved in the process of reducing the size of the packets. I believe the type is ICMP_UNREACH_NEEDFRAG, anyways, since certain sites which are no less running incredibly secure servers have decided to block ICMP, we can't adjust MTU anymore. Erik.

Oops...looks like I left out an obvious step.... On Wed, 17 Mar 1999, Lon R. Stockton, Jr. wrote: > [...] > Then go to the 'DNIS Access Codes' parameter group. For the 'DNIS > Group 1' parameter, enter the DNIS number (as seen on your TCM > Performance Monitor) for your newly added second phone number. For > the 'DNIS Init String 1' parameter, enter in the AT command string > which will switch the modem from your normal configuration to your > connect-with-anything configuration (discussed below). After this, enter the AT command string that reverses the stuff you did in the other string in the 'DNIS Default String'. > At the moment, I'm using 'AT&K0S27.3=1S76.1=1S81.5=1' And my DNIS Default String is 'AT&K3S27.3=0S76.1=0S81.5=0' Lon Stockton MoonStar

Hi Country codes setting for the HDM are only applicable to version 2.0. x code which is in Beta, We have kept the same command settings with the DSP as was used with the Quad. The only difference is one command changes will change all the modems on the DSP as for the Quad you had to access each modem. Ray Whelan Net Sys Dublin "Andres Kroonmaa" <andre@ml.ee> on 16/03/99 22:28:47 Please respond to usr-tc@lists.xmission.com cc: (Ray Whelan/IE/3Com) Hi, way back with Quads it was sometimes needed to change country codes on modems. What about HDM's? How can you change that on HDM? ---------------------------------------------------------------------- Andres Kroonmaa mail: andre@online.ee Network Manager Organization: MicroLink Online Tel: 6308 909 Tallinn, Sakala 19 Pho: +372 6308 909 Estonia, EE0001 http://www.online.ee Fax: +372 6308 901 ---------------------------------------------------------------------- - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Speaking of Radius what is the optimal configuration for a user in radius for a default user for hiper dsp/arc dialin user? Thanks, Brian Gordon, MCP, A+ Network Administrator Westelcom Internet 518-566-8376 Voice 518-566-8348 Fax http://home.westelcom.com administrator@westelcom.com ----- Original Message ----- Sent: Wednesday, March 17, 1999 4:23 AM >Once upon a time Ray Bellis shaped the electrons to say... >>simple pluggable extensions which can be chained together to provide >>sophisticated authentication and accounting mechanisms. >> >>I've already used the API to implement >> >>o Access control based on DNIS and JDBC >>o GRIC roaming proxy >>o Unix password authentication (uses JNI to access getpwnam) >>o JDBC password authentication >>o JDBC attribute setting >>o JDBC accounting >> >>I'd be interested in getting feedback from other RADIUS users on >>whether an easily extensible RADIUS server would have any demand >>(commercial or otherwise). > >Seeing as Lucent currently markets *2* extensible 100% Java RADIUS servers - >RADIUS ABM and Port Authority (though they are merging them into one server >with the features of both, keeping the PA name (it goes with PM)) - I think >you could safely assume the answer is *yes*. > >Radiator is also extremely popular because it is extremely easy to extend - >being all Perl. (And it performs well too - especially if you pre-compile >it with the Perl Compiler.) > >-MZ >-- >-=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- ><URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. >Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> >"A little nonsense now and then, is relished by the wisest men" 781-788-0130 ><URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia! > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Brian >On Wed, 17 Mar 1999, Jeff Mcadams wrote: >> Nope, and nope. You can use a network statement for serial links. >> Assuming you've assigned /30's to your serial links, you can just put a >> network statement on there for that /30, works like a charm. As far as >But I don't assign 30's, I use ip unnumbered..........can RIP broadcasts >traverse an ip unnumbered link without a neighbor statment? with IP unnumbered, you may be correct. >I thought that using the "neighbor" statment in a RIP config forced a >directed broadcast. Nope, I don't believe so. I believe the neighbor statement makes it get sent as a unicast to that IP address rather than any type of broadcast. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Brian <signal@shreve.net> writes: > We take in RIP at our router, and redistribute via OSPF.........is this > what alot of you do, or do you do something else? For our setup, we only use RIP (v1 at that still on the NETServers) at the fringes in order to get the "next hop" right between our Cisco border routers and the appropriate NETServer/HiperARC. We don't redistribute the RIP announcements dynamically beyond that point. Our overall addressing plan is pre-allocated amongst our sites globally, and the appropriate address prefix is configured into each border Cisco as a static route to Null0. This static information is then redistributed into both OSPF and BGP for backbone routing purposes. This configuration has a key advantage that we don't flap routes within the core just as the first user in a given prefix comes on or off, which at a large scale can be a problem. It also means that routes within the core are always aggregated (while the ARC may do it, our NETServers announce individual /32s for the dialup users), and they can then be aggregated even further the next level up (the POP) since they were initially allocated just for that purpose. Within the backbone, dialup prefixes are always live, and can be traced to the site from which they are announced with or without users online. The static route to Null0 on the border Cisco just drops such packets on the floor once they reach the Cisco if there is no user actually online with the specific target address. It also avoids any issues with the redistribution of RIP into any other protocol, since RIP is soley used on the final ethernet leg. We can also turn down the RIP timers to almost nothing to remove any problems with address reuse (next hop changing quickly as someone gets off and a new user on a different box gets the same address) since such a timer change does not affect the backbone proper. On the "con" side, this configuration requires somewhat more configuration (not so much during initial install as during later maintenance/modification), and it also does have a disadvantage that except in special cases, address space is not mobile at all - dynamically assigned within a site, but not across the backbone. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

I had the exact same situation, except my modem cards were HiperDSPs. 3com support told me the same thing about users upgrading their winmodem software. Not really feasible with ~2500 inexperienced users. We had channelized T1s with line-side termination. Found out that exceeds the v.90 requirement for digital-to-analog conversions. If they were trunk side terminations we might have been OK. Anyway, we got a good deal from Bell for the line screwup, and we put in PRIs. Things have been great since. Check with your carrier about your exact line build, and I recommend PRIs if available, fast & and digital helps a lot with 56k. Scott Boggs IS Manager United Bank Zebulon Georgia > -----Original Message----- > From: R. Ferguson [SMTP:cygnus@vsta.com] > Sent: Tuesday, March 16, 1999 1:49 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) disconnect problems > > Hello Everyone, > I'm new to this list but from the few days i've been on it looks like > someone here might have the answer i need. > I have 3 TC chassis with the configuration shown below. I have been > having > a problem with customers calling up and getting dropped immediately. Some > users finish the handshake and get disconnected during authentication > others never get past the handshake stage many users report messages > saying "error 631" or "a connection could not be established please check > you network configuration and try again" (something like that). Anyways > the people complaining have been long standing customers who have never > reported trouble then suddenly about a month ago everyone started having > this trouble(about the time i put in a usr update). The only real pattern > i > see is that it mostly affects Kflex users and V.90 users and users with > pc's(Compaq and Gateway) less that 3 months old. USR support told me to > update the code to the version you see listed below and that all the V.90 > problems would be resolved. I saw no difference with the new code except > that WebTv users work great now. I have managed to get the real angry > customers back online by turning off 56k/v.90 in thier modems with an init > string but it's not a real solution because the problem is still there. > Is anyone else seeing this problem? Is there a known bug with V.90/56k? > Can > anyone give me some advice on resolving this problem.....The USRTechs i > have spoken with say that my customers have to go get thier modems updated > to the latest code. Some of my customers have tried doing this and they > are > told by their vendors that there code is solid and their ISP (me) is the > one with the problem.... > any help or adice will be greatly appreciated > Rudy Ferguson > cygnus@vsta.com > > > > 1 3COM DUAL T1 NAC BBB6NZTY 11C 3.0.0 512 512 > 0000000000000101 3.5.0 > 2 3COM Quad V.34 Digital Modem NAC BCI6XI90 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 3 3COM Quad V.34 Digital Modem NAC BCF6WXM6 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 4 3COM Quad V.34 Digital Modem NAC BCL6Y9MA 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 5 3COM Quad V.34 Digital Modem NAC BCG6X1OR 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 6 3COM Quad V.34 Digital Modem NAC BCE6WRHG 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 7 3COM Quad V.34 Digital Modem NAC BCI6XIG5 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 8 3COM Quad V.34 Digital Modem NAC BCI6XI8M 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 9 3COM Quad V.34 Digital Modem NAC BCG6X1UB 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 10 3COM Quad V.34 Digital Modem NAC BCL6Y9NM 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 11 3COM Quad V.34 Digital Modem NAC BCG6X1OL 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 12 3COM Quad V.34 Digital Modem NAC BCG6X1KL 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 13 3COM Quad V.34 Digital Modem NAC BCH6XGZI 19U000 > 2.0.0 0 0 > 0000000110001000 5.10.9 > 14 3COM High-Density 24 Channel NAC BC77B0TF 1OQ > 0.49.0 8192 2048 > 0000000000000000 1.2.59 > 15 3COM High-Density 24 Channel NAC B1C8DPRE 1OQ > 0.49.0 8192 2048 > 0000000000000000 1.2.59 > 16 3COM HiPer ARC NAC B648VNPZ 20C 19.0.0 65536 8192 > 0000000000000000 4.1.59 > 17 3COM Network Management Card with clock BCI6XJ5M 11I00000 > 3.0 20480 8192 > 0000000000000000 5.5.5 > 1 3COM Bellcore Approved Long Haul Dual T1 NIC > 512 512 0000000000000101 > 14 3COM T1/E1 HDM NIC 8192 2048 > 0000000000000000 > 15 3COM T1/E1 HDM NIC 8192 2048 > 0000000000000000 > 16 3COM Dual 10/100 Ethernet NIC - PCI based > 65536 8192 0000000000000000 > 17 3COM Ethernet NIC ???????? ?? 0 0 > 0000000000000000 > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

I need a pair of brackets to rackmount a netserver 16. Thanks.... tony

I am working to implementing a dedicated modem from a DSP card. The modem would be free from the hunt group on the T1. I was curious if someone had a clue on how to configure the DSP or ARC card for this feature. I have read through several pages of manuals, but this feature is not mentioned. At least I have not come across it. I am running the following software versions: NMC 5.5.5 ARC 4.1.59 DSP 1.2.59 Scott Childers Network Systems Manager SEI Data Network Services http://www.seidata.com VenusNet http://www.venus.net

I currently have a call in to the telco to see if they assign a POTS number to a single channel and make it separate from the POTS number assigned to the rest of the channels. They're quite sure they can but they have yet to get back to me. I think that would effectively accomplish what you're trying to do without having to bugger with the DSP configuration. On Wednesday, March 17, 1999 3:56 PM, Network Administrator [SMTP:netadmin@seidata.com] wrote: > > I am working to implementing a dedicated modem from a DSP card. The modem > would be free from the hunt group on the T1. I was curious if someone had a > clue on how to configure the DSP or ARC card for this feature. I have read > through several pages of manuals, but this feature is not mentioned. At > least I have not come across it. I am running the following software > versions: > NMC 5.5.5 > ARC 4.1.59 > DSP 1.2.59 > > > Scott Childers > Network Systems Manager > SEI Data Network Services > http://www.seidata.com > VenusNet > http://www.venus.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.

Thanks Blake...I'll check that. RickyZ -----Original Message----- Sent: Tuesday, March 16, 1999 7:16 PM I had that error once. Are you importing accounting information? If so, I would uncheck that box in the appropriate window. One other problem I ran in to with 6.0.9 is our two session users would not get logged in. Strange thing is I didn't even see them hitting the hub via "mon ppp" or "mon radius". After I changed the "maximum number of concurrent sessions" from 2 to 0 they got right in. (a two channel ISDN user). blake > -----Original Message----- > From: Rick [mailto:rickyz@mindspring.com] > Sent: Tuesday, March 16, 1999 5:54 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) 3Com Security and Accounting upgrade from 6.0.8 to > 6.0.90 > > > I did a test install of 6.0.9. It installs to a different > directory from > the previous 6.0.8 -- c:\3comsuite vs. c:\usrsuite. If > c:\usrsuite exists, > the installation routine apparently renames (or copies) the existing > usradius.mdb to old.mdb in preparation for importing the records. > > There is a database import utility under Server Setup / > Advanced Options / > Database Maintenance. There are options for importing from > various other > versions, including 6.0.8. > > So far, so good. > > However, when I try to import the database, I get the following error > message: > > 3COM Security and Accounting Database Manager can't append > all the records > in the append query. > 3COM Security and Accounting Database Manager set 0 > field(s) to Null > due to a type > conversion failure, and it didn't add 3476 record(s) to > the table due > to key violations, 0 > record(s) due to lock violations, and 0 record(s) due to > validation > rule violations. > Do you want to run the action query anyway? > To ignore the error(s) and run the query, click Yes. > For an explanation of the causes of the violations, click Help. > > If I tell it to continue on with the import, I get several more error > messages, then when I check the users database, there are > only about 200 > records. > > What do I need to do to get this straightened out? > > ricky@mindspring.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. begin 600 WINMAIL.DAT M>)\^(@L,`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <` M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`````@`"``$$ MD 8`T $```$````0`````P``, (````+``\.``````(!_P\!````40`````` M``"!*Q^DOJ,0&9UN`-T!#U0"`````'5S<BUT8T!L:7-T<RYX;6ES<VEO;BYC M;VT`4TU44 !U<W(M=&- ;&ES=',N>&UI<W-I;VXN8V]M`````!X``C !```` M!0```%--5% `````'@`#, $````:````=7-R+71C0&QI<W1S+GAM:7-S:6]N M+F-O;0````,`%0P!`````P#^#P8````>``$P`0```!P````G=7-R+71C0&QI M<W1S+GAM:7-S:6]N+F-O;2<``@$+, $````?````4TU44#I54U(M5$- 3$E3 M5%,N6$U)4U-)3TXN0T]-```#```Y``````L`0#H!````'@#V7P$````:```` M=7-R+71C0&QI<W1S+GAM:7-S:6]N+F-O;0````(!]U\!````40````````"! M*Q^DOJ,0&9UN`-T!#U0"`````'5S<BUT8T!L:7-T<RYX;6ES<VEO;BYC;VT` M4TU44 !U<W(M=&- ;&ES=',N>&UI<W-I;VXN8V]M``````,`_5\!`````P#_ M7P`````"`?8/`0````0````````"^6@!!( !`$<```!213H@*'5S<BUT8RD@ M,T-O;2!396-U<FET>2!A;F0@06-C;W5N=&EN9R!U<&=R861E(&9R;VT@-BXP M+C@@=&\@-BXP+CDP`$P6`06 `P`.````SP<#`!(`!P`T``,`! `M`0$@@ ,` M#@```,\'`P`2``<`,P`F``0`3P$!"8 !`"$```!!1#<U138W-S V1$1$,C$Q M.#0Q130T-#4U,S4T,# P, #D!@$#D 8`Z H``"$````+``(``0````L`(P`` M`````P`F```````+`"D```````,`+@```````P`V``````! `#D`(!?"'CYQ MO@$>`' ``0```$<```!213H@*'5S<BUT8RD@,T-O;2!396-U<FET>2!A;F0@ M06-C;W5N=&EN9R!U<&=R861E(&9R;VT@-BXP+C@@=&\@-BXP+CDP```"`7$` M`0```!8````!OG$^'L)WYG6NW081TH0>1$535 `````>`!X,`0````4```!3 M3510`````!X`'PP!````%@```')I8VMY>D!M:6YD<W!R:6YG+F-O;0````,` M!A!IV@7H`P`'$)X(```>``@0`0```&4```!42$%.2U-"3$%+14E,3$-(14-+ M5$A!5%))0TM96BTM+2TM3U))1TE.04Q-15-304=%+2TM+2U&4D]-.D),04M% M1DE42$5.4TU44#I&251(14Y 3D545T]22U-03%530T]-4T5.``````(!"1 ! M````F@<``)8'``!'#@``3%I&=5RPL*!W``H!`P'W( *D`^,"`&.": K <V5T M," '$X<"@P!0#O9P<G$R#_8F?0J ",@@.PEO,C5F-0* "H%U8P!0"P-C`P!! M"V!N9S$P,S-)"Z8@5 ^ ;FL$($(1"V!K92X7($DG;$<#( ]P!9!K('0/@'1. M+@JB"H0*@%)I%]!YAEH86@KT;&DS-@% IQ40`4 10&]T!9!T$(10,38@+1PR M3P409P\+@ = != 'D'-A9V4_'#,85AM$&Q$+$QM&:2T8,30T`4 :D#$X,$<! M0 S0']-B($8#83K=#(-B#^ 6TR$0:1@`"?" (%M33510.A^@92)R0 ? ='<% ML!:@4,D*0',N!:!M71A5(0`7!F ","%G5 I0<V1AW'DL!= *P ]P(!P`)G!$ M,3DG0" W.AP!4%)-)*=4;R%G)R0P<I M=&- &I!S="1 M'AM! %I`B D4B<D MJ!AU8FH;<2%G4D4Z1" H*40I(#,(4&U%!E%C"'%T>2 `<&0U#_!C!:!U`C + M@&<@5'5P"<!A`0`@`U(@H#8N,"XX%_!O+]-^.1ZS'A\;-AJ4"[888TGN( ^ M+D 8`B $D -@!<"U`B!C%Q @#_$B,'D(8/H@!W!P"1$NT@#0+H<+@%T"$'(` MP"[ `B _,W5F."!S;R9P,] CP'5LURY +J 7J" &X'@W$1?Q^2(P87 ;,1% M!S ;8#C D0N 9&]W-2%/;B(POQA4&U 7L 7 &S$"8&4M</\ST"] `Z Z0C!0 M`_ 8`#!D_S7 !" (81?P(\ X8!TA*F%?+P`/L ^@&%0XU&X;4"#W'6 %0 D` M9QU@+D +@#4A_%-T/:$=8!?Q-N,$(#/0H&1I9&XG-&%V(I'_#[!"TCU0&%1# M``) +M(Z<I)H*X @=@<P("($8/,#H#K <"(TT 7 1H,O0?II)# B-2(!@#S1 M,] /<9M"L30291A41H!A> =PJG4M<&Y*,&(\T6\X4/\%H#3P"' )< (P/Y9' M\"^$WQ%P,$$/X")Q+@!G04$<D>YH&Y 88T(B*$9@/V)(PD,\$ ,@25-$3D 3 M*>\82P)@%O$86CX<+QT^4@"_(2,'\!DA(K 5`SCP( # FP,0,$ Z!1 9,7I M*B#]+C!S.P$5<"12&N,X\ _@'R254@`E,R7_)P8U.C7^-"?'4@`H@4 1*6\J M=%?G_RN%+*\MOR[/+]=1IC!Z4@#_8JY#@U]P%_ 'D 5 "X IT-\'0 ,@2M$P M<S4A2637!"#_,$%&8$.@`2 $D$MR4:9#H/\)<!N !;!?8"^34:8Z<A% ?T00 M*F D,"_54B 7D"%@7+(S)&%S=2)@(C!V)$#_:Q-;<6NC9?(X4%&F;$HT</]* M`"G163!I2F3U-X,]D A@;V A.I,*P"5!;%]@2V%AK0>"* 6Q!:!P")!S7H _ M.G)NLV R4:9;<4>S+FWN9"$`,$$&\&1U`SI!:@'_"K%P9#=!-<DZ<FAQ!;!6 MD/\816,(%F!G<3[B9Q$8( &@_F$/L#7%8&!@(!J07U%@`"\$@0921"!\`G1@ M<" O<6,7061V`' U`%^@3_<%,$OR?.E$>E8FD N &V#_4L T]'F4<7$TT'XU M=OQH^_]]L 40:E(\I(,'0$%+\EDP?0N 8PI 0Z!@02_C>(]3_3!09@K 63 X M<$U1!'"&?^Y(.[!$$8?1=R*",]!"@/]?8#!!>M4Z<GI&.))!<CIR_P(0%W [ ML& R-(11I@>!'4+G(6!BO5Z@3TU>[U_V?TG_4L =8'*1`'!#X3JQ"?!?H+]1 MIF4R=]EC%SI(DU)Q"E#_:,"(=Y="C^^0_Y(*#[%,X6=1IA^@3U!D*',",%!. M_SCP`R%GY@I09M280)- EMK_2P&$Y8>A`Q (<(P17X(B8,=#EF"P7Z S-#<< M$'@4_YNE:4H!D3U G--I1S!0%P#_F%!J,7!4;P%BEY="H2B<Y?\)`!?1I$I? M@@_@I=^#"!J0]WI!/^)1IG(X\&OAI%>6R_9$,% UDG<`<(M!,%"K$%\Z51N M/^*6<U]Q>:U >>\WU9<T*( UP&=!,#5A<S/_-)*;HE^"K<:6<UDPA:!4LO99 M!Y"6RT8%L0.1;K +4?]2P'!S2M$Z<I+ 0"$_`;6$ZZ1*LN1(3U!PB'\X08IA M_T]0`R"?\3!!2P%@(9SQ/_'_/D-OLS7CC"8/L'Q14M$$8/\U88V/'4)O`2)S MBA47IB(P_T CBYD\LH#T4:8"(''!`:"_<-%,D"!@JHAX+U'$5S1"_SN@.*$\ M$$D2,%#%<3!!C&3_/O$IT&"@3;()\$'Q<-&O=_^JEQDB5EYBOU'%EM>P06 ` M_6N@8@3R2I P,EMTA^&34F^T@E6",#))T6K#T0-P;]I *AHBEM<^0R+,VEMT M]T<`.D4&X&284+5UCF66R/^T0C<INK)#H+YA*>!'$@EP_T* ")!&0(*"`Q ' MD5^"=8'WO@?.,Y;7(A>PN !'`#!!_SIR'4 '@*"""7 $$#4AK-'_03) (99A M&U$$(#I!-9$%P/_4/AA:'<7,G\VOSK_/S]]5_]%OTG_3C]26U3_63]=?V&]_ MV77:#]L?W"_=/PJ $@$``?%@```#`! 0``````,`$1 !`````P" $/____] M``<PH-<P$#YQO@% ``@PH-<P$#YQO@$+`"2 "" &``````# ````````1@`` M```#A0````````,`)8 (( 8``````, ```````!&`````!"%`````````P`F M@ @@!@``````P ```````$8`````4H4``+<-```>`"> "" &``````# ```` M````1@````!4A0```0````0````X+C ``P`H@ @@!@``````P ```````$8` M`````84````````+`"F "" &``````# ````````1@`````.A0````````,` M*H (( 8``````, ```````!&`````!&%`````````P`K@ @@!@``````P `` M`````$8`````&(4````````>`"R "" &``````# ````````1@`````VA0`` M`0````$`````````'@`M@ @@!@``````P ```````$8`````-X4```$````! M`````````!X`+H (( 8``````, ```````!&`````#B%```!`````0`````` @```>`#T``0````4```!213H@``````,`#33]-P``-4.% ` end

Sound like the dreaded 4.1.72-7 memory leak on the ARC. This is probably coming from MPIP. There's only one solution : upgrade your code Regards, Robert > -----Original Message----- > From: Brett Murphy [SMTP:sysadmin@alphalink.com.au] > Sent: mardi, 16. mars 1999 00:57 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) HyperARC needs a regular reboot? > > Hi All, > Far too regularly I am finding that when I telnet to my HyperARC > it drops the connection immediately. The problem remains until I > powercycle the chassis. Has anyone seen this before? > > -- > > All the best, > Brett Murphy > System Administrator, Alphalink (Australia) PTY LTD > ph: +61 3 9486-8844 fax: +61 3 9486-6822 > email: sysadmin@alphalink.com.au > > The contents of this message may not be quoted, > copied, reproduced or published in part or in whole, > without the written authorization of Brett Murphy, > Director, Alphalink (Australia) Pty Ltd. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Are there any plans in the future to allow management of HiperDSP cards through the HiperARC cli? Doing things through the windoze nmc manager is a real pain, and hooking up the serial ports at remote unmanned pops is not always possible. It would be nice to be able to e.g. in-service/out-of-service channels and spans from the CLI. This is one thing about Ciscos that is *very* nice. -Dan

Hello, I am using bsdi radius that comes with 3.1(very close to merit radius). I am trying to implement the port-limit setting, but it does not seem to work. I have three machines doing auth and one doing all the logging. I set Port-Limit = 1 and even tried Simultaneous-Use = 1, but am still able to login mult. times. Any ideas or suggestions? Thanks, Mark

Hello all, I am using Netserver 8/16 I for X2, V.90, ISDN, and analog dial in. I also use Livingson PM2E for strictly analog dial in. I have the DNS servers set in the Netserver config. (and PM2) Currently we have the users specify the Name Server addresses in their setup. While testing I set my config (WIN95/98) to use server assigned name server addresses. This works fine on the PM2, but the Netserver doesn't seem to report the nameservers to the clients when they dial in. Is this a known problem/feature or should I be looking for some other problem? How can I set up the Netservers to assign the DNS to the dial-in clients? Thanks, Curt

It always starts that way...... -----Original Message----- >yep, no problems so far. > >blake > >> -----Original Message----- >> From: Robert J. Adams [mailto:radams@siscom.net] >> Sent: Thursday, March 18, 1999 2:04 PM >> To: usr-tc@lists.xmission.com >> Subject: (usr-tc) DSP1.2.43 >> >> >> Hello, >> >> Anyone tried the new 1.2.43 code yet? >> >> -j >> >> --- >> Robert J. Adams radams@siscom.net http://www.siscom.net >> Looking to outsource news? http://www.newshosting.com >> SISCOM Network Administration - President, SISCOM Inc. >> Phone: 937-222-8150 FAX: 937-222-8153 >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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. >

yep, no problems so far. blake > -----Original Message----- > From: Robert J. Adams [mailto:radams@siscom.net] > Sent: Thursday, March 18, 1999 2:04 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) DSP1.2.43 > > > Hello, > > Anyone tried the new 1.2.43 code yet? > > -j > > --- > Robert J. Adams radams@siscom.net http://www.siscom.net > Looking to outsource news? http://www.newshosting.com > SISCOM Network Administration - President, SISCOM Inc. > Phone: 937-222-8150 FAX: 937-222-8153 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

The release notes only show differences in 1.2.43 and 1.2.5. I just got done flashing 1.2.59 into a LOT of my chassis around here. Could somebody please comment on the changes between 1.2.59 and 1.2.43. Thank you. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Senior Vice President - Exec-PC, Inc. |

We're using a NS16I for dedicated dial-up customers (ISDN & x2.) Static routes (Since the 16I doesn't do RIP2) do the trick for two Class C's, and one host route (They're using NAT), but we have a new customer with a /28 (16 IP's) subnet. The subnet is 209.224.119.224/28. 209.224.119.238 is assigned to them via RADIUS. I've added and saved a static route on the NetServer with `add route 209.224.119.224 209.224.119.238 1`. I've added and saved an entry to the netmask table with `add netmask 209.224.119.224 255.255.255.240`. A `show route` rightly shows these two entries: 209.224.119.224 209.224.119.238 HSC 1 ptp12 209.224.119.238 209.224.119.238 HLC 1 ptp12 And a `show table netmask` shows: Active Netmasks: Network Netmask Type ---------------- ---------------- ------- 209.224.119.224 255.255.255.240 Static 209.100.92.0 255.255.255.192 Dynamic Stored Netmasks: Network Netmask ---------------- ---------------- 209.224.119.224 255.255.255.240 A static route has been created on our Cisco 3640 directing 209.224.119.224/28 traffic to the NETServer. Traces to 209.224.119.238 arrive as expected. Any traces to 209.224.119.225-237 bounce back and forth between the NETServer and the Cisco. The NETServer is running 3.3.0 (Date: Nov 14 1997) How can I get this to work correctly? 14 static routes is messy, and upgrading to NetServer+ is worse. TIA, -Jeremy -=========================================================================- Jeremy Shaffner JORSM Internet, Regional Internet Services Senior Technical Support 7 Area Codes in Chicagoland and NW Indiana jer@jorsm.com 100Mbps+ Connectivity, 56K-DS3, V.90, ISDN support@jorsm.com Quality Service, Affordable Prices http://www.jorsm.com Serving Gov, Biz, Indivds Since 1995 -=========================================================================-

Hello, Anyone tried the new 1.2.43 code yet? -j --- Robert J. Adams radams@siscom.net http://www.siscom.net Looking to outsource news? http://www.newshosting.com SISCOM Network Administration - President, SISCOM Inc. Phone: 937-222-8150 FAX: 937-222-8153

I have 4 TCs with Netservers that broadcast RIPv1 to a Cisco 7206 (Formerly a Cisco 4000) just fine. I installed another TC with Netserver with the same exact config, but it's talking to a Cisco 4000 instead. No RIP routes show up on the Cisco 4000, but routing is working, probably due to proxy ARP. How can I debug the RIP problems? (I double checked the TC settings.) Here is my Cisco config router rip passive-interface Ethernet0 passive-interface Ethernet2 network 209.98.223.0 The network is on e1 and the IP addresses are in 209.98.223/24. Brian

Once upon a time Mark Starr shaped the electrons to say... > I am using bsdi radius that comes with 3.1(very close to merit radius). I >am trying to implement the port-limit setting, but it does not seem to work. >I have three machines doing auth and one doing all the logging. I set >Port-Limit = 1 and even tried Simultaneous-Use = 1, but am still able to >login mult. times. Any ideas or suggestions? Port-Limit DOES NOT limit multiple logins - period. What Port-Limit controls is the number of channels allowed in an MP bundle - it has no bearing at all on mutliple simultaneous, SEPARATE, logins. Simultaneous-Use is server specific and requires intelligence on the RADIUS server to deal with it. Last I knew Merit didn't handle it well - my personal recommendation would be to grab Cistron RADIUS which DOES handle simultaneous use limits with all popular NASen. AND Cistron also handles 3Com VSAs. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

I'm currently having a problem I've never had before. For quite a while we have had one active span on a dual PRI card. This week we ordered the second span and attempted to put it into service. However, the instant I plugged the span into the second port of the dual PRI card, it caused all the calls on the first span to drop. After a few seconds, calls start coming in on the first span again but are dropped after a few seconds. All the calls seem to drop simultaneously. I talked to the guys at the switch about it and they said it looked like it was related to signalling which would make sense since I'm using NFAS to share the D channel between the two spans. The configuration on the card looks okay and I have compared it with configurations on other cards I have had in service for over a year. All code is up to date. The other strange thing is the carrier and channels seem to come up on the second span but the DS1 terminator box that the telco installed indicates that AMI framing is being used. But I thought the carrier wouldn't even come up if the framing was incorrect (I have it set on the PRI Card as b8zs, wihch is what it should be). Error counters for the second span are through the roof according to the CLI on the PRI card. Has anybody seen this before? At this point I'm not sure if it's the line has been provisioned wrong by the telco or if my PRI card is bad. In my experience, I thought the carrier on the ds1 wouldn't even come up if the line was provisioned wrong. Any ideas?

When did they "RELEASE" this code? We still have 1.2.59! Any "REAL" bug fixes in this release? ============================================================================== 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 Thu, 18 Mar 1999, Blake Fithen wrote: > yep, no problems so far. > > blake > > > -----Original Message----- > > From: Robert J. Adams [mailto:radams@siscom.net] > > Sent: Thursday, March 18, 1999 2:04 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) DSP1.2.43 > > > > > > Hello, > > > > Anyone tried the new 1.2.43 code yet? > > > > -j > > > > --- > > Robert J. Adams radams@siscom.net http://www.siscom.net > > Looking to outsource news? http://www.newshosting.com > > SISCOM Network Administration - President, SISCOM Inc. > > Phone: 937-222-8150 FAX: 937-222-8153 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Hi Curt, Below are the two major issues resolved from 1.2.59 to 1.2.43. Hope this helps. Regards, David MR 2021 Improved V.42 compatibility with slower Win-modem clients. MR 2029 Issue : Failure to connect rates were too high and back channel speeds were too low. Resolution : The answer tone level was hard-coded and too loud to trigger the network echo cancellers in some environments. Curt Shambeau <curt@execpc.com> on 03/18/99 02:33:51 PM Please respond to usr-tc@lists.xmission.com cc: (David Bachta/MW/US/3Com) The release notes only show differences in 1.2.43 and 1.2.5. I just got done flashing 1.2.59 into a LOT of my chassis around here. Could somebody please comment on the changes between 1.2.59 and 1.2.43. Thank you. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Senior Vice President - Exec-PC, 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.

upgrade to 6.0.9. 5.3.3 is very old. 3com said 6.0.9 is backward compatible with all ARC releases. hard to believe but... (can't find the Software Compatibility Matrix to verify). blake > -----Original Message----- > From: K Mitchell [mailto:mitch@keyconn.net] > Sent: Thursday, March 18, 1999 4:13 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) HyperARC needs a regular reboot? > > > At 11:54 AM 3/18/99 +0100, Robert von Bismarck wrote: > >Sound like the dreaded 4.1.72-7 memory leak on the ARC. This > is probably > >coming from MPIP. There's only one solution : upgrade your code > > I know this is a bit far-fetched but; I haven't had any > problems with my > ARC console connection but, I've recently seen S&A Server sucking up > increasing amounts of memory, requiring a restart every > couple of days. I'm > running; > S&A Server 5.5.3 on NT 4 > ARC 4.1.72 > > Kirk > > > > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Elfert <brian@citilink.com> writes: > How can I debug the RIP problems? (I double checked the TC settings.) My first shot would be "debug ip rip" on the Cisco. (with "term mon" to see debugging). This will at least let you know what the Cisco thinks it is hearing (if anything) versus what the NETServer is generating (which you might verify if it's otherwise idle with ptrace). Might at least let you point at one side or the other. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

At 11:54 AM 3/18/99 +0100, Robert von Bismarck wrote: >Sound like the dreaded 4.1.72-7 memory leak on the ARC. This is probably >coming from MPIP. There's only one solution : upgrade your code I know this is a bit far-fetched but; I haven't had any problems with my ARC console connection but, I've recently seen S&A Server sucking up increasing amounts of memory, requiring a restart every couple of days. I'm running; S&A Server 5.5.3 on NT 4 ARC 4.1.72 Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

At 04:40 PM 3/18/99 -0600, you wrote: >upgrade to 6.0.9. 5.3.3 is very old. 3com said 6.0.9 is >backward compatible with all ARC releases. hard to believe >but... (can't find the Software Compatibility Matrix to >verify). I'd love to but, S&A Server was originally provided to me free by Source, who sold me my hub. It appears that Source no longer provides this and, naturally, 3Com won't give me a free upgrade(despite the fact that 5.5.3 has never worked correctly for me). I hesitate to pay for the newer version considering I can likely get a much better product than S&A Server if I'm shelling out bucks. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

On Thu, 18 Mar 1999, Mike Hamrich wrote: > OK HiperArc with latest code 3/4/99 I assume that you now have HiPer arc 4.1.59 -6 code. What is the DSP code that you have? > > Since the "upgrade" we are having tons of connection issues. > Couriers can't connect > Owners of Sporsters flashed with Feb '99 v.90 code connect slower > OEM/Brown box Sportsters can't stay connected > > We also told owner of non X2 modem to go elsewere. > > We surveyed our users, 248 replied so far: > 67% say slower speed, 22% are having problems saying connected, 4% can't > connect at all, and ONLY 7% report better connection. > > We have PRI lines, Set PPP offloading to no, Authenticate ANY Preferrd PAP If look at the release notes for this - There is a clear mention to set PPP offloading to enable and also to disable ppp receive_accm > Any other ideas to make this stuff work as well as the old stuff did? Set the PPP off loading to enable enable ppp offloading that should help you a lot. Also need to know the version of DSP code regards krish > > Thanks in advance for you help > > Mike Hamrich > CIO, DrFast.Net, Inc. > (216) 797-1040 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Anyone, I had error message on my log screen, it is the first time since we installed this system last May. It seems to me everything looks normal for now...but I want your opinion. It said: At 19:16:52, Facility "IP", Level "CRITICAL" :: [../../net/igmp_host.C]: Failed to join the multicast group, 224.0.0.1 I do not what this means, so I am little worried. Can you explain it to me?? Rickyz@mindspring.com

ARC 4.1.59-6 DSP 1.2.43 The only thing we having problems with are ISDN calls. Analog current link transmit rates are anywhere from 14,400 to 53,300. But i haven't seen a single ISDN call get established and pass data. mon ppp, and mon radius show nothing - "li co" will show the modem being tied up but after about 10 seconds it drops. I had a few ISDN customers connected with 4.1.59 and 1.2.59 but as soon as I upgraded the DSP to 1.2.43 things went downhill. [1 hour goes by] and at 7:30 my pager goes nuts saying that all our dedicated ISDN customers are back up. during this time i have been gathering statistics from the incomplete ISDN calls and then many dedicated customers with ISDN devices from many different vendors begin working again without any intervention from me. Ah! and everything came back up about the same time last night! WHAT THE HELL??!?!?! any similar experiences? TELCO sabotage? blake > -----Original Message----- > From: Mike Hamrich [mailto:mhamrich@drfast.net] > Sent: Thursday, March 18, 1999 7:21 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect > > > OK HiperArc with latest code 3/4/99 > > Since the "upgrade" we are having tons of connection issues. > Couriers can't connect > Owners of Sporsters flashed with Feb '99 v.90 code connect slower > OEM/Brown box Sportsters can't stay connected > > We also told owner of non X2 modem to go elsewere. > > We surveyed our users, 248 replied so far: > 67% say slower speed, 22% are having problems saying > connected, 4% can't > connect at all, and ONLY 7% report better connection. > > We have PRI lines, Set PPP offloading to no, Authenticate ANY > Preferrd PAP > > Any other ideas to make this stuff work as well as the old stuff did? > > Thanks in advance for you help > > Mike Hamrich > CIO, DrFast.Net, Inc. > (216) 797-1040 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Thu, 18 Mar 1999, Rick wrote: > Anyone, > I had error message on my log screen, it is the first time since we > installed this system last May. > > It seems to me everything looks normal for now...but I want your opinion. > It said: > At 19:16:52, Facility "IP", Level "CRITICAL" :: [../../net/igmp_host.C]: > Failed to join the multicast group, 224.0.0.1 This message basically tells you that the Hiper arc could not join the multicast group. This could be because you have not setup multicast properlly on the ARC. Check your multicast configuration - rather the igmp config krish > > I do not what this means, so I am little worried. > Can you explain it to me?? > > Rickyz@mindspring.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. >

On Thu, 18 Mar 1999, Netlink Hardware admin wrote: > > Hello all, > > I am using Netserver 8/16 I for X2, V.90, ISDN, and analog dial in. > I also use Livingson PM2E for strictly analog dial in. > The Netserver 8/16 does not support the DNS and wins attributes. krish > I have the DNS servers set in the Netserver config. (and PM2) > > Currently we have the users specify the Name Server addresses in their > setup. > > While testing I set my config (WIN95/98) to use server assigned name > server addresses. > > This works fine on the PM2, but the Netserver doesn't seem to report the > nameservers to the clients when they dial in. > > Is this a known problem/feature or should I be looking for some other > problem? > > How can I set up the Netservers to assign the DNS to the dial-in clients? > > Thanks, > > Curt > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

OK HiperArc with latest code 3/4/99 Since the "upgrade" we are having tons of connection issues. Couriers can't connect Owners of Sporsters flashed with Feb '99 v.90 code connect slower OEM/Brown box Sportsters can't stay connected We also told owner of non X2 modem to go elsewere. We surveyed our users, 248 replied so far: 67% say slower speed, 22% are having problems saying connected, 4% can't connect at all, and ONLY 7% report better connection. We have PRI lines, Set PPP offloading to no, Authenticate ANY Preferrd PAP Any other ideas to make this stuff work as well as the old stuff did? Thanks in advance for you help Mike Hamrich CIO, DrFast.Net, Inc. (216) 797-1040

Thus spake K Mitchell >At 04:40 PM 3/18/99 -0600, you wrote: >>upgrade to 6.0.9. 5.3.3 is very old. 3com said 6.0.9 is >>backward compatible with all ARC releases. hard to believe >>but... (can't find the Software Compatibility Matrix to >>verify). >I'd love to but, S&A Server was originally provided to me free by Source, >who sold me my hub. It appears that Source no longer provides this and, >naturally, 3Com won't give me a free upgrade(despite the fact that 5.5.3 >has never worked correctly for me). I hesitate to pay for the newer version >considering I can likely get a much better product than S&A Server if I'm >shelling out bucks. Gee...can I connect this back to my "3Com Problems" thread from last week or so? Sounds like much the same situation, and screw the customer even though 3Com didn't deliver what they promised attitude that we're *still* fighting with 3Com. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

At 10:09 PM 3/18/99 -0500, Jeff Mcadams wrote: >Thus spake K Mitchell >>At 04:40 PM 3/18/99 -0600, you wrote: >>>upgrade to 6.0.9. 5.3.3 is very old. 3com said 6.0.9 is >>>backward compatible with all ARC releases. hard to believe >>>but... (can't find the Software Compatibility Matrix to >>>verify). > >>I'd love to but, S&A Server was originally provided to me free by Source, >>who sold me my hub. It appears that Source no longer provides this and, >>naturally, 3Com won't give me a free upgrade(despite the fact that 5.5.3 >>has never worked correctly for me). I hesitate to pay for the newer version >>considering I can likely get a much better product than S&A Server if I'm >>shelling out bucks. > >Gee...can I connect this back to my "3Com Problems" thread from last >week or so? Sounds like much the same situation, and screw the customer >even though 3Com didn't deliver what they promised attitude that we're >*still* fighting with 3Com. No arguement here. It's really a shame that 3Com continues support policies that steer so many potential customers to other vendors. Hardware-wise, I feel the HiPer chassis is amoung the best currently available, but 3Com management is selling a lot of product for their competitors. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

I am currently trying to switch to another PRI provider, and to do a gradual move of all my PRIs I would need to have my old PRIs to overflow (when busy) to some other PRIs in another Central Office (in the same area code). The two telcos say that it is technically impossible to program this feature on the DMS since it is not in the same Central Office. Could someone confirm if this is true ? Also, would you say that it would be possible to have the old telco PRI to overflow to a centrex line in the same CO. And then program the centrex line to forward calls to the phone number of the other PRI of the other telco ? D Baud

On Thu, 18 Mar 1999, Jeff Mcadams wrote: >Gee...can I connect this back to my "3Com Problems" thread from last >week or so? Sounds like much the same situation, and screw the customer >even though 3Com didn't deliver what they promised attitude that we're >*still* fighting with 3Com. No. I got Win3.1 with my computer; does that mean Microsoft should give me a free copy of 95? (or 95->98...) He didn't buy the radius server, so why should 3Com give away something they've devoted resources to develop? What kind of problems do you have with 5.5.3? --Ricky

On Fri, 19 Mar 1999, d baud wrote: >The two telcos say that it is technically impossible to program this >feature on the DMS since it is not in the same Central Office. Could >someone confirm if this is true ? Not "impossible", just impracticle. It would not be a normal rotary type of setup. The telco would have to setup some form of call forwarding to get the overflow from on PRI to another switch. I know for a fact this can be done, because I had it done before. The 800# rotary landed as 800 traffic on hardware in four different cities. Two of those cities had dedicated hardware and T1's from the 800 provider (BTI). The other two POPs were pre-existing PRI feed POPs from different telcos (GTE or USLEC, and Bellsouth.) I don't know how they did it, but they did charge for the 800# overflow. The only possible difference is the fact that BTI is a LD provider who has interconnections with the telcos handling the overflow. (Personally, I was amazed to see BTI get it right the first time. :-) (no offense)) --Ricky

At 01:05 AM 3/19/99 -0500, Ricky Beam wrote: >No. I got Win3.1 with my computer; does that mean Microsoft should give me >a free copy of 95? (or 95->98...) He didn't buy the radius server, so why >should 3Com give away something they've devoted resources to develop? What >kind of problems do you have with 5.5.3? No, I didn't buy it. As I said, it was included with my purchase by Source. My understanding is that Source had an agreement with 3Com that allowed them to do this for their customers and 3Com discontinued the agreement. Personally I feel that I should at least have something that works, whether it's upgraded to 6.x.x or not. As for the problems...the only log that works is Event Log. All of the other logs either display "error#" under the column headers or they display the sample information containing 3 months worth of data from 1995. I've gone over the accounting and logging configuration 3 times with support to no avail. 5.5.3 is running on NT4/SP4 with Access 98 Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Thia has less to do with technical capabilities and more to do with politics and turf. The only real way to do this is to bring in your new PRIs and have your initial provider call forward all calls to you new PRI number. Since the cut will also be an issue, you will have to have the new PRIs running and tested (and believe me there will be a hundred reasons the new ones will need to be tested), and then watch for the calls to start dropping and plug in the new PRIs. Once you are up on the new PRIs, then you can have the old ones disconnected, but maintain the call forwards on the old number (unless you have number portability in your area). Over a few months you can get the word out to your customers, and gradually reduce the number of call forward paths from the old number. -----Original Message----- >I am currently trying to switch to another PRI provider, and to do a >gradual move of all my PRIs I would need to have my old PRIs to overflow >(when busy) to some other PRIs in another Central Office (in the same >area code). >The two telcos say that it is technically impossible to program this >feature on the DMS since it is not in the same Central Office. Could >someone confirm if this is true ? > >Also, would you say that it would be possible to have the old telco PRI >to overflow to a centrex line in the same CO. And then program the >centrex line to forward calls to the phone number of the other PRI of >the other telco ? > >D Baud > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I re-enabled ppp offloading and disabled ppp receive_accm as it is recomended in the release notes of 4.1.59-6. After doing this, we started receiving a rash of NT people getting blocked at the PAP authentication. Fortunately, this problem can be fixed by disabling the LCP Extensions on the NT machine. I am planning to disable ppp offloading to avoid this but I need to know how bad this will impact the gerneral performance for a chasis with a maximum of 4 DSP cards per HiperArc. D Baud

Thus spake Ricky Beam >On Thu, 18 Mar 1999, Jeff Mcadams wrote: >>Gee...can I connect this back to my "3Com Problems" thread from last >>week or so? Sounds like much the same situation, and screw the customer >>even though 3Com didn't deliver what they promised attitude that we're >>*still* fighting with 3Com. >No. I got Win3.1 with my computer; does that mean Microsoft should give me >a free copy of 95? (or 95->98...) He didn't buy the radius server, so why >should 3Com give away something they've devoted resources to develop? What >kind of problems do you have with 5.5.3? Geez...you're just not getting it. Its not an issue of upgrading from one product that works to another better product that works. Its an issue of being sold a product that doesn't work, and then being told to get a fix you have to pay more money for a different product. Its bait and switch and its illegal. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of d baud |Sent: Friday, March 19, 1999 3:41 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) PPP offloading and NT | | |I re-enabled ppp offloading and disabled ppp receive_accm as it is |recomended in the release notes of 4.1.59-6. |After doing this, we started receiving a rash of NT people getting |blocked at the PAP authentication. Fortunately, this problem can be |fixed by disabling the LCP Extensions on the NT machine. | |I am planning to disable ppp offloading to avoid this but I need to know |how bad this will impact the gerneral performance for a chasis with a |maximum of 4 DSP cards per HiperArc. | You should leave the settings as sugested in the release notes. NT has its own problems, not the TCH. NT should have failed reguardless of the offloading setting. If you dissable PPP offloading you may run back into the "WebRamp"/PAP issues. -M

Anyone know why 6.0.9 isn't freely downloadable since it is called a service release ? Just wondering. Jeff Binkley ASA Network Computing U>upgrade to 6.0.9. 5.3.3 is very old. 3com said 6.0.9 is U>backward compatible with all ARC releases. hard to believe U>but... (can't find the Software Compatibility Matrix to U>verify). U>blake U>> -----Original Message----- U>> From: K Mitchell [mailto:mitch@keyconn.net] U>> Sent: Thursday, March 18, 1999 4:13 PM U>> To: usr-tc@lists.xmission.com U>> Subject: RE: (usr-tc) HyperARC needs a regular reboot? U>> At 11:54 AM 3/18/99 +0100, Robert von Bismarck wrote: U>> >Sound like the dreaded 4.1.72-7 memory leak on the ARC. This U>> is probably U>> >coming from MPIP. There's only one solution : upgrade your code U>> I know this is a bit far-fetched but; I haven't had any U>> problems with my U>> ARC console connection but, I've recently seen S&A Server sucking up U>> increasing amounts of memory, requiring a restart every U>> couple of days. I'm U>> running; U>> S&A Server 5.5.3 on NT 4 U>> ARC 4.1.72 U>> Kirk U>> Kirk Mitchell-General Manager sysadmin@keyconn.net U>> Keystone Connect http://www.keyconn.net U>> Altoona, PA 814-941-5000 We Unlock the World U>> - U>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U>> with "unsubscribe usr-tc" in the body of the message. U>> For information on digests or retrieving files and old messages U>> send "help" to the same address. Do not use quotes in your U>> message. U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. U> CMPQwk 1.42 9999

Krish, Note he has Preferred set to PAP which may be a problem with Quads as you and I discovered the other day. Jeff Binkley ASA Network Computing U>On Thu, 18 Mar 1999, Mike Hamrich wrote: U>> OK HiperArc with latest code 3/4/99 U>I assume that you now have HiPer arc 4.1.59 -6 code. U>What is the DSP code that you have? U>> Since the "upgrade" we are having tons of connection issues. U>> Couriers can't connect U>> Owners of Sporsters flashed with Feb '99 v.90 code connect slower U>> OEM/Brown box Sportsters can't stay connected U>> We also told owner of non X2 modem to go elsewere. U>> We surveyed our users, 248 replied so far: U>> 67% say slower speed, 22% are having problems saying connected, 4% U>> can't connect at all, and ONLY 7% report better connection. U>> We have PRI lines, Set PPP offloading to no, Authenticate ANY U>> Preferrd PAP U>If look at the release notes for this - There is a clear mention to U>set PPP offloading to enable and also to disable ppp receive_accm U>> Any other ideas to make this stuff work as well as the old stuff U>did? U>Set the PPP off loading to enable U>enable ppp offloading U>that should help you a lot. U>Also need to know the version of DSP code U>regards U>krish U>> Thanks in advance for you help U>> Mike Hamrich U>> CIO, DrFast.Net, Inc. U>> (216) 797-1040 U>> - U>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U>> with "unsubscribe usr-tc" in the body of the message. U>> For information on digests or retrieving files and old messages U>> send "help" to the same address. Do not use quotes in your U>> message. U>- U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" U> with "unsubscribe usr-tc" in the body of the message. U> For information on digests or retrieving files and old messages send U> "help" to the same address. Do not use quotes in your message. U> CMPQwk 1.42 9999

Ricky, I would tend to agree with you but I think the concept of version levels vs service packs/releases needs to be brought into play. You can download patches for free from MS for Windows 3.1 and Windows 95, however you can download Windows 95 freely to install over 3.1. Now how 3Com would manage this remains to be seen. For instance a 6.0.8 user should be able to freely download the SR 6.0.9 but they can't. The problem is if 3Com makes 6.0.9 freely downloadable without some way for the installation routine to verify the release levels then everyone can upgrae by pulling down the SR. It's not an insurrmoutnable problem, just one which hasn't been addressed. Jeff Binkley ASA Network Computing u>On Thu, 18 Mar 1999, Jeff Mcadams wrote: u>>Gee...can I connect this back to my "3Com Problems" thread from last u>>week or so? Sounds like much the same situation, and screw the u>customer >even though 3Com didn't deliver what they promised attitude u>that we're >*still* fighting with 3Com. u>No. I got Win3.1 with my computer; does that mean Microsoft should u>give me a free copy of 95? (or 95->98...) He didn't buy the radius u>server, so why should 3Com give away something they've devoted u>resources to develop? What kind of problems do you have with 5.5.3? u>--Ricky u>- u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" u> with "unsubscribe usr-tc" in the body of the message. u> For information on digests or retrieving files and old messages send u> "help" to the same address. Do not use quotes in your message. u> CMPQwk 1.42 9999

Now that we're all trading our quads for HiperDSP's, what can we do with our T1 cards? Is there a way to use those t1 ports for frame relay? I don't see a way to do it, but maybe I'm missing something. Hate to just waste good hardware.

So...no comments regarding connect-with-anything modem strings? Did my last message even go out on the list?

Can any tell me where I can find help files that tell me how to setup a USR from the very first one that came out to the latest one. Thanks Vito

On Fri, 19 Mar 1999, Jeff Binkley wrote: > > > > Krish, > > Note he has Preferred set to PAP which may be a problem with Quads as > you and I discovered the other day. > Well he is using DSP for the most part and also he is complaing about speed and through put. Disabling ppp offloading does slow down the throughput to a good extent. I have not heard from him and I also offered to work with him to find out if he has the quad or the DSP, no answer from him yet. thanks krish > Jeff Binkley > ASA Network Computing > > > U>On Thu, 18 Mar 1999, Mike Hamrich wrote: > > U>> OK HiperArc with latest code 3/4/99 > > U>I assume that you now have HiPer arc 4.1.59 -6 code. > U>What is the DSP code that you have? > > U>> Since the "upgrade" we are having tons of connection issues. > U>> Couriers can't connect > U>> Owners of Sporsters flashed with Feb '99 v.90 code connect slower > U>> OEM/Brown box Sportsters can't stay connected > > U>> We also told owner of non X2 modem to go elsewere. > > U>> We surveyed our users, 248 replied so far: > U>> 67% say slower speed, 22% are having problems saying connected, 4% > U>> can't connect at all, and ONLY 7% report better connection. > > U>> We have PRI lines, Set PPP offloading to no, Authenticate ANY > U>> Preferrd PAP > > U>If look at the release notes for this - There is a clear mention to > U>set PPP offloading to enable and also to disable ppp receive_accm > > > > U>> Any other ideas to make this stuff work as well as the old stuff > U>did? > > > U>Set the PPP off loading to enable > > U>enable ppp offloading > U>that should help you a lot. > > U>Also need to know the version of DSP code > > U>regards > U>krish > > U>> Thanks in advance for you help > > U>> Mike Hamrich > U>> CIO, DrFast.Net, Inc. > U>> (216) 797-1040 > > > U>> - > U>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > U>> with "unsubscribe usr-tc" in the body of the message. > U>> For information on digests or retrieving files and old messages > U>> send "help" to the same address. Do not use quotes in your > U>> message. > > > U>- > U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > U> with "unsubscribe usr-tc" in the body of the message. > U> For information on digests or retrieving files and old messages send > U> "help" to the same address. Do not use quotes in your message. > > U> > > 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. >

I have two arcs that when I boot them, the rn/fl light is just solid red. I get no BOOT PROM banner at any speed. I have set SW5 and tried to boot but that does not work. What is the next step in getting these cards to a point where I can work with them? Any more SW's I can set etc? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

We're still having numerous MacPPP failures under 4.1.59-6. Catching your request in advance Krish, here's the hex dump output of one such failure. Please note that I changed the user name and password, and XX'd the hex for the password. Decode tracing started, press ESCAPE to stop; press X for hex tracing. Tracing changed to hex dumps; press Escape to stop; press D for decode tracing. Outgoing PPP Data on interface: slot:11/mod:14 c0 23 02 01 00 05 00 | # | Outgoing PPP Data on interface: slot:11/mod:14 80 21 01 04 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| 01 15 | | Outgoing PPP Data on interface: slot:11/mod:14 80 21 01 05 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| 01 15 | | Outgoing PPP Data on interface: slot:11/mod:14 80 21 01 06 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| 01 15 | | Incoming PPP Data on interface: slot:11/mod:14 c0 23 01 03 00 14 08 6c 6f 73 74 63 68 6c 64 06 | # username | XX XX XX XX XX XX |SEKRET | Outgoing PPP Data on interface: slot:11/mod:14 80 21 01 07 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| 01 15 | | Incoming PPP Data on interface: slot:11/mod:14 c0 23 01 04 00 14 08 6c 6f 73 74 63 68 6c 64 06 | # username | XX XX XX XX XX XX |SEKRET | Outgoing PPP Data on interface: slot:11/mod:14 80 fd 01 08 00 15 12 06 00 00 00 01 11 05 00 00 | | 03 11 06 00 00 01 01 | | Incoming PPP Data on interface: slot:11/mod:14 ff 03 c0 21 08 05 00 1b 80 fd 01 08 00 15 12 06 | ! | 00 00 00 01 11 05 00 00 03 11 06 00 00 01 01 | | Outgoing PPP Data on interface: slot:11/mod:14 80 21 01 09 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| 01 15 | | Incoming PPP Data on interface: slot:11/mod:14 ff 03 c0 21 05 06 00 04 | ! | Outgoing PPP Data on interface: slot:11/mod:14 ff 03 c0 21 06 06 00 04 | ! | (hangup)

Your message made it. :) My excuse is "vacation", but I'm going to try it later today... thanks for the rundown, this'll be a BIG help... Why disable the 2100hz answer tone? What does this gain you? Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!" On Fri, 19 Mar 1999, Lon R. Stockton, Jr. wrote: > So...no comments regarding connect-with-anything modem strings? > > Did my last message even go out on the list?

Tatai SV Krishnan said once upon a time: >> We're still having numerous MacPPP failures under 4.1.59-6. Catching your >> request in advance Krish, here's the hex dump output of one such failure. >> Please note that I changed the user name and password, and XX'd the hex for >> the password. > >This is with DSP code ?? Yes. We're almost Quad free here. >Are you also using Quad here? Not in the case I sent you. >Also is it safe to say that disabling ppp offloading does resolve this >problem? I haven't tried that yet. I thought that doing this was a "bad thing".

If the HARC is not giving a BOOT PROMPT on the console prompt or a Debug Port OKAY on the Debug Port then 1 of 4 things has been broken: If the system on power up goes from Red to green and then to Red, then your memory controller/DRAM DIMM is defective, try replacing the DIMM with another and see if the problem disappears. The 16C550 UART fails diagnostics. One of the 2 UART ports on the 2692 fails diagnostics. The Real-Time clock fails diagnostics. The only way to find out which of these things has been broken is to set DipSwitch 10 ON and reinsert the card. When you do this it will perform a complete memory test(inprogress when the LEDs rotate orange). After it finishes it will then test the 3 UART ports, configure the 3 UART ports and then test the Real-Time Clock. It uses LEDs 5 6 7(from the top) to indicate status, if any of them go RED then it has failed diagnostics and the board is toast and must be replaced. Get a cup of coffee prior to starting this test and pay careful attention to the LEDs because they get reset fairly fast. -- Matt Brian <signal@shreve.net> on 03/19/99 10:44:12 AM Please respond to usr-tc@lists.xmission.com cc: (Matt Harper/MW/US/3Com) I have two arcs that when I boot them, the rn/fl light is just solid red. I get no BOOT PROM banner at any speed. I have set SW5 and tried to boot but that does not work. What is the next step in getting these cards to a point where I can work with them? Any more SW's I can set etc? 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.

On Fri, 19 Mar 1999, Jeff Binkley wrote: >I would tend to agree with you but I think the concept of version levels >vs service packs/releases needs to be brought into play. You can Not to mention confusing... >3Com would manage this remains to be seen. For instance a 6.0.8 user >should be able to freely download the SR 6.0.9 but they can't. The >problem is if 3Com makes 6.0.9 freely downloadable without some way for >the installation routine to verify the release levels then everyone can >upgrae by pulling down the SR. It's not an insurrmoutnable problem, >just one which hasn't been addressed. I have pointed that out to them before. They need a method of "patching" the binary files -- something like the redhat "rhmask" files... I alays had someone mail me the files I had to have. I was fortunate enough to have source code access to SA4 and then SA6, so as soon as I'd get the source, I didn't care what 3Com was up to anymore aside from sending bug patches back to them (I hope they paid attention to them since the NDA required me to destroy the source when I left Interpath.) --Ricky

> -----Original Message----- > From: Jeff Mcadams [mailto:jeffm@iglou.com] > Sent: Friday, March 19, 1999 11:59 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) modem configs > > I actually saw this mentioned recently somewhere. > > The telephone companies use echo cancellers (sp?) in their network > to...cancel echos...(duh) so you don't hear yourself talking when you > talk on the phone. Basically, modems take care of this > themselves...well...at least they're *supposed* to, and the telco echo > cancellers screw up the connection, so the 2100hz tone for > approximately > 1 sec will turn off any echo cancellers that the telcos provide on the > lines, letting the modems do their own things in that department. This is accurate info... the echo cancellers munge the data streams by inserting silence when an echo condition is detected... this makes sense for speech but will kill data (or at least, make it very sick). However, "echo cans" are usually only deployed on long distance networks, so if you aren't taking inbound toll or 800 calls, you probably could disable this and still function. Never tried it.

On Fri, 19 Mar 1999, Pete Ashdown wrote: > We're still having numerous MacPPP failures under 4.1.59-6. Catching your > request in advance Krish, here's the hex dump output of one such failure. > Please note that I changed the user name and password, and XX'd the hex for > the password. This is with DSP code ?? Are you also using Quad here? Also is it safe to say that disabling ppp offloading does resolve this problem? krish > > Decode tracing started, press ESCAPE to stop; press X for hex tracing. > Tracing changed to hex dumps; press Escape to stop; press D for decode tracing. > > Outgoing PPP Data on interface: slot:11/mod:14 > c0 23 02 01 00 05 00 | # | > > > Outgoing PPP Data on interface: slot:11/mod:14 > 80 21 01 04 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| > 01 15 | | > > > Outgoing PPP Data on interface: slot:11/mod:14 > 80 21 01 05 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| > 01 15 | | > > > Outgoing PPP Data on interface: slot:11/mod:14 > 80 21 01 06 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| > 01 15 | | > > > Incoming PPP Data on interface: slot:11/mod:14 > c0 23 01 03 00 14 08 6c 6f 73 74 63 68 6c 64 06 | # username | > XX XX XX XX XX XX |SEKRET | > > > Outgoing PPP Data on interface: slot:11/mod:14 > 80 21 01 07 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| > 01 15 | | > > > Incoming PPP Data on interface: slot:11/mod:14 > c0 23 01 04 00 14 08 6c 6f 73 74 63 68 6c 64 06 | # username | > XX XX XX XX XX XX |SEKRET | > > > Outgoing PPP Data on interface: slot:11/mod:14 > 80 fd 01 08 00 15 12 06 00 00 00 01 11 05 00 00 | | > 03 11 06 00 00 01 01 | | > > > Incoming PPP Data on interface: slot:11/mod:14 > ff 03 c0 21 08 05 00 1b 80 fd 01 08 00 15 12 06 | ! | > 00 00 00 01 11 05 00 00 03 11 06 00 00 01 01 | | > > > Outgoing PPP Data on interface: slot:11/mod:14 > 80 21 01 09 00 10 02 06 00 2d 0f 00 03 06 a6 46 | ! - F| > 01 15 | | > > > Incoming PPP Data on interface: slot:11/mod:14 > ff 03 c0 21 05 06 00 04 | ! | > > > Outgoing PPP Data on interface: slot:11/mod:14 > ff 03 c0 21 06 06 00 04 | ! | > > (hangup) > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Fri, 19 Mar 1999, Mike Andrews wrote: > Your message made it. :) My excuse is "vacation", but I'm going to try > it later today... thanks for the rundown, this'll be a BIG help... No problem, glad to help if it indeed does. (: But what's a 'vacation'? > Why disable the 2100hz answer tone? What does this gain you? I was in a quick scan mode looking for stuff to turn off. (: According to the dox, some older 2400 modems didn't recognize it, and it allows v42 modems to connect more quickly. On the other hand, it doesn't say what it's for and what I'm losing by turning it off, so more research is indicated on that....or perchance an authoritative post from someone here... (:

Thus spake Lon R. Stockton, Jr. >On Fri, 19 Mar 1999, Mike Andrews wrote: >> Why disable the 2100hz answer tone? What does this gain you? >I was in a quick scan mode looking for stuff to turn off. (: According >to the dox, some older 2400 modems didn't recognize it, and it allows >v42 modems to connect more quickly. On the other hand, it doesn't say >what it's for and what I'm losing by turning it off, so more research >is indicated on that....or perchance an authoritative post from someone >here... (: I actually saw this mentioned recently somewhere. The telephone companies use echo cancellers (sp?) in their network to...cancel echos...(duh) so you don't hear yourself talking when you talk on the phone. Basically, modems take care of this themselves...well...at least they're *supposed* to, and the telco echo cancellers screw up the connection, so the 2100hz tone for approximately 1 sec will turn off any echo cancellers that the telcos provide on the lines, letting the modems do their own things in that department. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Fri, 19 Mar 1999, Jeff Mcadams wrote: > Thus spake Lon R. Stockton, Jr. > >On Fri, 19 Mar 1999, Mike Andrews wrote: > >> Why disable the 2100hz answer tone? What does this gain you? > > >I was in a quick scan mode looking for stuff to turn off. (: According > >to the dox, some older 2400 modems didn't recognize it, and it allows > >v42 modems to connect more quickly. On the other hand, it doesn't say > >what it's for and what I'm losing by turning it off, so more research > >is indicated on that....or perchance an authoritative post from someone > >here... (: > > I actually saw this mentioned recently somewhere. > > The telephone companies use echo cancellers (sp?) in their network > to...cancel echos...(duh) so you don't hear yourself talking when you > talk on the phone. Basically, modems take care of this > themselves...well...at least they're *supposed* to, and the telco echo > cancellers screw up the connection, so the 2100hz tone for approximately > 1 sec will turn off any echo cancellers that the telcos provide on the > lines, letting the modems do their own things in that department. Hmmm. From the sounds of it, it's something I don't want to turn off (it was a stretch worrying about a handful of really old 2400bps modems anyway). The faster v.42 connect is enticing tho...I wonder if the echo cancelling is much of a factor on digital lines. I hate thinking that I'm spending a second turning off things that don't [exist|bother_me]. Time to go a-searchin'...

> > >> We're still having numerous MacPPP failures under 4.1.59-6. Catching your > >> request in advance Krish, here's the hex dump output of one such failure. > >> Please note that I changed the user name and password, and XX'd the hex for > >> the password. > > > >This is with DSP code ?? > > Yes. We're almost Quad free here. > What version of DSP are you using? > >Are you also using Quad here? > > Not in the case I sent you. > > >Also is it safe to say that disabling ppp offloading does resolve this > >problem? Disabling ppp offloading is not recommened. PPP offloading enabled will have the modem hardware do the ppp framing. The only reason I asked if disabling ppp offloading works is because - that would tell me who is causing the problem - HiPer arc or DSP. krish > > I haven't tried that yet. I thought that doing this was a "bad thing". > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Yep, looks like I *don't* want to turn off the 2100hz tone for my connect-with-almost anything init string. OTOH, it looks like it could be turned off for the high-performance init string *if* you don't have long-distance callers (and if you don't have a telco with the echo cans deployed on their local lines). Interesting info about it all is here: <http://www.electric-words.com/dict/e/echocancellation.html>

Tatai SV Krishnan said once upon a time: >What version of DSP are you using? 1.2.59 (reports as 1.2.60) >> >Also is it safe to say that disabling ppp offloading does resolve this >> >problem? >Disabling ppp offloading is not recommened. PPP offloading enabled will >have the modem hardware do the ppp framing. The only reason I asked if >disabling ppp offloading works is because - that would tell me who is >causing the problem - HiPer arc or DSP. It is a bit difficult to do this, as it is on production equipment.

I have several webramp customers that are having trouble. I've isolated the problem with 3com and if I turn off 'stack compression' on the webramp everything should work fine. I've looked through all the webramp pdf docs and I can't find anywhere the command or place on the web interface to set this on or off. Does anybody know how to do this? Thanks! -Mark Lemmert AthEnet Data Exchange Chief Technical Officer 888-919-8700

On Fri, 19 Mar 1999, Pete Ashdown wrote: > > It is a bit difficult to do this, as it is on production equipment. Let me setup a mac here and start dialing here to check the problem - Can you give me info on what modem the mac is using? I assume that you are using freeppp on the mac. regards krish > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Has anyone bothered counting the number of call failures on the DSP's? I have included a script below which parses through our SNMP trap logs and generates a simple report on the number of call failures ordered by modem. The values get reset every midnight. Here is a sample of what you get. Note that this report was generated mid afternoon. I've confident that the top 7 modems have not had a successfull call today. Report generated: Fri Mar 19 15:00:01 EST 1999 Fails NMC Slot Modem 45 10.1.1.102 8 24 45 10.1.1.102 8 23 26 10.1.4.105 3 16 26 10.1.4.105 3 15 23 10.1.4.105 14 15 22 10.1.4.105 3 6 21 10.1.4.105 3 5 18 10.1.5.11 15 6 18 10.1.5.11 15 5 (NOTE: The above are all DSP's) 7 10.1.5.11 6 3 7 10.1.5.11 15 8 5 10.1.5.11 4 1 Notice the trend of sequential pairs of modems with nearly the same call failure rate? As a witness to many of these reports, I can tell you this is not even close to a rare occurrance. And forget all the BS about the 'telco'... at the 10.1.4.* site, _we_are_ the telco. (The chassis' are barely 10 feet from the DMS100). Since this report was generated rather early in the day, the values are actually low. By the end of the day, most of our pool is full, so these bad modems are the only ones attempting to take calls. I'll probably have over 300 failures per bad modem by the end of the day. ("good" modems only have around 10-12 failures max. per day). The only solution I've come up with to fix this is to reboot the DSP. (Since this is not a desirable solution, I end up busying out the associated DS0's and waiting until our _weekly_ chassis reboot). Tried resetting and dis/enabling the modems from the TCM, and soft-resetting the modems. Doesn't do a darn thing. (BTW: Our code versions are ARC 4.1.72 and DSP 1.2.60, because I still don't trust the .59 codes... I mean, come on... a bug fix for a bug fix???) Here's how to set up this report: On a Unix machine, set up the UCD-SNMP tools (snmptrapd in particular). (by default, it will syslog traps to LOG_LOCAL0, which you direct to /var/log/snmptraps). Place the MIB files from the mib directory under TCM into the directory /usr/local/share/snmp/mibs on the UCD-SNMP machine. Configure all of your modems to SNMP trap Incoming Call Failures to this machine. (I actually trap all sorts of stuff). This works with DSP's and Quadmodems. Install the following scripts into /usr/local/bin. Add a cron job to run 'publish_badmodems' every half hour. Let the chaos unfold. I don't claim that this will for for everyone. I do know it works for me. --- publish_badmodems --- #!/bin/sh exec 1>/path/to/publish/to/badmodems.html echo "<head></head><body>" echo "<p>Report generated: `date`<hr><pre>" echo -e "<b>Fails\tNMC\t\tSlot\tModem</b><p><hr>" nice /usr/local/bin/parsefails echo "</pre></body>" --- parsefails --- #!/bin/sh if [ -f "$1" ]; then INFILE="$1" else INFILE=/var/log/snmptraps fi egrep -i 'inconnectAttemptFailure|ctConnectAttemptFailure' $INFILE \ | awk -f /usr/local/sbin/parsefails.awk \ | sort -n | uniq -c | sort -nr --- parsefails.awk --- /Uptime: [0-9]* days?,/ { gsub("Uptime: [0-9]* days?,","Uptime: ") } { gsub("[,:]","") } /Trap \(inconnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 } /Trap \(ctConnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }

So far no joy... I get a fast busy on the (new) number now, and the failure to connect reason is logged as "invalid cause code". Hmmmm. I know DNIS is being received OK because we've been using it for other accounting stuff for forever. Init string is &K0S51.6=1S76.1=1S81.5=1 (without the leading AT). Do you maybe have the leading AT on yours? Mdm.mib says it shouldn't be there. I haven't yet had the chance to test this on Quads... only DSP's... but the settings should be the same either way (just without the profiles). Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!" On Fri, 19 Mar 1999, Lon R. Stockton, Jr. wrote: > So...no comments regarding connect-with-anything modem strings? > > Did my last message even go out on the list?

On Fri, 19 Mar 1999, Lon R. Stockton, Jr. wrote: >On Fri, 19 Mar 1999, Mike Andrews wrote: >> Your message made it. :) My excuse is "vacation", but I'm going to try >> it later today... thanks for the rundown, this'll be a BIG help... > >No problem, glad to help if it indeed does. (: But what's a 'vacation'? A 'vacation' is what you call the first time away from (any) work in several years. [Something I was doing until too many people became aware of my employment status... it was nice while is lasted :-)] >> Why disable the 2100hz answer tone? What does this gain you? > >I was in a quick scan mode looking for stuff to turn off. (: According >to the dox, some older 2400 modems didn't recognize it, and it allows >v42 modems to connect more quickly. On the other hand, it doesn't say >what it's for and what I'm losing by turning it off, so more research >is indicated on that....or perchance an authoritative post from someone >here... (: I think the answer tone is used to help the modem index the crappiness of the phone line. (Trick to detect padding???) --Ricky

I had the same exact problem and it took me and Bell Atlantic 3 weeks to figure out it was a "bad house cable" in other words a bad pair. Tell them the reason the 1st span drops it that it is causing too much noise on the 1st circuit and causes it to drop. Just have the telco change the pair that its on (if you have multiple) if not then have them install a brand new sheilded line in from the smartjack. John On Thu, 18 Mar 1999, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: > I'm currently having a problem I've never had before. For quite a while we > have had one active span on a dual PRI card. This week we ordered the > second span and attempted to put it into service. However, the instant I > plugged the span into the second port of the dual PRI card, it caused all > the calls on the first span to drop. After a few seconds, calls start > coming in on the first span again but are dropped after a few seconds. All > the calls seem to drop simultaneously. I talked to the guys at the switch > about it and they said it looked like it was related to signalling which > would make sense since I'm using NFAS to share the D channel between the two > spans. The configuration on the card looks okay and I have compared it with > configurations on other cards I have had in service for over a year. All > code is up to date. The other strange thing is the carrier and channels > seem to come up on the second span but the DS1 terminator box that the telco > installed indicates that AMI framing is being used. But I thought the > carrier wouldn't even come up if the framing was incorrect (I have it set on > the PRI Card as b8zs, wihch is what it should be). > > Error counters for the second span are through the roof according to the CLI > on the PRI card. > > Has anybody seen this before? At this point I'm not sure if it's the line > has been provisioned wrong by the telco or if my PRI card is bad. In my > experience, I thought the carrier on the ds1 wouldn't even come up if the > line was provisioned wrong. Any ideas? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Works great, so far...... One of my DSP's didn't take the upgrade well. Had to pull out the NAC to force reboot. Worked great after that. On Thu, 18 Mar 1999, Robert J. Adams wrote: > Hello, > > Anyone tried the new 1.2.43 code yet? > > -j > > --- > Robert J. Adams radams@siscom.net http://www.siscom.net > Looking to outsource news? http://www.newshosting.com > SISCOM Network Administration - President, SISCOM Inc. > Phone: 937-222-8150 FAX: 937-222-8153 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I *think* this is possible. It's called trunk group overflow and the cost here is $150 per arrangment. On Fri, 19 Mar 1999, d baud wrote: > I am currently trying to switch to another PRI provider, and to do a > gradual move of all my PRIs I would need to have my old PRIs to overflow > (when busy) to some other PRIs in another Central Office (in the same > area code). > The two telcos say that it is technically impossible to program this > feature on the DMS since it is not in the same Central Office. Could > someone confirm if this is true ? > > Also, would you say that it would be possible to have the old telco PRI > to overflow to a centrex line in the same CO. And then program the > centrex line to forward calls to the phone number of the other PRI of > the other telco ? > > D Baud > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Just to let everybody know, I have updated my tcview script to 0.92, which has many improvements, but keep in mind since I don't have access to some types of Total Control equipment, I must rely on your results to improve the script. The improvements: Now should support 30 channel DSP cards as well as 24. Now should support older firmware. Now should support Netserver. Now it can make an educated guess if the chassis/NMC is Hiper or not. And most importantly, it should work with more flavors of CMU-SNMP. Most people had problems with the chassis being drawn, but no LEDs lighting up... this should be fixed by the CMU-SNMP coding change. I am currently working on a readme, describing the script... which should be online sometime tonight... but the new script itself is online already at http://www.dandy.net/~amadei Email me if you have problems, praises, spare cash... ;-) ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

On Fri, 19 Mar 1999, Mike Andrews wrote: > I know DNIS is being received OK because we've been using it for other > accounting stuff for forever. Init string is &K0S51.6=1S76.1=1S81.5=1 > (without the leading AT). Do you maybe have the leading AT on yours? > Mdm.mib says it shouldn't be there. mib must be incorrect, I couldn't get it to work until I added the AT prefix. Speaking of problems with the docs... There's an item called 'Fallback disable' (under signal converter settings). It is either enabled or disabled. If I set it to 'enabled', have I set the thing to enable fallbacks, or have I set it to enable the disabling of fallbacks?

Has anyone seen problems with Creative Labs DI5601 Kflex/V.90 modems Labs DI5601 Kflex/V.90 modems connecting to Total Control systems ? We have a customer who's modem will train and train but never connect. It shows unauthenticated in RADIUS. I've look on all of the 56K modem web pages and noone says much about this beast. I went to www.modemblaster.com, Creative Lab's website, and it was useless. No manual to even look for init commands or anything. I am running 4.1.62-4 of HiPerArc code with Quads running 5.10.9 code across PRIs. Thanks, Jeff Binkley ASA Network C

I remember reading lots about this on the list a few months back, and now I am becoming convinced it's happening to me at one of my pops (pop is a HARC/HDSP chassis, all PRI circuits). Symptoms: * Customer calls lead number and gets "nothing" or "dead air". Customer * retries call and occasionally gets the same thing, then suddenly symptom * vanishes and customer is able to connect. Test calls from our NOC * occasionally do the same thing. Sometimes the dead air lasts for several * minutes, sometimes it disappears almost immediately (and of course, most of * the time we can't reproduce it at all). * The HDSP's "No Idle Modem Available" counters are incrementing, especially * those cards that are first in the hunt group. The increment is slow * (and I'm beginning to feel, related). All the DSP cards are set to "Round Robin." IIRC from this list, someone once mentioned something about the telco signaling a new call on a PRI _before_ the HDSP has officially "released" the last modem available on a full circuit; and thus no modems are available to take the call. Any ideas on settings I can confirm/ask the telco about? For reference, the switch is a DMS100. Thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. 800-496-4736 (ext 106) * Finger jss@evcom.net for my PGP Public Key *

If 4% can't connect at all, how did they fill out the survey? Or did you mail it to them? My experience is that asking them what is going on is a bad thing. The connection is NEVER fast enough, the ALWAYS get disconnected, etc. Check your logs to back up the data.... you may be suprised. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Thu, 18 Mar 1999, Mike Hamrich wrote: > OK HiperArc with latest code 3/4/99 > > Since the "upgrade" we are having tons of connection issues. > Couriers can't connect > Owners of Sporsters flashed with Feb '99 v.90 code connect slower > OEM/Brown box Sportsters can't stay connected > > We also told owner of non X2 modem to go elsewere. > > We surveyed our users, 248 replied so far: > 67% say slower speed, 22% are having problems saying connected, 4% can't > connect at all, and ONLY 7% report better connection. > > We have PRI lines, Set PPP offloading to no, Authenticate ANY Preferrd PAP > > Any other ideas to make this stuff work as well as the old stuff did? > > Thanks in advance for you help > > Mike Hamrich > CIO, DrFast.Net, Inc. > (216) 797-1040 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I've seen this fly on the mailing list in the past, but it's been a while now. If I wanted to stick a second radius server entry in the ARC, the default behaviour is to switch to the second if the first one fails; that switch is permanent until the secondary goes offline for some reason. What's the procedure to auth off the 2nd server ONLY IF the primary goes down? (ie: how do you get it to switch back to the 1st automatically) Thanks. -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 You have acquired a scroll entitled 'irk gleknow mizk'(n).--More-- This is an IBM Manual scroll.--More-- You are permanently confused. -- Dave Decot

On Sat, 20 Mar 1999, Gilles Melanson wrote: > What's the procedure to auth off the 2nd server ONLY IF the primary goes > down? (ie: how do you get it to switch back to the 1st automatically) I, too, anxiously await this tidbit of knowledge... temporarily killing off the backup RADIUS server is getting old. ;-) ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

If I'm looking at the right setup script, this is what I have, and it acheives the desired behaviour... set accounting_backup primary first_server 10.0.0.1 set accounting_backup primary first_secret "secretsecret" set authENTICATION secondarY_serVER 10.1.0.1 set autHENTICATION secondary_secRET "secretsecret" set radIUS autHENTICATION_ALGORITHM fall_THROUGH show authen show account Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Sat, 20 Mar 1999, Stephen Amadei wrote: > On Sat, 20 Mar 1999, Gilles Melanson wrote: > > > What's the procedure to auth off the 2nd server ONLY IF the primary goes > > down? (ie: how do you get it to switch back to the 1st automatically) > > I, too, anxiously await this tidbit of knowledge... temporarily killing > off the backup RADIUS server is getting old. ;-) > > ----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. >

On Sat, 20 Mar 1999, Lon R. Stockton, Jr. wrote: > > On Fri, 19 Mar 1999, Mike Andrews wrote: > > > I know DNIS is being received OK because we've been using it for other > > accounting stuff for forever. Init string is &K0S51.6=1S76.1=1S81.5=1 > > (without the leading AT). Do you maybe have the leading AT on yours? > > Mdm.mib says it shouldn't be there. > > mib must be incorrect, I couldn't get it to work until I added the AT > prefix. Sure enough, that took care of it. Thanks... you just saved us a TON of hassle (and possibly some money we were considering putting into a PM3)... > Speaking of problems with the docs... > > There's an item called 'Fallback disable' (under signal converter > settings). It is either enabled or disabled. If I set it to 'enabled', > have I set the thing to enable fallbacks, or have I set it to enable > the disabling of fallbacks? Heh. I'm not sure, but I've just left that at the default. I wouldn't think you'd ever want to disable fallbacks.. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

That model uses the Rockwell PCI chipset if I am correct 2.1.2.12x Customer must use AT+MS=V90 or AT+MS=V34 to get connected. > Has anyone seen problems with Creative Labs DI5601 Kflex/V.90 modems Labs > DI5601 Kflex/V.90 modems > connecting to Total Control systems ? We have a customer who's modem > will train and train but never connect. It shows unauthenticated in > RADIUS. > I've look on all of the 56K modem web pages and noone says much about > this beast. I went to www.modemblaster.com, Creative Lab's website, and > it was useless. No manual to even look for init commands or anything. > I am running 4.1.62-4 of HiPerArc code with Quads running 5.10.9 code > across PRIs. > Thanks, > Jeff Binkley > ASA Network 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.

Thanks but no luck. When I had the user add this, Dialup networking says the modem no longer responds (i.e. doesn't understand command). I also tried -V90=0. Same results. I told them to call Creative Labs or take it back for a trade on another brand. Anyone else have ideas on this one ? Jeff U>That model uses the Rockwell PCI chipset if I am correct 2.1.2.12x U>Customer must use AT+MS=V90 or AT+MS=V34 to get connected. U>> Has anyone seen problems with Creative Labs DI5601 Kflex/V.90 modems U>> Labs DI5601 Kflex/V.90 modems U>> connecting to Total Control systems ? We have a customer who's U>> modem will train and train but never connect. It shows U>> unauthenticated in RADIUS. U>> I've look on all of the 56K modem web pages and noone says much U>> about this beast. I went to www.modemblaster.com, Creative Lab's U>> website, and it was useless. No manual to even look for init U>> commands or anything. I am running 4.1.62-4 of HiPerArc code with U>> Quads running 5.10.9 code across PRIs. U>> Thanks, U>> Jeff Binkley U>> ASA Network C CMPQwk 1.42-21 9999

We are having a problem of users dialing up and getting no response from our Hyperarc with DSP modems. Looked in Total Control it appears that in slot 1 modem 7&8 show and "abnormal disconnect77" error for reason for call failure and no users are able to log on to those modems. Have tried resetting the ports, but it did no good. Any ideas!!! Is this a modem going bad or could a reset of the card be in order here. Greg Owens Magnolia Internet Services

Users that could not connect were ask the questions on the phone in between the threats to leave us. Most of these clients have been with us over 2 years, and the logs back up that this "upgrade" is the worst thing we have done. Is anyone running this stuff sucessfully? If so it must be something with our setup or the Telco. You are right, only negatives will fill out survey online, and the logs show that the ones that can stay connected do achive 6-22K faster than they think. -----Original Message----- >If 4% can't connect at all, how did they fill out the survey? Or did you >mail it to them? > >My experience is that asking them what is going on is a bad thing. The >connection is NEVER fast enough, the ALWAYS get disconnected, etc. > >Check your logs to back up the data.... you may be suprised. > >Paul D. Farber II >Farber Technology >Ph. 570-628-5303 >Fax 570-628-5545 >farber@admin.f-tech.net > >On Thu, 18 Mar 1999, Mike Hamrich wrote: > >> OK HiperArc with latest code 3/4/99 >> >> Since the "upgrade" we are having tons of connection issues. >> Couriers can't connect >> Owners of Sporsters flashed with Feb '99 v.90 code connect slower >> OEM/Brown box Sportsters can't stay connected >> >> We also told owner of non X2 modem to go elsewere. >> >> We surveyed our users, 248 replied so far: >> 67% say slower speed, 22% are having problems saying connected, 4% can't >> connect at all, and ONLY 7% report better connection. >> >> We have PRI lines, Set PPP offloading to no, Authenticate ANY Preferrd PAP >> >> Any other ideas to make this stuff work as well as the old stuff did? >> >> Thanks in advance for you help >> >> Mike Hamrich >> CIO, DrFast.Net, Inc. >> (216) 797-1040 >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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.

----Original Message----- >On Fri, 19 Mar 1999, Jeff Binkley wrote: >> Krish, >> Note he has Preferred set to PAP which may be a problem with >quads as you and I discovered the other day. We only have Quads installed >Well he is using DSP for the most part and also he is complaing >about speed and through put. Disabling ppp offloading does slow No DSP installed yet, only the quads > I have not heard from him and I also offered to work with him to find >out if he has the quad or the DSP, no answer from him yet. Thank you very much about offer. Sorry been out with Kidney stone. Im not complaing about throughput, users report slower initial connect rate then with old Netserver/X2 modem code though. I just need to set things up so they do not get dissconnected. Im sure it's a setting on our side or a telco issue. Will set PPP enable and the accm like you said. Is it possible that our TC Chassi is too old to handle this upgrade? It's 2 years old, has combination of Quad analog and digital cards.

>Re-enabled ppp offloading and disabled ppp receive_accm as it is >|recomended in the release notes of 4.1.59-6. >|After doing this, we started receiving a rash of NT people getting >|blocked at the PAP authentication. Fortunately, this problem can >|fixed by disabling the LCP Extensions on the NT machine. Just LCP or do you have to turn off compression and header cmp also? With offloading disable we did seem to fix the NT users gripes. >You should leave the settings as sugested in the release notes. NT >has its own problems, not the TCH. NT should have failed >reguardless of the offloading setting. If you dissable PPP offloading >you may run back into the "WebRamp"/PAP When users that were OK with NT and old Netserver based TCH have to be called in mass to make changes. It is TCH problem, and what do you do about webramps? Is there anyway to make the Hiperarc's works at least as good netserver base TCH's

Blake, before you did the upgrade how did you have the NMC set to answer ISDN calls, on the Quads or the Netserver? -----Original Message----- >ARC 4.1.59-6 >DSP 1.2.43 > >The only thing we having problems with are ISDN calls. Analog >current link transmit rates are anywhere from 14,400 to 53,300. >But i haven't seen a single ISDN call get established and pass >data. mon ppp, and mon radius show nothing - "li co" will show >the modem being tied up but after about 10 seconds it drops. I >had a few ISDN customers connected with 4.1.59 and 1.2.59 but >as soon as I upgraded the DSP to 1.2.43 things went downhill. > >[1 hour goes by] > >and at 7:30 my pager goes nuts saying that all our dedicated >ISDN customers are back up. during this time i have been >gathering statistics from the incomplete ISDN calls and then >many dedicated customers with ISDN devices from many different >vendors begin working again without any intervention from me. >Ah! and everything came back up about the same time last night! > >WHAT THE HELL??!?!?! > >any similar experiences? TELCO sabotage? > >blake > > >> -----Original Message----- >> From: Mike Hamrich [mailto:mhamrich@drfast.net] >> Sent: Thursday, March 18, 1999 7:21 PM >> To: usr-tc@lists.xmission.com >> Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect >> >> >> OK HiperArc with latest code 3/4/99 >> >> Since the "upgrade" we are having tons of connection issues. >> Couriers can't connect >> Owners of Sporsters flashed with Feb '99 v.90 code connect slower >> OEM/Brown box Sportsters can't stay connected >> >> We also told owner of non X2 modem to go elsewere. >> >> We surveyed our users, 248 replied so far: >> 67% say slower speed, 22% are having problems saying >> connected, 4% can't >> connect at all, and ONLY 7% report better connection. >> >> We have PRI lines, Set PPP offloading to no, Authenticate ANY >> Preferrd PAP >> >> Any other ideas to make this stuff work as well as the old stuff did? >> >> Thanks in advance for you help >> >> Mike Hamrich >> CIO, DrFast.Net, Inc. >> (216) 797-1040 >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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.

Interestingly enough, that's what the switch dudes thought at first but they found something more interesting first. It seems that when you set up two PRI circuits with separate signalling channels, they are classified as separate trunk groups. That makes sense. When you are sharing a D channel with NFAS it is classified as one trunk group and the trunks have to be enumerated properly. For some strange reason, it doesn't work very well when you enumerate the first 23 channels from 1 to 23 and then enumerate the trunks on the second PRI 1 to 24(as opposed to 24 to 47). Gee. Imagine that. As consolation for so much wasted time, I got to go back to my boss and bash the telco for being stupid. There's always a silver lining... On Saturday, March 20, 1999 12:31 AM, GTI x2 Tech [SMTP:x2@apollo.gti.net] wrote: > > I had the same exact problem and it took me and Bell Atlantic 3 weeks to > figure out it was a "bad house cable" in other words a bad pair. > > Tell them the reason the 1st span drops it that it is causing too much > noise on the 1st circuit and causes it to drop. > > Just have the telco change the pair that its on (if you have multiple) if > not then have them install a brand new sheilded line in from the > smartjack. >

I while back someone posted a suggestion about a way to divide a single class C for maximum efficiency for a pop, and was wondering if anyone remembers. I would like to use 2 class C's, for 2 chassis, with a max of 10 hdm's per chassis, it looks messy, but the best I can get is this, which isn't quite enough: 208.232.62.0/28 router, switch, arcs, nmc's (1 router, 1 switch, 2 nmc's, 4 arc's) Hub 1 Arc 1 ============= 208.232.62.16/28 pool1 16 208.232.62.32/27 pool2 32 208.232.62.64/26 pool3 64 208.232.62.128/29 pool4 8 ------------ 120 (23channels x 5hdms needs at least 115) Hub 1 Arc 2 ============= 208.232.62.136/29 pool5 8 208.232.62.144/28 pool6 16 208.232.62.160/27 pool7 32 208.232.62.192/26 pool8 64 ------------ 120 (23channels x 5hdms needs at least 115) Hub 2 Arc 1 ============= 208.232.63.0/25 pool9 128 Hub 2 Arc 2 ============= 208.232.63.128/25 pool10 128 Is the above really the best way to do it, if I want to use no address space other than the 2 /24's? It looks ugly that many pools, but perhaps its efficient and really a good solution, if anyone has any comments, that would be great, or even better, a better solution would be great as well. Also, can anyone see any problems with the above? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dale Hege |Sent: Monday, March 22, 1999 9:16 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) TCM View | | | |Does anyone know what variables TCM polls to find out if a card is to be |shown in yellow? | It goes yellow when it cant talk to the card. (ie no responce). -M

Does anyone know what variables TCM polls to find out if a card is to be shown in yellow? -Dale

On Mon, 22 Mar 1999, Jeff Soetemans wrote: > Is it possible for the dual arc configuration in the fully loaded DSP > chassis to back up each other in the event one arc card dies. I've heard > from one source it's not possible and another source says it's possible > if you only run 10 DSP's in the chassis. I am confused on this also. It would be great if when Arc #2 fails Arc #1 could just become the owner of all the cards in the chasis, and press on. I am not sure how IP pools would be handled though, I suppose for it to work 100% Arc #1 would have to assume any ip pools that were handled by arc #2. brian > Thanks, > Jeff > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

Dead Air happens when one of the modems of the DSP has not recycled before the PRI part of the HDSP acknowledges the "CALL SETUP" command from the switch. The only method to reduce this is to set the modems to "Fixed Assignment" and set the switch to "round-robin". The weirdness about this is that the dead air is even Q.931 compliant. Background on Q.931 if I remember everything correctly When call comes in, switch sends "CALL SETUP" to equipment. Equipment sends "CALL PROCEEDING" or "ALERT" (depends on code version in the HDSP) within 1 second Switch sends "CONNECT" and that's it... In case of no acknowledge from the equipment, switch sends "CALL CLEAR", if no answer, it tears down the DS0 or the DS1 (depending on the switch) and sends alarms everywhere. If you need more low-level info, check out document ETS 300 102-2 for ISDN basic call control (http://www.etsi.org) Hope this helps, Robert > -----Original Message----- > From: Jesse Sipprell [SMTP:jss@evcom.net] > Sent: samedi, 20. mars 1999 19:44 > To: usr-tc@lists.xmission.com > Subject: (usr-tc) HDSP "Dead Air" > > I remember reading lots about this on the list a few months back, and now > I am > becoming convinced it's happening to me at one of my pops (pop is a > HARC/HDSP > chassis, all PRI circuits). > > Symptoms: > > * Customer calls lead number and gets "nothing" or "dead air". Customer > * retries call and occasionally gets the same thing, then suddenly symptom > * vanishes and customer is able to connect. Test calls from our NOC > * occasionally do the same thing. Sometimes the dead air lasts for > several > * minutes, sometimes it disappears almost immediately (and of course, most > of > * the time we can't reproduce it at all). > > * The HDSP's "No Idle Modem Available" counters are incrementing, > especially > * those cards that are first in the hunt group. The increment is slow > * (and I'm beginning to feel, related). > > All the DSP cards are set to "Round Robin." IIRC from this list, someone > once > mentioned something about the telco signaling a new call on a PRI _before_ > the > HDSP has officially "released" the last modem available on a full circuit; > and > thus no modems are available to take the call. > > Any ideas on settings I can confirm/ask the telco about? For reference, > the > switch is a DMS100. > > Thanks! > > -- > Jesse Sipprell > Technical Operations Director > Evolution Communications, Inc. > 800-496-4736 (ext 106) > > * 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.

Is it possible for the dual arc configuration in the fully loaded DSP chassis to back up each other in the event one arc card dies. I've heard from one source it's not possible and another source says it's possible if you only run 10 DSP's in the chassis. Thanks, Jeff

> > > I just upgraded one of my TC racks with the HiperArc upgrade. Everything > went fine except all my ISDN router users (mainly Livingston ORU's and one > Ascend 50) with subnets cant connect. The error that they all get is > this: (from the ORU side) > > S2: Couldn't find CHAP user HiPer > The portmaster is looking for the user with system password as name. You have to do this. On the hiper arc create a user with the system name of the portmaster and with a password ( say x) on the port master create a user with the username of HiPer and the password (x) krish > > Do I have to activate something? I have a user using Linux and his subnet > works fine. It seems only to effect people with stand-alone ISDN routers. > > Debug info follows. > > TIA, > > John > > > > > Sending LCP_CONFIGURE_REQUEST to port S2 of 25 bytes containing: > 01 01 00 19 05 06 87 2B AB F9 11 04 06 1C 12 02 13 09 03 00 C0 05 03 1F FE > Packet Info: Code: 0x01, ID: 0x01, 25 bytes. > Magic-Number [0x05], length: (6 bytes), [0x872BABF9] > Multilink-MRRU [0x11], length: (4 bytes), [0x061C] > Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes. > Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes) > Multilink-Endpoint-Discriminator [0x13], length: (9 bytes), > [0x0300C005031FFE] > Class [0x03]: IEEE 802.1 MAC Address 00 C0 05 03 1F FE > Received LCP_CONFIGURE_REQUEST on port S2 of 26 bytes containing: > 01 01 00 1E 01 04 05 EA 03 05 C2 23 05 05 06 20 D7 29 EB > 07 02 08 02 11 04 05 EA 13 03 00 Packet Info: Code: 0x01, ID: > 0x01, 30 bytes. > Maximum-Receive-Unit [0x01], length: (4 bytes) 1514 bytes [0x05EA] > Authentication-Protocol [0x03], length: (5 bytes), Challenge > Handshake Authentication Protocol [0xC22305] > CHAP using MD5 encryption algorithm > Magic-Number [0x05], length: (6 bytes), [0x20D729EB] > Protocol-Field-Compression [0x07], length: (2 bytes) > Address-and-Control-Field-Compression [0x08], length: (2 bytes) > Multilink-MRRU [0x11], length: (4 bytes), [0x05EA] > Max-Receive-Reconstructed-Unit (MRRU): 1514 bytes. > Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00] > Class [0x00]: Null Class Null Address > Sending LCP_CONFIGURE_ACK to port S2 of 30 bytes containing: > 02 01 00 1E 01 04 05 EA 03 05 C2 23 05 05 06 20 D7 29 EB > 07 02 08 02 11 04 05 EA 13 03 00 Packet Info: Code: 0x02, ID: > 0x01, 30 bytes. > Maximum-Receive-Unit [0x01], length: (4 bytes) 1514 bytes [0x05EA] > Authentication-Protocol [0x03], length: (5 bytes), Challenge > Handshake Authentication Protocol [0xC22305] > CHAP using MD5 encryption algorithm > Magic-Number [0x05], length: (6 bytes), [0x20D729EB] > Protocol-Field-Compression [0x07], length: (2 bytes) > Address-and-Control-Field-Compression [0x08], length: (2 bytes) > Multilink-MRRU [0x11], length: (4 bytes), [0x05EA] > Max-Receive-Reconstructed-Unit (MRRU): 1514 bytes. > Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00] > Class [0x00]: Null Class Null Address > Received LCP_CONFIGURE_REJECT on port S2 of 2 bytes containing: > 04 01 00 06 12 02 Packet Info: Code: 0x04, ID: 0x01, 6 bytes. > Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes) > Sending LCP_CONFIGURE_REQUEST to port S2 of 23 bytes containing: > 01 02 00 17 05 06 87 2B AB F9 11 04 06 1C 13 09 03 00 C0 05 03 1F FE > Packet Info: Code: 0x01, ID: 0x02, 23 bytes. > Magic-Number [0x05], length: (6 bytes), [0x872BABF9] > Multilink-MRRU [0x11], length: (4 bytes), [0x061C] > Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes. > Multilink-Endpoint-Discriminator [0x13], length: (9 bytes), > [0x0300C005031FFE] > Class [0x03]: IEEE 802.1 MAC Address 00 C0 05 03 1F FE > Received LCP_CONFIGURE_ACK on port S2 of 19 bytes containing: > 02 02 00 17 05 06 87 2B AB F9 11 04 06 1C 13 09 03 00 C0 05 03 1F FE > Packet Info: Code: 0x02, ID: 0x02, 23 bytes. > Magic-Number [0x05], length: (6 bytes), [0x872BABF9] > Multilink-MRRU [0x11], length: (4 bytes), [0x061C] > Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes. > Multilink-Endpoint-Discriminator [0x13], length: (9 bytes), > [0x0300C005031FFE] > Class [0x03]: IEEE 802.1 MAC Address 00 C0 05 03 1F FE > **** S2: LCP Open > Sending IPCP_CONFIGURE_REQUEST to port S2 of 10 bytes containing: > 01 01 00 0A 03 06 D0 D8 7C 81 Packet Info: Code: 0x01, ID: 0x01, 10 > bytes. > IP-Address [0x03], length: (6 bytes), [208.216.111.111] > Received CHAP_CONF_CHALLENGE on port S2 of 26 bytes containing: > 72 > Packet Info: Code: 01, ID: 02, 26 bytes. > ValSize[0x10]: (16 bytes), Value: > [0xBA02BEFAE8AB07EBE1E4F] > Name: HiPer [0x4869506572] > S2: Couldn't find CHAP user HiPer > > Received LCP_PROTOCOL_REJECT on port S2 of 12 bytes containing > 08 03 00 10 80 21 01 01 00 0A 03 06 D0 D8 7C 81 > Packet Info: Code: 0x08, ID: 0x03, 16 bytes. > Rejected Protocol: [0x8021], Internet Protocol Control Protocol > 01 01 00 0A 03 06 D0 D8 7C 81 Packet Info: Code: 0x01, ID: 0x01, 10 > bytes. > IP-Address [0x03], length: (6 bytes), [208.216.111.111] > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I just upgraded one of my TC racks with the HiperArc upgrade. Everything went fine except all my ISDN router users (mainly Livingston ORU's and one Ascend 50) with subnets cant connect. The error that they all get is this: (from the ORU side) S2: Couldn't find CHAP user HiPer Do I have to activate something? I have a user using Linux and his subnet works fine. It seems only to effect people with stand-alone ISDN routers. Debug info follows. TIA, John Sending LCP_CONFIGURE_REQUEST to port S2 of 25 bytes containing: 01 01 00 19 05 06 87 2B AB F9 11 04 06 1C 12 02 13 09 03 00 C0 05 03 1F FE Packet Info: Code: 0x01, ID: 0x01, 25 bytes. Magic-Number [0x05], length: (6 bytes), [0x872BABF9] Multilink-MRRU [0x11], length: (4 bytes), [0x061C] Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes. Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes) Multilink-Endpoint-Discriminator [0x13], length: (9 bytes), [0x0300C005031FFE] Class [0x03]: IEEE 802.1 MAC Address 00 C0 05 03 1F FE Received LCP_CONFIGURE_REQUEST on port S2 of 26 bytes containing: 01 01 00 1E 01 04 05 EA 03 05 C2 23 05 05 06 20 D7 29 EB 07 02 08 02 11 04 05 EA 13 03 00 Packet Info: Code: 0x01, ID: 0x01, 30 bytes. Maximum-Receive-Unit [0x01], length: (4 bytes) 1514 bytes [0x05EA] Authentication-Protocol [0x03], length: (5 bytes), Challenge Handshake Authentication Protocol [0xC22305] CHAP using MD5 encryption algorithm Magic-Number [0x05], length: (6 bytes), [0x20D729EB] Protocol-Field-Compression [0x07], length: (2 bytes) Address-and-Control-Field-Compression [0x08], length: (2 bytes) Multilink-MRRU [0x11], length: (4 bytes), [0x05EA] Max-Receive-Reconstructed-Unit (MRRU): 1514 bytes. Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00] Class [0x00]: Null Class Null Address Sending LCP_CONFIGURE_ACK to port S2 of 30 bytes containing: 02 01 00 1E 01 04 05 EA 03 05 C2 23 05 05 06 20 D7 29 EB 07 02 08 02 11 04 05 EA 13 03 00 Packet Info: Code: 0x02, ID: 0x01, 30 bytes. Maximum-Receive-Unit [0x01], length: (4 bytes) 1514 bytes [0x05EA] Authentication-Protocol [0x03], length: (5 bytes), Challenge Handshake Authentication Protocol [0xC22305] CHAP using MD5 encryption algorithm Magic-Number [0x05], length: (6 bytes), [0x20D729EB] Protocol-Field-Compression [0x07], length: (2 bytes) Address-and-Control-Field-Compression [0x08], length: (2 bytes) Multilink-MRRU [0x11], length: (4 bytes), [0x05EA] Max-Receive-Reconstructed-Unit (MRRU): 1514 bytes. Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00] Class [0x00]: Null Class Null Address Received LCP_CONFIGURE_REJECT on port S2 of 2 bytes containing: 04 01 00 06 12 02 Packet Info: Code: 0x04, ID: 0x01, 6 bytes. Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes) Sending LCP_CONFIGURE_REQUEST to port S2 of 23 bytes containing: 01 02 00 17 05 06 87 2B AB F9 11 04 06 1C 13 09 03 00 C0 05 03 1F FE Packet Info: Code: 0x01, ID: 0x02, 23 bytes. Magic-Number [0x05], length: (6 bytes), [0x872BABF9] Multilink-MRRU [0x11], length: (4 bytes), [0x061C] Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes. Multilink-Endpoint-Discriminator [0x13], length: (9 bytes), [0x0300C005031FFE] Class [0x03]: IEEE 802.1 MAC Address 00 C0 05 03 1F FE Received LCP_CONFIGURE_ACK on port S2 of 19 bytes containing: 02 02 00 17 05 06 87 2B AB F9 11 04 06 1C 13 09 03 00 C0 05 03 1F FE Packet Info: Code: 0x02, ID: 0x02, 23 bytes. Magic-Number [0x05], length: (6 bytes), [0x872BABF9] Multilink-MRRU [0x11], length: (4 bytes), [0x061C] Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes. Multilink-Endpoint-Discriminator [0x13], length: (9 bytes), [0x0300C005031FFE] Class [0x03]: IEEE 802.1 MAC Address 00 C0 05 03 1F FE **** S2: LCP Open Sending IPCP_CONFIGURE_REQUEST to port S2 of 10 bytes containing: 01 01 00 0A 03 06 D0 D8 7C 81 Packet Info: Code: 0x01, ID: 0x01, 10 bytes. IP-Address [0x03], length: (6 bytes), [208.216.111.111] Received CHAP_CONF_CHALLENGE on port S2 of 26 bytes containing: 72 Packet Info: Code: 01, ID: 02, 26 bytes. ValSize[0x10]: (16 bytes), Value: [0xBA02BEFAE8AB07EBE1E4F] Name: HiPer [0x4869506572] S2: Couldn't find CHAP user HiPer Received LCP_PROTOCOL_REJECT on port S2 of 12 bytes containing 08 03 00 10 80 21 01 01 00 0A 03 06 D0 D8 7C 81 Packet Info: Code: 0x08, ID: 0x03, 16 bytes. Rejected Protocol: [0x8021], Internet Protocol Control Protocol 01 01 00 0A 03 06 D0 D8 7C 81 Packet Info: Code: 0x01, ID: 0x01, 10 bytes. IP-Address [0x03], length: (6 bytes), [208.216.111.111]

Dale Hege <fhege@sover.net> writes: > Does anyone know what variables TCM polls to find out if a card is to be > shown in yellow? I don't have TCM source, but there are really only two likely possibilities: * The value from querying uchasEntityOperStatus for the card level entity (or in the case of a quad modem card, the status for the individual modems - or perhaps just the first modem, since there is no card level manageable entity on such cards). This object reflects whether or not the NMC can communicate successfully to the particular entity and thus whether or not information can be queried or set for that entity. * The "failed" bit in the LED status query for the chassis, which indicates whether or not a card is operational. The most significant bit of each of the 12 nibbles (6 byte block) in the LED state query (uchasFrontPanelLedStates) is used for status information. The first three MSBs, if set, represent that the slot has a card, it has been discovered, and something on it is failed, respectively. So if the first two MSBs indicate presence and identification, but the third MSB is set, then uchasEntityOperStatus is something other than "operational" for at least one entity on that slot. You can just check the third MSB directly, since it won't be set if the slot is empty or not discovered. If I had to bet I'd guess the LED state information is used, since all TCM does is draw the card in yellow - it doesn't try to actually tell you what the non-operational state is (which would require querying the specific uchasEntityOperStatus objects for the appropriate entities). Also, the LED state query is faster and TCM would already have queried it in order to draw the chassis. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

How i configure a HiperARC to assign DHCP address? I have installed Total Control Security and Accounting server in windows NT 4.0. -- _______________________________ Ing. Abraham N. Aldaco Gast�lum Telecomunicaciones y Redes ITESM CSN

I am trying to assign a static IP and keep getting this error in syslogs. I can not find where and overlap would exist. Can someone shed some light? Worked fine until I stuck in a ARC. At 14:19:39, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt(): Invalid Configuration, Address range overlap - IP address (XXX.XXX.XXX.XXX) TIA Sean Herr @YourNET Connection, Inc. 847-524-3900 http://www.ync.net

On Mon, 22 Mar 1999, Sean Herr wrote: > I am trying to assign a static IP and keep getting this error in syslogs. I > can not find where and overlap would exist. Can someone shed some light? > Worked fine until I stuck in a ARC. > > At 14:19:39, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt(): Invalid > Configuration, > Address range overlap - IP address (XXX.XXX.XXX.XXX) > What is the netmask you are using for this users? Looks like you are giving the user a invalid netmask. krish > TIA > > > Sean Herr > @YourNET Connection, Inc. > 847-524-3900 > http://www.ync.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. >

This is a multi-part message in MIME format. ------=_NextPart_000_00B8_01BE747E.D47521A0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I was asking my telco if they could pass both ANI and DNIS digits so I = would have both calling station id and called station id. This is on a T1 vs = a PRI. In trying it out, it looks like it is putting the Calling Station = ID into the DNIS digits, and there is nothing in the ANI digits. Do I need = to choose one over the other? Also, is there a difference in capabilities between the mftones and dtmftones setup? Right now it is using mftones because the telco = thought it would work better for this. Thanks for any info. Randy McMillan PacInfo ------=_NextPart_000_00B8_01BE747E.D47521A0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"text/html; charset=3Dwindows-1252" = http-equiv=3DContent-Type> <META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>I was asking my telco if they could = pass both ANI=20 and DNIS digits so I would<BR>have both calling station id and called = station=20 id.&nbsp; This is on a T1 vs a<BR>PRI.&nbsp; In trying it out, it looks = like it=20 is putting the Calling Station ID<BR>into the DNIS digits, and there is = nothing=20 in the ANI digits.&nbsp; Do I need to<BR>choose one over the = other?<BR>Also, is=20 there a difference in capabilities between the mftones and<BR>dtmftones=20 setup?&nbsp; Right now it is using mftones because the telco thought = it<BR>would=20 work better for this.&nbsp; Thanks for any info.<BR><BR>Randy=20 McMillan<BR>PacInfo<BR></FONT></DIV></BODY></HTML> ------=_NextPart_000_00B8_01BE747E.D47521A0--

On Sat, 20 Mar 1999, Lon R. Stockton, Jr. wrote: > On Fri, 19 Mar 1999, Mike Andrews wrote: > > > I know DNIS is being received OK because we've been using it for other > > accounting stuff for forever. Init string is &K0S51.6=1S76.1=1S81.5=1 > > (without the leading AT). Do you maybe have the leading AT on yours? > > Mdm.mib says it shouldn't be there. > > mib must be incorrect, I couldn't get it to work until I added the AT > prefix. I found the discrepancy here -- the MIB is correct for Quads. It's wrong for DSP's. DSP's want the AT. Quads don't. I'm also having a problem that maybe someone else can help with here. The above init string doesn't disable v.90/x2 correctly on the Quads. (Works great on DSP's.) If I call in with a Courier, it chokes during the handshake -- it sounds as if one side is attempting x2 (not v.90) and the other side is trying v.34. (It dies during the line frequency probe sequence, in other words.) If I call in with an LT Winmodem it seems to be more or less OK. So... What's the *correct* AT sequence to completely kill all 56K modulations on a Quad modem and leave v.34 intact? Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!"

On Mon, 22 Mar 1999, Randy McMillan wrote: > I was asking my telco if they could pass both ANI and DNIS digits so I would > have both calling station id and called station id. This is on a T1 vs a > PRI. In trying it out, it looks like it is putting the Calling Station ID > into the DNIS digits, and there is nothing in the ANI digits. Do I need to > choose one over the other? no. > Also, is there a difference in capabilities between the mftones and > dtmftones setup? Right now it is using mftones because the telco thought it > would work better for this. Thanks for any info. > > Randy McMillan > PacInfo > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

We get both here, but we had to whine to Bellsouth to get them to turn ANI on (even though it's included for free per their PRI tariff). DNIS worked out of the box. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me getting beaten by the police, put down the video camera and come help me!" On Mon, 22 Mar 1999, Randy McMillan wrote: > I was asking my telco if they could pass both ANI and DNIS digits so I would > have both calling station id and called station id. This is on a T1 vs a > PRI. In trying it out, it looks like it is putting the Calling Station ID > into the DNIS digits, and there is nothing in the ANI digits. Do I need to > choose one over the other? > Also, is there a difference in capabilities between the mftones and > dtmftones setup? Right now it is using mftones because the telco thought it > would work better for this. Thanks for any info. > > Randy McMillan > PacInfo > >

I also get both here with the exception that ANI does not come through if the user has an unpublished number or has disabled it with *68 or whichever sequence does it in your area. I tried to pursuade the telco not to block ANI in those circumstances by telling them I needed them for billing purposes and asking what they would do if I were a long distance carrier and I needed to bill for calls. They said they couldn't do it because I had to be an inter-lata carrier. On Monday, March 22, 1999 8:50 PM, Mike Andrews [SMTP:mandrews@termfrost.org] wrote: > We get both here, but we had to whine to Bellsouth to get them to turn ANI > on (even though it's included for free per their PRI tariff). DNIS worked > out of the box. > > > Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me > getting beaten by the police, put down the video camera and come help me!" > > On Mon, 22 Mar 1999, Randy McMillan wrote: > > > I was asking my telco if they could pass both ANI and DNIS digits so I would > > have both calling station id and called station id. This is on a T1 vs a > > PRI. In trying it out, it looks like it is putting the Calling Station ID > > into the DNIS digits, and there is nothing in the ANI digits. Do I need to > > choose one over the other? > > Also, is there a difference in capabilities between the mftones and > > dtmftones setup? Right now it is using mftones because the telco thought it > > would work better for this. Thanks for any info. > > > > 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.

Randy McMillan writes... >I was asking my telco if they could pass both ANI and DNIS digits so I >would have both calling station id and called station id. This is on a >T1 vs a PRI. I usually don't answer people who won't turn off MIME when posting to mailing lists, but I'm in a generous mood today. First off, I'm going to assume you mean CALLER-ID, not ANI. You can't get ANI, you can get CALLER-ID. Sure, your telco can send you both, but that would be an unusual configuration, and it's unlikely that the order writer would be able to convey that request correctly to the translations group. More likely than not, they are just going to tell you it's not possible. If you have a CLEC, they would be much more likely to do it for you. The CLEC we use can do this. Other problems are going to be that CALLER-ID isn't normally sent on a T1 as digit tones, it's sent as FSK. So you'd have to stuff CALLER-ID into the slot where ANI would go (if you were a long-distance carrier). Then you are going to need to negotiate the format, all of the KP+ST stuff, winks, digit supression, etc. It's unlikely you'd ever get it working without a T1 test set capabable of monitoring the line to see what they are sending you. -- Aaron Nabil

It was a netmask issue, but now it is doing this, any idea? At 11:01:34, Facility "Auth Facility", Level "COMMON":: The connection for call id 6730, on if slot:5/mod:1 was dropped for user UNKNOWN At 11:01:33, Facility "Auth Facility", Level "COMMON":: Port slot:5/mod:1 successful local authentication for user: jjohns -----Original Message----- Sent: Monday, March 22, 1999 4:10 PM Cc: 'usr-tc@lists.xmission.com' On Mon, 22 Mar 1999, Sean Herr wrote: > I am trying to assign a static IP and keep getting this error in syslogs. I > can not find where and overlap would exist. Can someone shed some light? > Worked fine until I stuck in a ARC. > > At 14:19:39, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt(): Invalid > Configuration, > Address range overlap - IP address (XXX.XXX.XXX.XXX) > What is the netmask you are using for this users? Looks like you are giving the user a invalid netmask. krish > TIA > > > Sean Herr > @YourNET Connection, Inc. > 847-524-3900 > http://www.ync.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.

On Tue, 23 Mar 1999, matthews wrote: > > Is it typically possible to do multiple independant hunt groups within a > single trunk group? We would like to dedicate one channel to a customer > who would dial a distinct phone number to get his dedicated modem. I posed > the question to our telco and they responded saying it was possible to > assign a POTS number to a trunk but they could not remove it from the > "main" hunt group. You can assign multiple numbers to a hunt, to hunt in on. You can put multiple trunk groups into a hunt as well, but most switches have a limit to the number of trunk groups per hunt (4 maybe?). > > I, however, have a feeling that they either aren't telling me the truth or > they don't know. > > Is anybody else doing anything like this? Another scenario might be two > distinct separate hunt groups composed of, say, 12 and 11 channels each. > Does anybody know if this is possible? > > Matthew... > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

Once upon a time Brian shaped the electrons to say... >Ok, our telco screwed up an order we had for 12 PRI's and gave us: > >PRI 1 23B+D >PRI 2-12 24B > >So I will have to run NFAS for a week or so until they can reconfigure. > >I did not see any info on NFAS in my dated HDM documentation. Please >don't tell me the HDM's cannot do NFAS :). The HDMs do not do NFAS yet. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

On Tue, 23 Mar 1999, matthews wrote: >I also get both here with the exception that ANI does not come through if >the user has an unpublished number or has disabled it with *68 or whichever >sequence does it in your area. I tried to pursuade the telco not to block >ANI in those circumstances by telling them I needed them for billing >purposes and asking what they would do if I were a long distance carrier >and I needed to bill for calls. They said they couldn't do it because I >had to be an inter-lata carrier. Check recent FCC rulings. There was something about disclosure of phone numbers by ANI some time ago. Our PBX gets ANI data but is honoring the blocking by not reporting it to the display on the phones. --Ricky

My telco has been able to do this (with a 5E switch) ... On Three PRIs... create four trunk groups: The first 22 circuits of each PRI are all bundled into one trunk group of 66 members, yet, the D-channels are not pooled. One telephone number hits any of these 66 lines. The 23rd B-channel of each PRI is in its own trunk group, and each one has its own telephone number. So, dialing the main number gets you the big pool, and the individual numbers always get the single dedicated channel. > -----Original Message----- > From: matthews [mailto:matthews@brunnet.net] > Sent: Tuesday, March 23, 1999 3:11 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) multiple hunt groups on a single trunk group > > > On Tuesday, March 23, 1999 4:58 PM, Brian > [SMTP:signal@shreve.net] wrote: > > > > You can assign multiple numbers to a hunt, to hunt in on. > You can put > > multiple trunk groups into a hunt as well, but most > switches have a limit > > to the number of trunk groups per hunt (4 maybe?). > > > > What I'd like to do is somewhat the opposite of that. We > have one "main > number" that customers dial to get access to some 300 lines, > composed of > PRI trunk groups. What I'd like to do is remove one of those > ds0's from > the main group, assign a POTS number to it, and give it to a > customer as a > "dedicated" line. Telco says it's not possible...but... >

Michael E. Ezzell writes... >My telco has been able to do this (with a 5E switch) ... On Three PRIs... >create four trunk groups: > >The first 22 circuits of each PRI are all bundled into one trunk group of 66 >members, yet, the D-channels are not pooled. One telephone number hits any >of these 66 lines. > >The 23rd B-channel of each PRI is in its own trunk group, and each one has >its own telephone number. > >So, dialing the main number gets you the big pool, and the individual >numbers always get the single dedicated channel. We do somthing simliar with both our US WEST and CLEC lines. Our pools are like -XX00, which points to one big trunk group which contains all of our lines. The -XX01, -XX02, to XX0n numbers point to trunk groups which only contain the trunks present on any particular T1. Makes testing much easier, I can't imagine not having our lines set up this way. If you switch isn't limited in how many trunk groups can be in a hunt group, you could just string the small trunk groups together. Although it takes a bit more explaining in the ordering process, I'd suggest that it's better if you can put them into two separate trunk groups as described. With the CLEC, we also have different hunting on both. If you call the XX00 main number, the calls are distributed sequentially across all of the trunks in the group so the chassis fill evenly and distribute the load. If you call the XX01 number it's just normal LO to HI fill limited to those 23 or 24 trunks. -- Aaron Nabil

matthews wrote: > Is it typically possible to do multiple independant hunt groups within a > single trunk group? We would like to dedicate one channel to a customer > who would dial a distinct phone number to get his dedicated modem. I posed > the question to our telco and they responded saying it was possible to > assign a POTS number to a trunk but they could not remove it from the > "main" hunt group. > > I, however, have a feeling that they either aren't telling me the truth or > they don't know. > > Is anybody else doing anything like this? Another scenario might be two > distinct separate hunt groups composed of, say, 12 and 11 channels each. > Does anybody know if this is possible? > > Yes, that definitely is possible. I work for an independant telco and we are > also an ISP and we are doing the exact thing you want to do. We have > dedicated accounts where the customer gets there own number to dial which > gives them there own modem (the same modem each time that is associated with > the timeslot on the incoming T1.) The telco needs to build a new CLLI for > each Number and point it to a specific trunk (DTC) The DTC is what supplies > the T1 signal to the RAS so you can point a call to any modem you want. As > far as removing the modem from the original modem pool and using it for this > dedicated number it's very simple, but they probably just won't want to do > it. Jeff > Matthew... > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

-> Is it typically possible to do multiple independant hunt groups within a -> single trunk group? We would like to dedicate one channel to a customer who -> would dial a distinct phone number to get his dedicated modem. I posed the -> question to our telco and they responded saying it was possible to assign a -> POTS number to a trunk but they could not remove it from the "main" hunt -> group. -> -> I, however, have a feeling that they either aren't telling me the truth or -> they don't know. -> -> Is anybody else doing anything like this? Another scenario might be two -> distinct separate hunt groups composed of, say, 12 and 11 channels each. -> Does anybody know if this is possible? Yes, but you do it within the TC chassis itself. If you are running HiPerArcs you can use modem groups to accomplish this. I have found it easier to do with quads and the dual pri as opposed to the HiPerDSPs, although the new DNIS screening may be the answer there. We have multiple phone numbers assigned to our hunt. Some we use like you ask, some we use for specific functions (i.e. 800 billing and signup servers) and others can be used to route to a specific host (i.e. BBS etc..) or be limited to certain modems. The trick here is to not have the same number of modems in your main modem group as you have incoming channels, otherwise you can't dedicate a connection. Once you get to a certain quantity, watch the LEC want you to buy a block of numbers instead of individual numbers. Jeff Binkley ASA Network Computing

Is it typically possible to do multiple independant hunt groups within a single trunk group? We would like to dedicate one channel to a customer who would dial a distinct phone number to get his dedicated modem. I posed the question to our telco and they responded saying it was possible to assign a POTS number to a trunk but they could not remove it from the "main" hunt group. I, however, have a feeling that they either aren't telling me the truth or they don't know. Is anybody else doing anything like this? Another scenario might be two distinct separate hunt groups composed of, say, 12 and 11 channels each. Does anybody know if this is possible? Matthew...

Ok, our telco screwed up an order we had for 12 PRI's and gave us: PRI 1 23B+D PRI 2-12 24B So I will have to run NFAS for a week or so until they can reconfigure. I did not see any info on NFAS in my dated HDM documentation. Please don't tell me the HDM's cannot do NFAS :). Usually, with NFAS, their is like an NFAS ID that you give each PRI to tell it where the D channel is at. Is this just the slot number of the SPAN that has a D channel? Or is this some sort of code you get from the telco? Thanks. Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Tuesday, March 23, 1999 4:58 PM, Brian [SMTP:signal@shreve.net] wrote: > > You can assign multiple numbers to a hunt, to hunt in on. You can put > multiple trunk groups into a hunt as well, but most switches have a limit > to the number of trunk groups per hunt (4 maybe?). > What I'd like to do is somewhat the opposite of that. We have one "main number" that customers dial to get access to some 300 lines, composed of PRI trunk groups. What I'd like to do is remove one of those ds0's from the main group, assign a POTS number to it, and give it to a customer as a "dedicated" line. Telco says it's not possible...but... > > > > > > I, however, have a feeling that they either aren't telling me the truth or > > they don't know. > > > > Is anybody else doing anything like this? Another scenario might be two > > distinct separate hunt groups composed of, say, 12 and 11 channels each. > > Does anybody know if this is possible? > > > > Matthew... > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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.

I'm about to purchase my first USR TC (HiPer bundle) and have been contemplating the support issue. I've read that the USR boxes generate a lot of heat and have a higher failure rate than most other access servers. Is there a consensus among list members on whether or not to purchase the support contract? Thanks, Dan

On Tue, 23 Mar 1999, Brian wrote: > So I will have to run NFAS for a week or so until they can reconfigure. > > I did not see any info on NFAS in my dated HDM documentation. Please > don't tell me the HDM's cannot do NFAS :). > > Usually, with NFAS, their is like an NFAS ID that you give each PRI to > tell it where the D channel is at. Is this just the slot number of the > SPAN that has a D channel? Or is this some sort of code you get from the > telco? The Total Control doesn't support NFAS. It is did, I'd used it on all my PRIs... (well, except the first... ;-) ) ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

On Tue, 23 Mar 1999, Brian wrote: > > Ok, our telco screwed up an order we had for 12 PRI's and gave us: > > PRI 1 23B+D > PRI 2-12 24B > > So I will have to run NFAS for a week or so until they can reconfigure. > > I did not see any info on NFAS in my dated HDM documentation. Please > don't tell me the HDM's cannot do NFAS :). > Currently the release code of HDM do not support NFAS. The NFAS code for DSP is in beta. You can if you wish try the beta code. krish > Usually, with NFAS, their is like an NFAS ID that you give each PRI to > tell it where the D channel is at. Is this just the slot number of the > SPAN that has a D channel? Or is this some sort of code you get from the > telco? > > 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. >

On Tue, 23 Mar 1999, Tatai SV Krishnan wrote: > On Tue, 23 Mar 1999, Brian wrote: > > > > > Ok, our telco screwed up an order we had for 12 PRI's and gave us: > > > > PRI 1 23B+D > > PRI 2-12 24B > > > > So I will have to run NFAS for a week or so until they can reconfigure. > > > > I did not see any info on NFAS in my dated HDM documentation. Please > > don't tell me the HDM's cannot do NFAS :). > > > > Currently the release code of HDM do not support NFAS. The NFAS code for > DSP is in beta. You can if you wish try the beta code. Ok, I will find out but I don't think we want to go this route, since we will be reloading a new codebase after they fix the circuits. Thanks for the info though thats good to know. > > krish > > > > Usually, with NFAS, their is like an NFAS ID that you give each PRI to > > tell it where the D channel is at. Is this just the slot number of the > > SPAN that has a D channel? Or is this some sort of code you get from the > > telco? > > > > 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. > > > Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

Could someone recommend a decent low cost v90 modem that works well with USR Total Control HiPer Arcs? Where can I find them and how much? We need 100+ modems for a promo we are doing. Thanks-Brian

On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote: > I'm about to purchase my first USR TC (HiPer bundle) and have been > contemplating the support issue. I've read that the USR boxes generate > a lot of heat and have a higher failure rate than most other access > servers. Is there a consensus among list members on whether or not to > purchase the support contract? Thanks, Dan Congrats.. I love our HiPer setup, buying two more racks in next 2 months. It may be worthwhile for the first chassis.. that way you can get access to code revisions. Past 2 DSP releases have been 'free' but who knows how long that will last. wrt heat, the HiPer DSPs run a lot cooler than a bunch of quads from what I have seen. I don't have enough TC racks nor do I have very long term experience (we put our first HiPer into service in Janurary), so I can't comment on "higher failure rate". I have had only one problem with our HiPer ARC, where the flash was either corrupted or just plain lost it, had to re-upload it... haven't done a proper post-mortem to find out why tho. --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net 918-967-2858 Give a man a fish, he eats for a day; Teach a man to fish, he eats for a lifetime; Enlighten him further, and he opens a chain of seafood restaurants

Thus spake Brian >Ok, our telco screwed up an order we had for 12 PRI's and gave us: >PRI 1 23B+D >PRI 2-12 24B >So I will have to run NFAS for a week or so until they can reconfigure. >I did not see any info on NFAS in my dated HDM documentation. Please >don't tell me the HDM's cannot do NFAS :). OK, I won't tell you that...but that will leave this message pretty much devoid of much content. :) >Usually, with NFAS, their is like an NFAS ID that you give each PRI to >tell it where the D channel is at. Is this just the slot number of the >SPAN that has a D channel? Or is this some sort of code you get from the >telco? You would assign each PRI a facility number, and the facility number would be used in the call setup information on the D channel along with the timeslot of that facility, indicating to the receiving unit which span and timeslot the call is on, rather than with facility associated signaling, where the span is already known, just the span. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake Stephen Amadei >On Tue, 23 Mar 1999, Brian wrote: >> So I will have to run NFAS for a week or so until they can reconfigure. >> >> I did not see any info on NFAS in my dated HDM documentation. Please >> don't tell me the HDM's cannot do NFAS :). >> >> Usually, with NFAS, their is like an NFAS ID that you give each PRI to >> tell it where the D channel is at. Is this just the slot number of the >> SPAN that has a D channel? Or is this some sort of code you get from the >> telco? >The Total Control doesn't support NFAS. It is did, I'd used it on all my >PRIs... (well, except the first... ;-) ) Well, that's not *entirely* true, as the dual-pri cards will do NFAS between the two PRI's on the card itself...nothing at this time in TC's will do cross-card NFAS or certainly cross-chassis. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Thus spake zip-usrtc@ran.zipcon.net >Is there a consensus among list members on whether or not to >purchase the support contract? For a single chassis, you're probably ok. When you start getting bigger, and want to only support selected equipment...sorry 'bout your luck. 3Com's support contracts have to be about the *worst* abomination I've ever seen. The restrictions that are put on them are insane, and the pricing is even worse, if that's possible. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

FWIW, out of seven chassis, we've averaged at least one failure in each. Most common were the quads. We also had a bad chassis, bad DSP (wacked-out flash), and two toasted NMC cards. This is all in a climate-controlled telco environment. As for heat, they aren't too bad really. PSI colos some TNTs near us, and the exhaust feels like a hair dryer on low. Ours run from 21 to 27 degrees celsius, 27 being the top of the rack. We're right next to a big Liebert chiller. As for the contract, forget about the support. This list is the best you'll find. Get a good reseller (Source was good at replacing early failures). With the quads, it was easy to handle losing a card or two, it's a bit more of a gamble with the new high density stuff... Good Luck, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote: > I'm about to purchase my first USR TC (HiPer bundle) and have been > contemplating the support issue. I've read that the USR boxes generate > a lot of heat and have a higher failure rate than most other access > servers. Is there a consensus among list members on whether or not to > purchase the support contract? Thanks, 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. >

On Tue, 23 Mar 1999, Stephen Amadei wrote: >The Total Control doesn't support NFAS. It is did, I'd used it on all my >PRIs... (well, except the first... ;-) ) The Dual PRI has always had NFAS (on that card anyway.) The released HDSP doesn't have NFAS, however, it's in beta if you're brave :-) --Ricky

On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote: >I'm about to purchase my first USR TC (HiPer bundle) and have been >contemplating the support issue. I've read that the USR boxes generate >a lot of heat and have a higher failure rate than most other access >servers. Is there a consensus among list members on whether or not to >purchase the support contract? Thanks, Dan I've never seen that to be true... one rack with 7 full quad modem chassis. (They were literally touching each other.) The air intake was 68dF and out at the top was 74dF. They were those racks with the integrated fan tray and 90% the modems in the entire rack were active for hours. I've never had much of a failure rate out of the hardware. A few modem cards have failed. One netserver failed. T1 NICs are a different story -- damned lightening. (over a period of two years.) --Ricky

On Tue, 23 Mar 1999, Bryan Wann wrote: >On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote: >It may be worthwhile for the first chassis.. that way you can get access >to code revisions. Past 2 DSP releases have been 'free' but who knows how >long that will last. You idiot. That's why the support contracts are so [bleep] expensive. 3Com isn't that stupid either; if you have more than one chassis, you have to buy support for all of them. As for contracts, pay for the software support contract. The hardware is more than stable enough to deal with the "factory" warantee (takes awhile to get the broken stuff replaced) or "per incedent" for things no longer under warantee. (I even got a netserver replaced one week after they discontinued the netserver... for free -- it was still under factory warantee.) >"higher failure rate". I have had only one problem with our HiPer ARC, >where the flash was either corrupted or just plain lost it, had to >re-upload it... haven't done a proper post-mortem to find out why tho. And that's easy enough to reflash assuming you have a "bulk configuration" file around somewhere. --Ricky

On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote: > I'm about to purchase my first USR TC (HiPer bundle) and have been > contemplating the support issue. I've read that the USR boxes generate > a lot of heat and have a higher failure rate than most other access > servers. Is there a consensus among list members on whether or not to > purchase the support contract? Thanks, Dan I've had good luck with our HiPer's. I bought 2 of the 48 port bundels just so I would have a spare NMC and ARC card. Nice to have 2 power supplies as well. As for heat, I haven't noticed it. Mine runs at a constant 70-73 degress. They are noisy, but I don't sit in the same room with them. As for support. It comes with 1 yr of free support and software updates I believe. I've never called their support anyway, I hear rumors it isn't that great but I can't say for sure since I've never called. Do yourself a favor and buy it from Source Technology. It'll come with a nice cheat sheet on getting it up and running. I had mine up and running in 15-20 minutes with their documentation. They also have their own tech support should you ever need it. I've called their tech support two times with a few simple questions and they called me back within 30 minutes each time I believe. Probably woulda been quicker had I been completly down. Their prices are good as well. For the money I don't think you can beat a HiPer. Only thing it lacks at the moment I really want is OSPF and BACP. I know OSPF should be out soon, anyone heard about BACP?

Hello all, I find myself in need of setting up some filters on a TC chassis w/5 Dsp's. Our boarder router is configured to filter packets not originating/destined for the network, but I find myself logging packets from the ARC card that users have set up to randomly ping an IP to keep the link alive. I've looked at the filter syntax and would like a simple example to clarify. Basically I need an input filter that will pass only packets coming from/to IP's that the PPP connections use. There is one large pool that goes from .100 to .230, the NMC/ARC card is .98 and .99 respectivly. How can I filter that range without specific ACCEPT / DENY lines for each IP? Thanks. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net

I'll try this again... can someone either 1) Get me a copy of the output of "ATS$" executed on a Quad? I tried getting it via the ARC (set swi inter slot:x/mod:x at "ats$") but it doesn't return the entire thing -- just the first half of so. Looks like it's too big for a buffer somewhere. 2) Give me some hints as to the right settings for the S76 and S81 registers to completely kill x2 and v.90 on a Quad? On a DSP, S76.1=1S81.5=1 does it. On a Quad, this does kill v.90, but it leaves some part of x2 enabled, and 3com modems calling in don't connect -- it sounds like one side is trying to do x2 and the other side is trying to do v.34, and the handshake gets stuck. (Probably a bug in the Quads?) The firmware release notes don't document these registers very well... This is for the DNIS-based reconfiguration trick discussed earlier, which is why I don't just use SNMP or TCM to do it... Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."

I have a Total Control box with my last remaining Netserver card running 12 quad modems. This box is mostly ISDN customers. I am having a problem over the last two days with the system "freezing" up. This seems to happen once or twice per day. Customers connected to the box will see things slow down, then stop. Only a reboot will fix the problem. I am running the latest code in all cards. This has run without a problem for several month. I have not touched it at all. Any ideas? Russ Miescke Power Web Connect russm@powerweb.net

On Tue, 23 Mar 1999, Ricky Beam wrote: > On Tue, 23 Mar 1999, Stephen Amadei wrote: > >The Total Control doesn't support NFAS. It is did, I'd used it on all my > >PRIs... (well, except the first... ;-) ) > > The Dual PRI has always had NFAS (on that card anyway.) The released HDSP > doesn't have NFAS, however, it's in beta if you're brave :-) Cripes... I would have really liked to have known that... but everyone I talked to told me the TC couldn't do NFAS at all... good to heard it will be available on the DSP. But beta? No thanks... I deal with enough beta stuff on PCs, let alone 10K worth of dialup equipment... ;-) ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

Is it possible to termite cable users on a DSP TC? I mean, supposing I have free slot on a Hiper chassis, can I plug the cards for cable? It was not clear on 3com page, how can I set up a chassis to cable connections. Which boards are necessary? And how many connections could be supported? TIA Get Your Private, Free Email at http://www.hotmail.com

We own over 20 TC units, never had a contract or a failure. Jack. zip-usrtc@ran.zipcon.net wrote: > I'm about to purchase my first USR TC (HiPer bundle) and have been > contemplating the support issue. I've read that the USR boxes generate > a lot of heat and have a higher failure rate than most other access > servers. Is there a consensus among list members on whether or not to > purchase the support contract? Thanks, 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.

On Wed, 24 Mar 1999, K Mitchell wrote: > I've had a HiPer chassis for almost a year now and have been pleased > overall with it. As for heat, I believe that earlier TC hardware did have a > heat problem, but it hasn't been an issue with the HiPer. It has an > integral fan tray with 9 or 12 fans that keeps it from going higher than 10 > degrees or so above room temp. It's a bit loud, but I normally sit about 2 The heat problem isn't a problem with the units getting too hot. The problem is simply the amount of heat generated by the units. You simply should not need 12 fans to keep a NAS cool. I have 4 of the quad modem racks, and the temperature 18" from the rack is 78F even though I have the A/C at 65F and the A/C blows directly towards that rack. The rest of the room stays around 67F. Brian

At 07:08 PM 3/23/99 -0800, zip-usrtc@ran.zipcon.net wrote: >I'm about to purchase my first USR TC (HiPer bundle) and have been >contemplating the support issue. I've read that the USR boxes generate >a lot of heat and have a higher failure rate than most other access >servers. Is there a consensus among list members on whether or not to >purchase the support contract? Thanks, Dan I've had a HiPer chassis for almost a year now and have been pleased overall with it. As for heat, I believe that earlier TC hardware did have a heat problem, but it hasn't been an issue with the HiPer. It has an integral fan tray with 9 or 12 fans that keeps it from going higher than 10 degrees or so above room temp. It's a bit loud, but I normally sit about 2 feet from it and I'm not deaf yet :) I've had no failure issues at all from 1 NMC, 1 ARC, 2 DSP and will be picking up a 3rd DSP shortly. I would buy it from someone like Source Technologies(888-765-5758) instead of direct. Talk to John DeDonato and tell him I sent ya. Thier price is likely about the cheapest you'll find and the support is better than 3Com's. I wouldn't buy the support contract, just software upgrades. Even at $300 per incident, w/o the contract, you won't need it much and will save money over the TCAP contract. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

On Tue, 23 Mar 1999, Ricky Beam wrote: > On Tue, 23 Mar 1999, Bryan Wann wrote: > >On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote: > >It may be worthwhile for the first chassis.. that way you can get access > >to code revisions. Past 2 DSP releases have been 'free' but who knows how > >long that will last. > > You idiot. Thank you! > That's why the support contracts are so [bleep] expensive. 3Com isn't > that stupid either; if you have more than one chassis, you have to buy > support for all of them. Since I am an idiot, care to expound on this a bit? Are the support contracts so bloody expensive because USR knows it is an extra source of revenue, or because they know some people may buy one support contract to leech upgrades for multiple racks? --- Bryan Wann bwann@cwis.net CWIS Internet Services http://www.cwis.net 918-967-2858 Give a man a fish, he eats for a day; Teach a man to fish, he eats for a lifetime; Enlighten him further, and he opens a chain of seafood restaurants

We have the quad modems, and I have tried "S76.1=1S76.2=1S81.5=1" for the string to turn off v.90 and "S76.1=0S76.2=0S81.5=0" for the default DNIS init string. and so far that seems to work for my tests. I hope it works for my users... I haven't tried to add &K0 S51.6=1 or s27.3=1. Randy McMillan ----- Original Message ----- Sent: Tuesday, March 23, 1999 11:08 PM > I'll try this again... can someone either > > 1) Get me a copy of the output of "ATS$" executed on a Quad? > I tried getting it via the ARC (set swi inter slot:x/mod:x at "ats$") but > it doesn't return the entire thing -- just the first half of so. Looks > like it's too big for a buffer somewhere. > > 2) Give me some hints as to the right settings for the S76 and S81 > registers to completely kill x2 and v.90 on a Quad? On a DSP, > S76.1=1S81.5=1 does it. On a Quad, this does kill v.90, but it leaves > some part of x2 enabled, and 3com modems calling in don't connect -- it > sounds like one side is trying to do x2 and the other side is trying to do > v.34, and the handshake gets stuck. (Probably a bug in the Quads?) The > firmware release notes don't document these registers very well... > > This is for the DNIS-based reconfiguration trick discussed earlier, which > is why I don't just use SNMP or TCM to do it... > > > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a > Microsoft operating system is like a dog without a brick tied to its head." > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Elfert wrote: > > On Wed, 24 Mar 1999, K Mitchell wrote: > > > I've had a HiPer chassis for almost a year now and have been pleased > > overall with it. As for heat, I believe that earlier TC hardware did have a > > heat problem, but it hasn't been an issue with the HiPer. It has an > > integral fan tray with 9 or 12 fans that keeps it from going higher than 10 > > degrees or so above room temp. It's a bit loud, but I normally sit about 2 > > The heat problem isn't a problem with the units getting too hot. The > problem is simply the amount of heat generated by the units. Everything except the PortMasters generate a ton of heat. I never really took the temperature of a PM3, but it strikes me from being around them that they run somewhat cooler. Everything else is like a frickin blow drier, the Max 4000 series, the Max 6000 series, the Max TNT, the Cisco AS5200 units, the Cisco AS5800 blast furnace, the Bay Networks 5000 chassis.. I've seen them all. You can fry your fishstick if you stand in front of a 8' rack full of AS5200's too long. At least the TC's blow the heat upwards, instead of in your face. It's weird when you feel radiant heat off the front of a Bay Networks 5000 chassis full of 5399s. Does anyone have any data on how much heat is generated by each type of RAC? -Ron GLISnet, Inc. +1 810/939.9885

I would NEVER do that! I like paying for software 7 times! I like to be on hold... plus I get to pay for the wonderful MUSAK they use! More .. please more! Lets hope they don't figure out what a dongle is or encrypt software to work with only burned in serial numbers.. that would suck! Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Wed, 24 Mar 1999, Bryan Wann wrote: > On Tue, 23 Mar 1999, Ricky Beam wrote: > > > On Tue, 23 Mar 1999, Bryan Wann wrote: > > >On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote: > > >It may be worthwhile for the first chassis.. that way you can get access > > >to code revisions. Past 2 DSP releases have been 'free' but who knows how > > >long that will last. > > > > You idiot. > > Thank you! > > > > That's why the support contracts are so [bleep] expensive. 3Com isn't > > that stupid either; if you have more than one chassis, you have to buy > > support for all of them. > > Since I am an idiot, care to expound on this a bit? Are the support > contracts so bloody expensive because USR knows it is an extra source of > revenue, or because they know some people may buy one support contract to > leech upgrades for multiple racks? > > > > --- > Bryan Wann bwann@cwis.net > CWIS Internet Services http://www.cwis.net 918-967-2858 > > Give a man a fish, he eats for a day; > Teach a man to fish, he eats for a lifetime; > Enlighten him further, and he opens a chain of seafood restaurants > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Bryan Wann >On Tue, 23 Mar 1999, Ricky Beam wrote: >> That's why the support contracts are so [bleep] expensive. 3Com isn't >> that stupid either; if you have more than one chassis, you have to buy >> support for all of them. >Since I am an idiot, care to expound on this a bit? Are the support >contracts so bloody expensive because USR knows it is an extra source of >revenue, or because they know some people may buy one support contract to >leech upgrades for multiple racks? Well, considering that their equipment has serial numbers on it, I have to assume that they're "so bloody expensive" because 3Com/USR knows it is an extra source of revenue...that would be also consistent with their attitudes towards other issues (check in the archives for the thread "3Coms problems" or something along those lines. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Wednesday, March 24, 1999 1:31 PM, Robert von Bismarck [SMTP:rvb@petrel.ch] wrote: > Physical state : > psF3Fc2LossOfSignal(3) > Line Status : > dsx1XmtFarEndLOF (4) = Near end sending LOF Indication > dsx1LossOfFrame (32) = Near end LOF (Red Alarm) > This looks weird, USR tells me that with a RED alarm it won't work, but it > definitely does, and customers are happy. > What could it be ? defect PRI cables ? bad provisioning ? bad setup ? bad > weather ? What do you see for errors at the span level? I recently set up a second span on a dual PRI card and, once I had it working, noticed CRC errors and errored seconds were skyrocketing. Calls were coming in normally as far as I could tell and the customers were happy. As it turned out, at some point in the circuit the telco had not set it for B8ZS as it should have been. As soon as they had corrected that, the errors dropped to nil. This was on a dual pri card and there were no warning lights on it at all but DSPs might react differently. It's one thing to check. Matthew

I have just noticed this error is syslogs, it seems to reset the whole card. Though I was imagining things, first the card was full, next it was empty?? At 20:40:00, Facility "Driver", Level "CRITICAL":: Deactivating Timer Fired on interface: slot:15/mod:16 Sean Herr

Once upon a time Ricky Beam shaped the electrons to say... >Both. It costs 3Com money to develop the software and people were stealing >money from them by buying one contract and putting that code on more than >one chassis. Funny that other vendors can give away OS upgrades for free, and they aren't goign bankrupt. And are even charging per port prices in the same range as 3Com. And then they give you free support, free management tools... Gosh, I never knew 3Com was so poorly run they need to make money on software on top of everything else. >Do you really want to see 3Com wiring serial number checks in the code to >prevent you from loading code on a card that isn't under a software support I'd like to see them give the upgrades away - but that might mean respecting the customers and responding to the market. So I won't hold my breath. >they aren't charging enough for the hardware itself -- the TC hardware is, >by far, much cheaper than competing hardware. Much cheaper? Not that I've seen. Depending on the reseller, specials, etc, you can find other vendors' gear for less. And prices across the board continue to decline. 3Com charges for just about everything. >PS: If you want "free" code updates, participate in the beta program and > actually give some feedback. You'll have access to the code before it Or buy from another vendor... Have you seen the latest (free) PM-4 open release? Jesus is it loaded. <URL:ftp://ftp.livingston.com/pub/le/doc/release/release41b14.txt> - free. The PM-4 itself is still pricey, but fairly new and prices are dropping. I've also seen the notes for 3.9, but that isn't public yet. Equally loaded, equally free. And there will be a build for the PM-2 - of course if the PM-2 were 3Com it wou;d be 'obsolete' and 'discontinued' and you'd be told to 'upgrade' for any 'fix'... Oh, did I get sarcasm on you? -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

On Wed, 24 Mar 1999, MegaZone wrote: > Gosh, I never knew 3Com was so poorly run they need to make money on software > on top of everything else. Does this mean Cisco is badly run? > >Do you really want to see 3Com wiring serial number checks in the code to > >prevent you from loading code on a card that isn't under a software support > I'd like to see them give the upgrades away - but that might mean respecting > the customers and responding to the market. So I won't hold my breath. Responding to the market. Hm. Then why did it take Lucent so long to support RIPv2. And why does it feel like Lucent is giving users the finger with the RIPv2 release. Eg "heres your RIPv2, you freaking lamers" -Dan

On Wed, 24 Mar 1999, Bryan Wann wrote: >On Tue, 23 Mar 1999, Ricky Beam wrote: >> On Tue, 23 Mar 1999, Bryan Wann wrote: >> >On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote: >> >It may be worthwhile for the first chassis.. that way you can get access >> >to code revisions. Past 2 DSP releases have been 'free' but who knows how >> >long that will last. >> >> You idiot. > >Thank you! You're welcome. >> That's why the support contracts are so [bleep] expensive. 3Com isn't >> that stupid either; if you have more than one chassis, you have to buy >> support for all of them. > >Since I am an idiot, care to expound on this a bit? Are the support >contracts so bloody expensive because USR knows it is an extra source of >revenue, or because they know some people may buy one support contract to >leech upgrades for multiple racks? Both. It costs 3Com money to develop the software and people were stealing money from them by buying one contract and putting that code on more than one chassis. Do you really want to see 3Com wiring serial number checks in the code to prevent you from loading code on a card that isn't under a software support contract? I certainly don't want to see that level complexity. And I'm certain no one wants to have to enter enable codes on every card in their network -- the X2 crap drove me mad with only 47 chassis. Try to pull that stunt with Cisco... 3Com has to make money somehow. IMO, they aren't charging enough for the hardware itself -- the TC hardware is, by far, much cheaper than competing hardware. --Ricky PS: If you want "free" code updates, participate in the beta program and actually give some feedback. You'll have access to the code before it becomes "release" and you have the chance to get things fixed before it's too late. You're providing a service to 3Com and vice versa.

Once upon a time Ronald Kushner shaped the electrons to say... >Everything except the PortMasters generate a ton of heat. I never really >took the temperature of a PM3, but it strikes me from being around them that You can yank the fan on a PM-3 and it won't die. People have had dead fans and thought they were temperature activated since they were never on. :-) >they run somewhat cooler. Everything else is like a frickin blow drier, the >Max 4000 series, the Max 6000 series, the Max TNT, the Cisco AS5200 units, The MAX 6000 is definitely better than the MAX 4000 - and the 4000 with the newer digital modems is WAY better than the old analog modem cards. A full MAX 4000 with 72 analog modems could *burn* you. They've been known to meltdown and some have caught fire. >the Cisco AS5800 blast furnace, the Bay Networks 5000 chassis.. I've seen >them all. You can fry your fishstick if you stand in front of a 8' rack full >of AS5200's too long. At least the TC's blow the heat upwards, instead of in Actually this is not a good thing. I've talked to people with racks of TCs where the heat at the top (and this was with quads, I am aware that DSPs are better) was enough to melt plastic items into goo. One guy laid a 3-ring binder down while doing something and had it melt, drooping over the rack. You make a chiminey. You *want* front to back airflow. Racks are mounted next to each other, and gear in the rack is above. So side to side - MAX - airflow cooks the next rack over. Also, many racks have sides now, not good. Top to bottom airflow - TC - creates the chiminey. Telco quality gear will have front to back flow. Or, if it is taller, will be lower front to upper rear. The former is like the AS5300 or PM-3, the latter is like the CVX-1800 or PM-4. This way the exhaust from one unit will *never* feed into the intake of another. >your face. It's weird when you feel radiant heat off the front of a Bay >Networks 5000 chassis full of 5399s. Yeah - I stood infront of a loaded 5000MSX and was very surprised. Even with the exhaust in back the thing was hot enough to radiate heat out the front. >Does anyone have any data on how much heat is generated by each type of RAC? Look for the Watts consumed and you can turn that into BTU. A PM-3 is 20Watts + .8 Watts a modem (dsp). Actually it is less, they budgeted high. It is more like .5-6W a modem. Say 60W for a 50 modem unit. A PM-4's *max* consumption is 800W - that's what the power supplies can give it. (3 400W supplies, N+1). But it is something less than that, even full. Jesus - get this, a MAX6000 with 6x16 modem cards has a draw of 225W! Minimum - no modem cards - is 80W! That's more than a loaded PM-3. HiPer - a T1 DSP is 24W (E1 is 26W), Router card is 31W, not sure on the network management card. But it is 5A and the DSP is 5.4A - so let's use 22W for example. Now, a loaded unit is listed by 3Com as 14 DSPs, 2 routers, and one NMC - so about 420W. I obtained all figures from the respective vendor's website. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Dan Hollis shaped the electrons to say... >On Wed, 24 Mar 1999, MegaZone wrote: >>Gosh, I never knew 3Com was so poorly run they need to make money on software >>on top of everything else. >Does this mean Cisco is badly run? I do think they are a bit inefficient. >Responding to the market. Hm. Then why did it take Lucent so long to >support RIPv2. And why does it feel like Lucent is giving users the finger >with the RIPv2 release. Eg "heres your RIPv2, you freaking lamers" All through the time I worked there RIPv2 had little demand, since I'm still in touch with folks there it is pretty much the same. The demand was always for *a* VLSM/CIDR protocol. A lot of people said RIPv2 because of bad experiences with Ascend OSPF, or complexity on Cisco, etc. When Livingston released OSPF and people actually tried it and found it easy to use, well, request for RIPv2 all but dried up. I mean it - requests for it dropped right off the radar. Had demand remained it would have shipped - the guy who did OSPF and BGP also did RIPv2. In fact, he did it *first* to get warmed up. I'm given to understand the reason it is being added now is more for marketing - people have checkboxes and look for RIPv2. Also, they are getting PM-4s into users who have Ascend gear and are using RIPv2 because of OSPF trouble, replacing TCs where users are RIPv2 because they don't have OSPF in the first place, etc. As they take more marketshare the need for RIPv2 just to be able to replace other vendors' lame HW has increased. OSPF will still be the recommended protocol. RIPv2 will be there if someone just has to have it - but isn't going to be trumpted. It *is* lame. I wouldn't be surprised if they added it because of some big customer saying they'd buy PMs if they did. Seeing as they've had the code on the shelf for a few years it wouldn't be a big investment to land a deal. But I know from talking to the engineers that no one really believes RIPv2 is worth it on its own merits. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

On Wed, 24 Mar 1999, MegaZone wrote: > OSPF will still be the recommended protocol. RIPv2 will be there if someone > just has to have it - but isn't going to be trumpted. It *is* lame. Any lamer than doing RIPv1 but not RIPv2? I never understood this. How long does it take to do a RIPv2 implementation from a RIPv1 one? A day or two max? Why Livingston blew it off for *years*, in favor of the long development time of a far more complex protocol, Ill never understand. > I wouldn't be surprised if they added it because of some big customer > saying they'd buy PMs if they did. Seeing as they've had the code on > the shelf for a few years it wouldn't be a big investment to land a > deal. But I know from talking to the engineers that no one really > believes RIPv2 is worth it on its own merits. Its all about interoperability with the lowest common denominator. Apparently Livingston/Lucent couldnt be bothered with that. Or maybe the pointy haired ones were too closely involved in micromanaging development. In any case I think it was a mistake to overlook the lowest common denominator for so long. -Dan

I've got a problem with users fairly frequently getting disconnected immediately after performing PAP, with this message getting syslogged: Mar 24 16:00:28 gb-hiper At 22:00:28, Facility "Auth Facility", Level "COMMON":: Port slot:4/mod:9 successful RADIUS authentication for user: Pxxxxxxxxx Mar 24 16:00:28 gb-hiper At 22:00:28, Facility "PPP", Level "UNUSUAL":: ../../src/ppp_main.c: PPP Get Option Rejected, (bad status). They can usually get connected on the second try. There doesn't seem to be a pattern to the slot/mod numbers -- they're more or less random throughout the group. We've got one where they get this every time, but they're an ISDN customer with what I think may be a misconfigured router. The others are analog dialups. A 'mon ppp' on one of these connection shows the ARC sending a PAP auth-ack and then nothing after that. In our RADIUS server's log I can see the auth request and ack, but no accounting records. Logging of unauthenticated calls isn't enabled on this box. Any info would be appreciated. If this is an RTFM issue, someone please indicate which FM. I suspect it's not, though, as this just started happening relatively recently. [versions] HARC 4.1.59-6 DSP 1.2.43 and 1.2.59, some on PRI some on channelized. Livingston RADIUS 2.0.1, soon to be Cistron RADIUS. [relevant config stuff] PPP offloading: ENABLED 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: DISABLE [mon PPP] Outgoing PPP Data on interface: slot:4/mod:9 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 50 8a b1 9b PROTO_COMP AC_COMP MPP_MRRU 05 ea MPP_ENDPTID 00 Incoming PPP Data on interface: slot:4/mod:9 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 1a 04 PROTO_COMP AC_COMP CALLBACK 06 Outgoing PPP Data on interface: slot:4/mod:9 LCP CFG_REJ CALLBACK 06 Incoming PPP Data on interface: slot:4/mod:9 LCP CFG_REJ MPP_MRRU 05 ea MPP_ENDPTID 00 Outgoing PPP Data on interface: slot:4/mod:9 LCP CFG_REQ MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 50 8a b1 9b PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:4/mod:9 LCP CFG_REQ ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 1a 04 PROTO_COMP AC_COMP Outgoing PPP Data on interface: slot:4/mod:9 LCP CFG_ACK ASYNC_MAP 00 0a 00 00 MAGIC_NUM 00 01 1a 04 PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:4/mod:9 LCP CFG_ACK MRU 05 ea ASYNC_MAP 00 00 00 00 AUTH_TYPE c0 23 MAGIC_NUM 50 8a b1 9b PROTO_COMP AC_COMP Incoming PPP Data on interface: slot:4/mod:9 PAP REQUEST USERNAME = Pxxxxxxxx PASSWORD = yyyyyyyyy Outgoing PPP Data on interface: slot:4/mod:9 PAP ACK ....Tracing the current/next session; Escape to stop... Tracing stopped, Return/Enter to re-start, ESCAPE to quit.

Hello- I'm trying to reprovision our isdn box(netserver with quads) here with different ip's and move the range down. In other words, it was xxx.xxx.47.240 with a size of 12. I tried to move it to xxx.xxx.47.225 with the same size of 12. I did this with the 'set assigned xxx.xxx.47.225' command and did a save all and reboot. Upon reboot anyone who dials into the box with the box cannot get out nor can I ping them. A traceroute shows that the router knows what box to send it to but it just never gets there. traceroute to xxx.xxx.47.232), 30 hops max, 40 byte packets 1 xxx.xxx.xxx.2 1.998 ms 2.128 ms 2.377 ms 2 xxx.xxx.xxx.4 3.746 ms 2.979 ms 3.567 ms 3 xxx.xxx.46.8 7.153 ms 6.639 ms 7.037 ms <--this is the isdn box 4 * * * Whatever more info is needed, i.e. show global or whatever, I can give. Any help is appreciated. Steve

I upgraded to DSP 1.2.43 & HiPer ARC 4.1.59-6 last week. There are 4 DSP cards in this box. Monday, when the first two spans filled up I would get fast busies. I noticed I was getting Invalid Channel ID errors so I took the span out of service and it rooled over to the fourth span fine. When I put the card back in service it started working after about 2 minutes. I did notice a loopback/d-channel alarm during that 2 minutes but then all was well. Today the fourth span had the same problem. The first 3 spans filled up fine then fast busy signals. I reset the card on the fourth span then all was well. These are all PRI's. Anyone else notice this problem?

Can someone elaborate on the problem with the Hiper 4.1.59-6 code and quad modems. We are setting up a couple of chassis like that. They seem to work OK when we are testing it with one modem in use. Although we are having some problems with our telco, and want to rule out a hiper/quad problem. We have T1's ppp authentication any ppp authentication_preference PAP ppp offloading enabled ppp Receive ACCM disabled When the authentication_preference was CHAP, it didn't authenticate for me. Should I be having problems? and what sort? Also, I don't think I saw 4.1.62-4 on the USR web site. Thanks. Randy McMillan PacInfo ----- Original Message ----- Sent: Wednesday, March 24, 1999 2:55 PM > > > > > Ok, that's the problem. Krish and I found out that with 4.1.59-6 and > Quads, you must not have the Preferred protocol set to PAP. Change it > to DEFAULT or get off of 4.1.59-6 and Quads. We are staying at 4.1.62-4 > for Quad racks. Krish can elaborate more on the bug if you wish. > > > Jeff Binkley > ASA Network Computing > > > u>----Original Message----- > > > u>>On Fri, 19 Mar 1999, Jeff Binkley wrote: > u>>> Krish, > u>>> Note he has Preferred set to PAP which may be a problem with >quads > u>as you and I discovered the other day. > > u>We only have Quads installed > > u>>Well he is using DSP for the most part and also he is complaing > u>>about speed and through put. Disabling ppp offloading does slow > > u>No DSP installed yet, only the quads > > 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. >

Ok, that's the problem. Krish and I found out that with 4.1.59-6 and Quads, you must not have the Preferred protocol set to PAP. Change it to DEFAULT or get off of 4.1.59-6 and Quads. We are staying at 4.1.62-4 for Quad racks. Krish can elaborate more on the bug if you wish. Jeff Binkley ASA Network Computing u>----Original Message----- u>>On Fri, 19 Mar 1999, Jeff Binkley wrote: u>>> Krish, u>>> Note he has Preferred set to PAP which may be a problem with >quads u>as you and I discovered the other day. u>We only have Quads installed u>>Well he is using DSP for the most part and also he is complaing u>>about speed and through put. Disabling ppp offloading does slow u>No DSP installed yet, only the quads CMPQwk 1.42-21 9999

Thus spake MegaZone >Gosh, I never knew 3Com was so poorly run they need to make money on software >on top of everything else. You haven't been watching them much have you? >I'd like to see them give the upgrades away - but that might mean >respecting the customers and responding to the market. So I won't hold >my breath. Heh, yeah, respecting the customer...that'll be the day. >>they aren't charging enough for the hardware itself -- the TC hardware is, >>by far, much cheaper than competing hardware. >Much cheaper? Not that I've seen. Depending on the reseller, specials, >etc, you can find other vendors' gear for less. And prices across the >board continue to decline. I kinda wondered about that comment too....we haven't seen that its much cheaper per port than much else, and sometimes more expensive. >3Com charges for just about everything. "just about?" *ponders trying to think of something that they don't charge for in normal circumstances* >>PS: If you want "free" code updates, participate in the beta program and >> actually give some feedback. You'll have access to the code before it That's assuming they even acknowledge your request to be a part of the Beta process...hasn't happened yet for me. >And there will be a build for the PM-2 - of course if the PM-2 were >3Com it wou;d be 'obsolete' and 'discontinued' and you'd be told to >'upgrade' for any 'fix'... Oh, did I get sarcasm on you? Not any that would be noticed in all of my own. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Guys, I've got a funny one here, I'm frankly lost, 3Com is stumped, and the telco is of no help : I set up a new chassis (HiperDSP 1.2.5 and ARC 4.1.59) in a remote POP. The telco checked the lines and foudn them ready to take up the service. We put the plug in (was some hell to find out the RJ-45 wall jacks were cabled funny, but it works) and we got the RN/FL light on, the CAR light off, the ALM light red, the LPBK/D-ALM light off and FAULT is off. in TCM monitoring I've got this that is different from the other chassis' I have : Physical state : psF3Fc2LossOfSignal(3) Line Status : dsx1XmtFarEndLOF (4) = Near end sending LOF Indication dsx1LossOfFrame (32) = Near end LOF (Red Alarm) This looks weird, USR tells me that with a RED alarm it won't work, but it definitely does, and customers are happy. What could it be ? defect PRI cables ? bad provisioning ? bad setup ? bad weather ? I'm open to any suggestions as long as it's not "TC's are lousy, buy Ascend or Livingston..." Thanks for any replies, Robert

We (me/TELCO) isolated and verified the problem down to not enough TELCO infrastructure trunks between there and here. TELCO problem. blake > -----Original Message----- > From: Mike Hamrich [mailto:mikeh@drfast.net] > Sent: Sunday, March 21, 1999 10:13 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers can't connect > > > Blake, before you did the upgrade how did you have the NMC > set to answer > ISDN calls, on the Quads or the Netserver? > -----Original Message----- > From: Blake Fithen <fithen@NetworksPlus.com> > To: 'usr-tc@lists.xmission.com' <usr-tc@lists.xmission.com> > Date: Thursday, March 18, 1999 9:11 PM > Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect > > > >ARC 4.1.59-6 > >DSP 1.2.43 > > > >The only thing we having problems with are ISDN calls. Analog > >current link transmit rates are anywhere from 14,400 to 53,300. > >But i haven't seen a single ISDN call get established and pass > >data. mon ppp, and mon radius show nothing - "li co" will show > >the modem being tied up but after about 10 seconds it drops. I > >had a few ISDN customers connected with 4.1.59 and 1.2.59 but > >as soon as I upgraded the DSP to 1.2.43 things went downhill. > > > >[1 hour goes by] > > > >and at 7:30 my pager goes nuts saying that all our dedicated > >ISDN customers are back up. during this time i have been > >gathering statistics from the incomplete ISDN calls and then > >many dedicated customers with ISDN devices from many different > >vendors begin working again without any intervention from me. > >Ah! and everything came back up about the same time last night! > > > >WHAT THE HELL??!?!?! > > > >any similar experiences? TELCO sabotage? > > > >blake > > > > > >> -----Original Message----- > >> From: Mike Hamrich [mailto:mhamrich@drfast.net] > >> Sent: Thursday, March 18, 1999 7:21 PM > >> To: usr-tc@lists.xmission.com > >> Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect > >> > >> > >> OK HiperArc with latest code 3/4/99 > >> > >> Since the "upgrade" we are having tons of connection issues. > >> Couriers can't connect > >> Owners of Sporsters flashed with Feb '99 v.90 code connect slower > >> OEM/Brown box Sportsters can't stay connected > >> > >> We also told owner of non X2 modem to go elsewere. > >> > >> We surveyed our users, 248 replied so far: > >> 67% say slower speed, 22% are having problems saying > >> connected, 4% can't > >> connect at all, and ONLY 7% report better connection. > >> > >> We have PRI lines, Set PPP offloading to no, Authenticate ANY > >> Preferrd PAP > >> > >> Any other ideas to make this stuff work as well as the old > stuff did? > >> > >> Thanks in advance for you help > >> > >> Mike Hamrich > >> CIO, DrFast.Net, Inc. > >> (216) 797-1040 > >> > >> > >> - > >> To unsubscribe to usr-tc, send an email to > "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the 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. >

P.S. everything else seems to be going pretty good with this specific firmware revision. (ARC 4.1.59-6, DSP 1.2.43) blake > -----Original Message----- > From: Blake Fithen [mailto:fithen@NetworksPlus.com] > Sent: Wednesday, March 24, 1999 6:40 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect > > > We (me/TELCO) isolated and verified the problem down to > not enough TELCO infrastructure trunks between there and > here. TELCO problem. > > blake > > > -----Original Message----- > > From: Mike Hamrich [mailto:mikeh@drfast.net] > > Sent: Sunday, March 21, 1999 10:13 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers > can't connect > > > > > > Blake, before you did the upgrade how did you have the NMC > > set to answer > > ISDN calls, on the Quads or the Netserver? > > -----Original Message----- > > From: Blake Fithen <fithen@NetworksPlus.com> > > To: 'usr-tc@lists.xmission.com' <usr-tc@lists.xmission.com> > > Date: Thursday, March 18, 1999 9:11 PM > > Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers > can't connect > > > > > > >ARC 4.1.59-6 > > >DSP 1.2.43 > > > > > >The only thing we having problems with are ISDN calls. Analog > > >current link transmit rates are anywhere from 14,400 to 53,300. > > >But i haven't seen a single ISDN call get established and pass > > >data. mon ppp, and mon radius show nothing - "li co" will show > > >the modem being tied up but after about 10 seconds it drops. I > > >had a few ISDN customers connected with 4.1.59 and 1.2.59 but > > >as soon as I upgraded the DSP to 1.2.43 things went downhill. > > > > > >[1 hour goes by] > > > > > >and at 7:30 my pager goes nuts saying that all our dedicated > > >ISDN customers are back up. during this time i have been > > >gathering statistics from the incomplete ISDN calls and then > > >many dedicated customers with ISDN devices from many different > > >vendors begin working again without any intervention from me. > > >Ah! and everything came back up about the same time last night! > > > > > >WHAT THE HELL??!?!?! > > > > > >any similar experiences? TELCO sabotage? > > > > > >blake > > > > > > > > >> -----Original Message----- > > >> From: Mike Hamrich [mailto:mhamrich@drfast.net] > > >> Sent: Thursday, March 18, 1999 7:21 PM > > >> To: usr-tc@lists.xmission.com > > >> Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect > > >> > > >> > > >> OK HiperArc with latest code 3/4/99 > > >> > > >> Since the "upgrade" we are having tons of connection issues. > > >> Couriers can't connect > > >> Owners of Sporsters flashed with Feb '99 v.90 code connect slower > > >> OEM/Brown box Sportsters can't stay connected > > >> > > >> We also told owner of non X2 modem to go elsewere. > > >> > > >> We surveyed our users, 248 replied so far: > > >> 67% say slower speed, 22% are having problems saying > > >> connected, 4% can't > > >> connect at all, and ONLY 7% report better connection. > > >> > > >> We have PRI lines, Set PPP offloading to no, Authenticate ANY > > >> Preferrd PAP > > >> > > >> Any other ideas to make this stuff work as well as the old > > stuff did? > > >> > > >> Thanks in advance for you help > > >> > > >> Mike Hamrich > > >> CIO, DrFast.Net, Inc. > > >> (216) 797-1040 > > >> > > >> > > >> - > > >> To unsubscribe to usr-tc, send an email to > > "majordomo@xmission.com" > > >> with "unsubscribe usr-tc" in the body of the 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 for the reply. The problem is that I set it up originally with the xxx.xxx.47.240 range and all I did was change the start address of the ip within the 47 network. It worked perfectly fine with the 47.240 range but when moved to 47.225 it puked. The other interesting thing related to this is that the customers who have a static ip assigned to them are 100% fine and operational. That ip is in the xxx.xxx.45.xxx range. The problem seems _only_ to be with the ip address pool and assignments from the pool. Thanks again for the reply. Steve On Wed, 24 Mar 1999, Paul Farber wrote: > Just a guess.. its on a different network? You box is on network 46 while > your modems are on network 47 (assuming a class c and no further > subnetting). > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Wed, 24 Mar 1999 vanhalen@coredcs.com wrote: > > > Hello- > > > > I'm trying to reprovision our isdn box(netserver with quads) here with > > different ip's and move the range down. In other words, it was > > xxx.xxx.47.240 with a size of 12. I tried to move it to xxx.xxx.47.225 > > with the same size of 12. I did this with the 'set assigned > > xxx.xxx.47.225' command and did a save all and reboot. Upon reboot anyone > > who dials into the box with the box cannot get out nor can I ping them. A > > traceroute shows that the router knows what box to send it to but it just > > never gets there. > > > > traceroute to xxx.xxx.47.232), 30 hops max, > > 40 byte packets > > 1 xxx.xxx.xxx.2 1.998 ms 2.128 ms 2.377 ms > > 2 xxx.xxx.xxx.4 3.746 ms 2.979 ms 3.567 ms > > 3 xxx.xxx.46.8 7.153 ms 6.639 ms 7.037 ms <--this is the isdn box > > 4 * * * > > > > > > > > Whatever more info is needed, i.e. show global or whatever, I can give. > > > > Any help is appreciated. > > > > Steve > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Did that yesterday, all was well. On Wed, 24 Mar 1999, Paul Farber wrote: > Ask the telco to check the translations for your hunt groups. Bell got me > 3 times on that. > > Paul D. Farber II > Farber Technology > Ph. 570-628-5303 > Fax 570-628-5545 > farber@admin.f-tech.net > > On Wed, 24 Mar 1999, Robert Reynolds wrote: > > > I upgraded to DSP 1.2.43 & HiPer ARC 4.1.59-6 last week. There are 4 DSP > > cards in this box. Monday, when the first two spans filled up I would get > > fast busies. I noticed I was getting Invalid Channel ID errors so I took > > the span out of service and it rooled over to the fourth span fine. > > When I put the card back in service it started working after > > about 2 minutes. I did notice a loopback/d-channel alarm during that > > 2 minutes but then all was well. Today the fourth span had the same > > problem. The first 3 spans filled up fine then fast busy signals. I reset > > the card on the fourth span then all was well. > > > > These are all PRI's. > > > > Anyone else notice this problem? > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Ask the telco to check the translations for your hunt groups. Bell got me 3 times on that. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Wed, 24 Mar 1999, Robert Reynolds wrote: > I upgraded to DSP 1.2.43 & HiPer ARC 4.1.59-6 last week. There are 4 DSP > cards in this box. Monday, when the first two spans filled up I would get > fast busies. I noticed I was getting Invalid Channel ID errors so I took > the span out of service and it rooled over to the fourth span fine. > When I put the card back in service it started working after > about 2 minutes. I did notice a loopback/d-channel alarm during that > 2 minutes but then all was well. Today the fourth span had the same > problem. The first 3 spans filled up fine then fast busy signals. I reset > the card on the fourth span then all was well. > > These are all PRI's. > > Anyone else notice this problem? > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Just a guess.. its on a different network? You box is on network 46 while your modems are on network 47 (assuming a class c and no further subnetting). Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Wed, 24 Mar 1999 vanhalen@coredcs.com wrote: > Hello- > > I'm trying to reprovision our isdn box(netserver with quads) here with > different ip's and move the range down. In other words, it was > xxx.xxx.47.240 with a size of 12. I tried to move it to xxx.xxx.47.225 > with the same size of 12. I did this with the 'set assigned > xxx.xxx.47.225' command and did a save all and reboot. Upon reboot anyone > who dials into the box with the box cannot get out nor can I ping them. A > traceroute shows that the router knows what box to send it to but it just > never gets there. > > traceroute to xxx.xxx.47.232), 30 hops max, > 40 byte packets > 1 xxx.xxx.xxx.2 1.998 ms 2.128 ms 2.377 ms > 2 xxx.xxx.xxx.4 3.746 ms 2.979 ms 3.567 ms > 3 xxx.xxx.46.8 7.153 ms 6.639 ms 7.037 ms <--this is the isdn box > 4 * * * > > > > Whatever more info is needed, i.e. show global or whatever, I can give. > > Any help is appreciated. > > Steve > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

What are you all finding as the best code set to be on right now? We run: ARC: 4.1.59-1 HDM: 1.2.60 And are pretty happy with it, but feel alot of modems should be connecting better etc. Has anyone used the above codeset, and then moved on to something they found even better? If so what code? Brian Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

(Sent this days ago but haven't seen it go through yet...) Has anyone bothered counting the number of call failures on the DSP's? I have included a script below which parses through our SNMP trap logs and generates a simple report on the number of call failures ordered by modem. The values get reset every midnight. Here is a sample of what you get. Note that this report was generated mid afternoon. I've confident that the top 7 modems have not had a successfull call today. Report generated: Fri Mar 19 15:00:01 EST 1999 Fails NMC Slot Modem 45 10.1.1.102 8 24 45 10.1.1.102 8 23 26 10.1.4.105 3 16 26 10.1.4.105 3 15 23 10.1.4.105 14 15 22 10.1.4.105 3 6 21 10.1.4.105 3 5 18 10.1.5.11 15 6 18 10.1.5.11 15 5 (NOTE: The above are all DSP's) 7 10.1.5.11 6 3 7 10.1.5.11 15 8 5 10.1.5.11 4 1 Notice the trend of sequential pairs of modems with nearly the same call failure rate? As a witness to many of these reports, I can tell you this is not even close to a rare occurrance. And forget all the BS about the 'telco'... at the 10.1.4.* site, _we_are_ the telco. (The chassis' are barely 10 feet from the DMS100). Since this report was generated rather early in the day, the values are actually low. By the end of the day, most of our pool is full, so these bad modems are the only ones attempting to take calls. I'll probably have over 300 failures per bad modem by the end of the day. ("good" modems only have around 10-12 failures max. per day). The only solution I've come up with to fix this is to reboot the DSP. (Since this is not a desirable solution, I end up busying out the associated DS0's and waiting until our _weekly_ chassis reboot). Tried resetting and dis/enabling the modems from the TCM, and soft-resetting the modems. Doesn't do a darn thing. (BTW: Our code versions are ARC 4.1.72 and DSP 1.2.60, because I still don't trust the .59 codes... I mean, come on... a bug fix for a bug fix???) Here's how to set up this report: On a Unix machine, set up the UCD-SNMP tools (snmptrapd in particular). (by default, it will syslog traps to LOG_LOCAL0, which you direct to /var/log/snmptraps). Place the MIB files from the mib directory under TCM into the directory /usr/local/share/snmp/mibs on the UCD-SNMP machine. Configure all of your modems to SNMP trap Incoming Call Failures to this machine. (I actually trap all sorts of stuff). This works with DSP's and Quadmodems. Install the following scripts into /usr/local/bin. Add a cron job to run 'publish_badmodems' every half hour. Let the chaos unfold. I don't claim that this will for for everyone. I do know it works for me. --- publish_badmodems --- #!/bin/sh exec 1>/path/to/publish/to/badmodems.html echo "<head></head><body>" echo "<p>Report generated: `date`<hr><pre>" echo -e "<b>Fails\tNMC\t\tSlot\tModem</b><p><hr>" nice /usr/local/bin/parsefails echo "</pre></body>" --- parsefails --- #!/bin/sh if [ -f "$1" ]; then INFILE="$1" else INFILE=/var/log/snmptraps fi egrep -i 'inconnectAttemptFailure|ctConnectAttemptFailure' $INFILE \ | awk -f /usr/local/sbin/parsefails.awk \ | sort -n | uniq -c | sort -nr --- parsefails.awk --- /Uptime: [0-9]* days?,/ { gsub("Uptime: [0-9]* days?,","Uptime: ") } { gsub("[,:]","") } /Trap \(inconnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 } /Trap \(ctConnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }

"T.J. Weber" wrote: > Hi, I'm in seek of if a RADIUS daemon that supports realms. What I need > to be able to do is authenticate users by domain, for example > user@my-domain.com and user@reseller-domain.com. Simple accounting is > all that is needed which will send basic information back to the acc't > server with the user@domain. I would like to stay in the low price > range (as in free). I know that Merit AAA supports this, how about the > basic Merit server? Cistron? Any others I should know about? Not free but Lucent PortAuthorty and Lucent RADIUS ABM. Both are JAVA Based. -- Thomas C Kinnen - <tkinnen@ra.lucent.com> <tkinnen@sobhrach.com> [RADIUS Test Engineer] - LUCENT Technologies RABU "All of the opinions stated above are my own and not my employer's, unless they were given to me by my employer"

On Wed, 24 Mar 1999, T.J. Weber wrote: > Hi, I'm in seek of if a RADIUS daemon that supports realms. What I need > to be able to do is authenticate users by domain, for example > user@my-domain.com and user@reseller-domain.com. Cistron does this. http://homepage.cistron.nl/~miquels/radius/ -Dan

On Wed, 24 Mar 1999, Randy McMillan wrote: > Can someone elaborate on the problem with the Hiper 4.1.59-6 code and quad > modems. We are setting up a couple of chassis like that. They seem to work > OK when we are testing it with one modem in use. Although we are having > some problems with our telco, and want to rule out a hiper/quad problem. > Quad and HiPer arc have no problems. There is a know issue with broken Webramp code. Per Webramp 1.0.6 code should solve the issues, but there are issues still from what we see. With Webramp chap works fine but PAP does not. If you disable ppp offloading on the hiper arc both pap and chap work fine with Quad modems. This is the issue. krish > We have T1's > ppp authentication any > ppp authentication_preference PAP > ppp offloading enabled > ppp Receive ACCM disabled > > When the authentication_preference was CHAP, it didn't authenticate for me. > Should I be having problems? and what sort? Also, I don't think I saw > 4.1.62-4 on the USR web site. Thanks. > > Randy McMillan > PacInfo > > ----- Original Message ----- > From: Jeff Binkley <jeff.binkley@asacomp.com> > To: <usr-tc@lists.xmission.com> > Sent: Wednesday, March 24, 1999 2:55 PM > Subject: Re: (usr-tc) RE: (USR-TC) > > > > > > > > > > > > Ok, that's the problem. Krish and I found out that with 4.1.59-6 and > > Quads, you must not have the Preferred protocol set to PAP. Change it > > to DEFAULT or get off of 4.1.59-6 and Quads. We are staying at 4.1.62-4 > > for Quad racks. Krish can elaborate more on the bug if you wish. > > > > > > Jeff Binkley > > ASA Network Computing > > > > > > u>----Original Message----- > > > > > > u>>On Fri, 19 Mar 1999, Jeff Binkley wrote: > > u>>> Krish, > > u>>> Note he has Preferred set to PAP which may be a problem with >quads > > u>as you and I discovered the other day. > > > > u>We only have Quads installed > > > > u>>Well he is using DSP for the most part and also he is complaing > > u>>about speed and through put. Disabling ppp offloading does slow > > > > u>No DSP installed yet, only the quads > > > > 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. >

I too would like to know about this! We currently run 4.1.72-7 on th equad rack and have not experienced any real problems. We run 4.1.59-1 on the rack with DSPs running 1.2.60 We plan to upgrade both racks next week and want to be absolutely SURE we won't have any difficulties. Want to move to 4.1.59-6 on both HiperArcs and 1.2.43 for the DSPs! ============================================================================== 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 Wed, 24 Mar 1999, Randy McMillan wrote: > Can someone elaborate on the problem with the Hiper 4.1.59-6 code and quad > modems. We are setting up a couple of chassis like that. They seem to work > OK when we are testing it with one modem in use. Although we are having > some problems with our telco, and want to rule out a hiper/quad problem. > > We have T1's > ppp authentication any > ppp authentication_preference PAP > ppp offloading enabled > ppp Receive ACCM disabled > > When the authentication_preference was CHAP, it didn't authenticate for me. > Should I be having problems? and what sort? Also, I don't think I saw > 4.1.62-4 on the USR web site. Thanks. > > Randy McMillan > PacInfo > > ----- Original Message ----- > From: Jeff Binkley <jeff.binkley@asacomp.com> > To: <usr-tc@lists.xmission.com> > Sent: Wednesday, March 24, 1999 2:55 PM > Subject: Re: (usr-tc) RE: (USR-TC) > > > > > > > > > > > > Ok, that's the problem. Krish and I found out that with 4.1.59-6 and > > Quads, you must not have the Preferred protocol set to PAP. Change it > > to DEFAULT or get off of 4.1.59-6 and Quads. We are staying at 4.1.62-4 > > for Quad racks. Krish can elaborate more on the bug if you wish. > > > > > > Jeff Binkley > > ASA Network Computing > > > > > > u>----Original Message----- > > > > > > u>>On Fri, 19 Mar 1999, Jeff Binkley wrote: > > u>>> Krish, > > u>>> Note he has Preferred set to PAP which may be a problem with >quads > > u>as you and I discovered the other day. > > > > u>We only have Quads installed > > > > u>>Well he is using DSP for the most part and also he is complaing > > u>>about speed and through put. Disabling ppp offloading does slow > > > > u>No DSP installed yet, only the quads > > > > 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. >

Hi, I'm in seek of if a RADIUS daemon that supports realms. What I need to be able to do is authenticate users by domain, for example user@my-domain.com and user@reseller-domain.com. Simple accounting is all that is needed which will send basic information back to the acc't server with the user@domain. I would like to stay in the low price range (as in free). I know that Merit AAA supports this, how about the basic Merit server? Cistron? Any others I should know about? Thanks, --t.j. -- T.J. Weber | James: "I hear that if you play the Interplanetary Media | NT 4.0 CD backwards, you phone: 847.205.5200 | get a Satanic message!" fax: 847.205.5201 | Marc: "That's nothing. If you e-mail: tjw@ipmedia.net | play it forward, it installs web: http://www.ipmedia.net | NT 4.0!" He's not dead, he's / You have the right to remain electroencephalographically / silent. Anything you say will challenged. / be misquoted and used against you.

Yes, I noticed that in a seperate Cistron readme file after I posted the message. Thanks to all of those who replied. I'm sure I'm going to have a lot of other questions regarding USR/3com TC equipment. Thanks, --t.j. Dan Hollis wrote: > > On Wed, 24 Mar 1999, T.J. Weber wrote: > > Hi, I'm in seek of if a RADIUS daemon that supports realms. What I need > > to be able to do is authenticate users by domain, for example > > user@my-domain.com and user@reseller-domain.com. > > Cistron does this. > > http://homepage.cistron.nl/~miquels/radius/ > > -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. -- T.J. Weber | James: "I hear that if you play the Interplanetary Media | NT 4.0 CD backwards, you phone: 847.205.5200 | get a Satanic message!" fax: 847.205.5201 | Marc: "That's nothing. If you e-mail: tjw@ipmedia.net | play it forward, it installs web: http://www.ipmedia.net | NT 4.0!" He's not dead, he's / You have the right to remain electroencephalographically / silent. Anything you say will challenged. / be misquoted and used against you.

Trivial with Radiator <http://www.open.com.au/radiator/>, which works great with TC gear as well. On Wed, 24 Mar 1999, T.J. Weber wrote: > > Hi, I'm in seek of if a RADIUS daemon that supports realms. What I need > to be able to do is authenticate users by domain, for example > user@my-domain.com and user@reseller-domain.com. Simple accounting is > all that is needed which will send basic information back to the acc't > server with the user@domain. I would like to stay in the low price > range (as in free). I know that Merit AAA supports this, how about the > basic Merit server? Cistron? Any others I should know about? > > Thanks, > --t.j. > > -- > T.J. Weber | James: "I hear that if you play the > Interplanetary Media | NT 4.0 CD backwards, you > phone: 847.205.5200 | get a Satanic message!" > fax: 847.205.5201 | Marc: "That's nothing. If you > e-mail: tjw@ipmedia.net | play it forward, it installs > web: http://www.ipmedia.net | NT 4.0!" > ---------------------------------------------------------------------- > He's not dead, he's / You have the right to remain > electroencephalographically / silent. Anything you say will > challenged. / be misquoted and used against you. > ---------------------------------------------------------------------- > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Wed, 24 Mar 1999, MegaZone wrote: >Once upon a time Ricky Beam shaped the electrons to say... >>Both. It costs 3Com money to develop the software and people were stealing >>money from them by buying one contract and putting that code on more than >>one chassis. > >Funny that other vendors can give away OS upgrades for free, and they >aren't goign bankrupt. And are even charging per port prices in the same >range as 3Com. And then they give you free support, free management tools... 3Com seems to be selling things based on what it cost to make the card not what it has cost to develop and support the software, etc. >>Do you really want to see 3Com wiring serial number checks in the code to >>prevent you from loading code on a card that isn't under a software support > >I'd like to see them give the upgrades away - but that might mean respecting >the customers and responding to the market. So I won't hold my breath. I never have :-) For all 3Com's craziness, I really like the hardware. Even so much as to learn to deal with their crazy business practices. >>they aren't charging enough for the hardware itself -- the TC hardware is, >>by far, much cheaper than competing hardware. > >Much cheaper? Not that I've seen. Depending on the reseller, specials, >etc, you can find other vendors' gear for less. And prices across the >board continue to decline. 47 USR chassis: dual 70A PS, 12 Quads, dual PRI, NetServer, NMC Cost: ~500k$ (two years ago) - support: 117k$ (full 24/7 hardware+software) 47 Cisco AS5300s: single PS, single 48 port modem card, quad PRI "RSP" Cost: ~1.25M$ (a few months ago) - support: 188k$ (15% of purchase) >Have you seen the latest (free) PM-4 open release? Jesus is it loaded. ><URL:ftp://ftp.livingston.com/pub/le/doc/release/release41b14.txt> - free. >The PM-4 itself is still pricey, but fairly new and prices are dropping. The PM4 is an impressive critter. I would have loved to play with one, but there was this anti-lucent trend (something involving the desire to put cisco gfx on the home page ??? (it's the only thing I can think of)) >I've also seen the notes for 3.9, but that isn't public yet. Equally >loaded, equally free. And there will be a build for the PM-2 - of course >if the PM-2 were 3Com it wou;d be 'obsolete' and 'discontinued' and you'd >be told to 'upgrade' for any 'fix'... Oh, did I get sarcasm on you? We won't talk about their dropping the netserver (a mistake in my opinion, but their NAS programming is far from what I would call "efficient".) If they want to shoot their feet out from under themselves, who am I to stop them? --Ricky

On Wed, 24 Mar 1999, Dan Hollis wrote: >On Wed, 24 Mar 1999, MegaZone wrote: >> >Do you really want to see 3Com wiring serial number checks in the code to >> >prevent you from loading code on a card that isn't under a software support >> I'd like to see them give the upgrades away - but that might mean respecting >> the customers and responding to the market. So I won't hold my breath. > >Responding to the market. Hm. Then why did it take Lucent so long to >support RIPv2. And why does it feel like Lucent is giving users the finger >with the RIPv2 release. Eg "heres your RIPv2, you freaking lamers" Well, I'd agree with the "screw RIP" attitude... the netblazers never did RIPv2 either. Come to think of it, it took IOS 11.1 to get the Cisco's to handle RIPv2 as well. (or was it 10.3? Anyway, we had to update IOS code all over the place. It was a bloody mess.) --Ricky

On Wed, 24 Mar 1999, Jeff Mcadams wrote: >I kinda wondered about that comment too....we haven't seen that its much >cheaper per port than much else, and sometimes more expensive. For the high density stuff yes... for the average ISP (read: quads) the USR hardware is pretty freakin' cheap. (esp. used :-)) >>3Com charges for just about everything. > >"just about?" *ponders trying to think of something that they don't >charge for in normal circumstances* Umm, 3Com NIC drivers are free :-) >>>PS: If you want "free" code updates, participate in the beta program and >>> actually give some feedback. You'll have access to the code before it > >That's assuming they even acknowledge your request to be a part of the >Beta process...hasn't happened yet for me. I didn't have much of a problem... maybe I should go work for IgLou for a few weeks :-) (I still have a palm pilot full of USR contacts.) --Ricky

In the webramp GUI if you go to the advanced configuration section you will find the option to disable the STAC compression. From the command line you can use the setprofile command to do the same. setprofile "-n < profile id> -S < 1- enable 0 - disable>" krish

Hi, last night I posted a question asking about different RADIUS servers that support realms. Thanks for all your replies. My next question is how can I use the RADIUS server to assign different IP addresses. For example, we have two ISPs sharing one TC. When a user logs in, his/her username will be in the format user@domain-1.com or user@domain-2.com. I have decided to use the Cistron RADIUS server because it is free, powerful, and now supports realms. Now what I need to do is assign the default user an address from a different pool. For example, domain-1.com will be using 192.168.1.0/24 and domain-2.com will be using 192.168.2.0/24. How do I configure this in the TC? How do I configure this in RADIUS? Is there anything else that I need to know before I go about doing this? Thanks in advance, --t.j. weber -- T.J. Weber | James: "I hear that if you play the Interplanetary Media | NT 4.0 CD backwards, you phone: 847.205.5200 | get a Satanic message!" fax: 847.205.5201 | Marc: "That's nothing. If you e-mail: tjw@ipmedia.net | play it forward, it installs web: http://www.ipmedia.net | NT 4.0!" He's not dead, he's / You have the right to remain electroencephalographically / silent. Anything you say will challenged. / be misquoted and used against you.

Hello- This is a follow up for the netserver problem I posted yesterday. We still don't have a fix or reason as to why I cannot ping some customers from the box and they cannot ping us. Traceroutes show that the packet is getting to the box and then it dies. Here's part of the show global from the netserver, can anyone see anything wrong with it? PPP in modem: ON SLIP in modem: OFF Packet bus clock: SLAVE ICMP error logging: ON Connect message: ON Dial !root access: OFF Random hosts list: OFF SNMP: OFF Proxy Arp: ON Response message: ON PPP message: ON Lan/Wan Routing: ON RIP V2 Authen: OFF VPN Local Routing: ON MPIP Server: OFF Hint assigned: OFF Tap Login: OFF Syslog facility: auth Extd. IPXCP Opts: OFF Acct AuthChk: OFF/OFF Send DNS info: ON Thanks for any help or pointers anyone can provide. Steve

d baud said once upon a time: > >I am currently trying to switch to another PRI provider, and to do a >gradual move of all my PRIs I would need to have my old PRIs to overflow >(when busy) to some other PRIs in another Central Office (in the same >area code). >The two telcos say that it is technically impossible to program this >feature on the DMS since it is not in the same Central Office. Could >someone confirm if this is true ? They could forward from the last number in your pool, but realize that standard forwarding can only do about 100 calls at one time. So this has its limits.

| |Hi, last night I posted a question asking about different RADIUS servers |that support realms. Thanks for all your replies. My next question is |how can I use the RADIUS server to assign different IP addresses. For |example, we have two ISPs sharing one TC. When a user logs in, his/her |username will be in the format user@domain-1.com or user@domain-2.com. |I have decided to use the Cistron RADIUS server because it is free, |powerful, and now supports realms. Now what I need to do is assign the |default user an address from a different pool. For example, |domain-1.com will be using 192.168.1.0/24 and domain-2.com will be using |192.168.2.0/24. How do I configure this in the TC? How do I configure |this in RADIUS? Is there anything else that I need to know before I go |about doing this? | On the HARC you need to create a "PRIVATE" pool for each isp. In the radius access-accept packet you indicate which pool you want the HARC to assign from by including the pool name in the VSA attribte "Framed-Pool-Name" (0x9024). The RADIUS must support 3com style VSA's. -M

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of |vanhalen@coredcs.com |Sent: Wednesday, March 24, 1999 6:51 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Assistance Needed Help!!!! | | |Thanks for the reply. The problem is that I set it up originally with the |xxx.xxx.47.240 range and all I did was change the start address of the ip |within the 47 network. It worked perfectly fine with the 47.240 range but |when moved to 47.225 it puked. | |The other interesting thing related to this is that the customers who have |a static ip assigned to them are 100% fine and operational. That ip is in |the xxx.xxx.45.xxx range. | |The problem seems _only_ to be with the ip address pool and assignments |from the pool. | Was the .47.225 range used by some other device previously? If so, you may want to check your routers ARP cache and see what MAC address it is using in conjunction with those IP's. Clearing the ARP cache will resolve the problem in that case. I think the Cisco will clear after 4 hours but some other vendors like Bay default to infinity. -M

Me too! This sounds really cool! Thanks-Brian vanhalen@coredcs.com wrote: > I'd be interested in any further info or examples of this implementation > that you can give! > > Steve > > On Thu, 25 Mar 1999, Tatai SV Krishnan wrote: > > > On Thu, 25 Mar 1999, Pete Ashdown wrote: > > > > > C Thompson said once upon a time: > > > > > > >Has anyone gotten > > > > > > > >1) Auth-Type = "Reject:you did not pay your bill" > > > >2) Reply-Message = "Go away" > > > > > > > >types of messages to work with Total Control chasses? > > > > > Man that would be cool. Does Win95/98/NT have the ability to pass messages > > > on to the user? > > > > > > > NT windows do not support this - but here is what you can do, you can do > > on the radius. I have seen a setup where when the user does not pay the > > bill, a script on the server check this and then changes the user to a > > tunnel user. Now when the user dials back he gets to a separate network, > > then when the user brings up say netscape of IE - regardless of what ever > > site he/she wishes to go, the bill payment webpage is displayed. > > > > This does require some changes in DNS server and in setup and was done > > using Hiper arcs. Very cool > > > > krish > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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.

> > Was the .47.225 range used by some other device previously? If so, you may want > to check your routers ARP cache and > see what MAC address it is using in conjunction with those IP's. Clearing the ARP > cache will resolve the problem in that case. I think the Cisco will clear after 4 > hours but some other vendors like Bay default to infinity. > Hello- Thanks for the note. The 47.225 range wasn't used before. We also cleared the ARP cache just in case and for fun. The ARP cache shows the ip's and the correct mac address(the mac address of the net0 interface). The traceroutes still show that the packets are reaching the netserver box fine but then they don't know where to go after that or at least they don't receive a reply back from the ip that we're pinging. In reproducing the problem here when I ping off of the isdn box to one of the 'dead links' I can see the ping make it to the machine I'm pinging. In other words in 95 and NT there's that little picture of two computers near the clock in the taskbar. I can see it blink and the counters increase when I ping it from somewhere on the network to that ip, but the ping never gets answered by the modem/machine I'm dialed in with. Steve

|> |> Was the .47.225 range used by some other device previously? If so, |you may want |> to check your routers ARP cache and |> see what MAC address it is using in conjunction with those IP's. |Clearing the ARP |> cache will resolve the problem in that case. I think the Cisco will |clear after 4 |> hours but some other vendors like Bay default to infinity. |> | |Hello- | |Thanks for the note. The 47.225 range wasn't used before. We also |cleared the ARP cache just in case and for fun. The ARP cache shows the |ip's and the correct mac address(the mac address of the net0 interface). |The traceroutes still show that the packets are reaching the netserver box |fine but then they don't know where to go after that or at least they |don't receive a reply back from the ip that we're pinging. | |In reproducing the problem here when I ping off of the isdn box to one of |the 'dead links' I can see the ping make it to the machine I'm pinging. In |other words in 95 and NT there's that little picture of two computers near |the clock in the taskbar. I can see it blink and the counters increase |when I ping it from somewhere on the network to that ip, but the ping |never gets answered by the modem/machine I'm dialed in with. | What network is the NAS on? Is it 47.x or something else? If its something else make sure that proxy arp is turned on. Also, do you use RIP or static routes? If static make sure that the next hop router knows where to send the replys to.. Can you ping the dial clients from the NAS? And vice-versa? -M

I have a TC Network hub, with a HyperArc, and 2 Hyper DSP cards installed. Plugged in my 2 new PRI's and the phone company is getting remote busy on D channel. Is there a setting that I am over looking for this? How can I unbusy the D channel, the phone co. is saying it is my cards causing the remote busy on D channel. Anyone have any clues? -Steve -- ---------------------------------------------------------------------------- Steve Johnson Sonic Sys Admin (707)522-1001 (33.6kbps) (707)522-1000 (Voice) e-mail linuxnut at sonic.net http://www.sonic.net ---------------------------------------------------------------------------- "Knowing others is wisdom, knowing your self is Enlightenment." -- Lao-Tzu

> Has anyone bothered counting the number of call failures on the > DSP's? I have included a script below which parses through our > SNMP trap logs and generates a simple report on the number of call > failures ordered by modem. The values get reset every midnight. > > Here is a sample of what you get. Note that this report was generated > mid afternoon. I've confident that the top 7 modems have not > had a successful call today. What are your reason's for call failure? I'm not sure how your call routing is set up on your DMS 100 or how you have it set up on the DSP's but I'll bet the guard time you have specified on your DMS 100 is default; which is 70ms I believe. This has been discussed on the list before but I would try changing it to 250ms. This will give the modems more time to reset and make themselves available to take a call after the last call disconnects. You can change this setting on the fly and since you are the telco you will be able to do it in a minute. If this doesn't solve your trouble then please give details on the reasons for call failure as reported by the modems Brian > > Report generated: Fri Mar 19 15:00:01 EST 1999 > > Fails NMC Slot Modem > > 45 10.1.1.102 8 24 > 45 10.1.1.102 8 23 > 26 10.1.4.105 3 16 > 26 10.1.4.105 3 15 > 23 10.1.4.105 14 15 > 22 10.1.4.105 3 6 > 21 10.1.4.105 3 5 > 18 10.1.5.11 15 6 > 18 10.1.5.11 15 5 > (NOTE: The above are all DSP's) > 7 10.1.5.11 6 3 > 7 10.1.5.11 15 8 > 5 10.1.5.11 4 1 > > Notice the trend of sequential pairs of modems with nearly the same > call failure rate? As a witness to many of these reports, I can tell > you this is not even close to a rare occurrence. And forget all the > BS about the 'telco'... at the 10.1.4.* site, _we_are_ the telco. > (The chassis' are barely 10 feet from the DMS100). > > Since this report was generated rather early in the day, the values are > actually low. By the end of the day, most of our pool is full, so these > bad modems are the only ones attempting to take calls. I'll probably have > over 300 failures per bad modem by the end of the day. ("good" modems > only have around 10-12 failures max. per day). > > The only solution I've come up with to fix this is to reboot the DSP. > (Since this is not a desirable solution, I end up busying out the > associated DS0's and waiting until our _weekly_ chassis reboot). Tried > resetting and dis/enabling the modems from the TCM, and soft-resetting the > modems. Doesn't do a darn thing. (BTW: Our code versions are ARC 4.1.72 > and DSP 1.2.60, because I still don't trust the .59 codes... I mean, come > on... a bug fix for a bug fix???) > > > Here's how to set up this report: > > On a Unix machine, set up the UCD-SNMP tools (snmptrapd in particular). > (by default, it will syslog traps to LOG_LOCAL0, which you > direct to /var/log/snmptraps). > Place the MIB files from the mib directory under TCM into the directory > /usr/local/share/snmp/mibs on the UCD-SNMP machine. > Configure all of your modems to SNMP trap Incoming Call Failures to > this machine. (I actually trap all sorts of stuff). This > works with DSP's and Quadmodems. > Install the following scripts into /usr/local/bin. > Add a cron job to run 'publish_badmodems' every half hour. > Let the chaos unfold. > > I don't claim that this will for for everyone. I do know it works > for me. > > --- publish_badmodems --- > #!/bin/sh > > exec 1>/path/to/publish/to/badmodems.html > > echo "<head></head>" > echo " > Report generated: `date`<hr>" > > echo -e "Fails\tNMC\t\tSlot\tModem > <hr>" > nice /usr/local/bin/parsefails > > echo "" > > --- parsefails --- > #!/bin/sh > > if [ -f "$1" ]; then > INFILE="$1" > else > INFILE=/var/log/snmptraps > fi > > egrep -i 'inconnectAttemptFailure|ctConnectAttemptFailure' $INFILE \ > | awk -f /usr/local/sbin/parsefails.awk \ > | sort -n | uniq -c | sort -nr > > --- parsefails.awk --- > /Uptime: [0-9]* days?,/ { gsub("Uptime: [0-9]* days?,","Uptime: ") } > > { gsub("[,:]","") } > > /Trap \(inconnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 } > /Trap \(ctConnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }

Mike Wronski wrote: > On the HARC you need to create a "PRIVATE" pool for each isp. > > In the radius access-accept packet you indicate which pool you want the HARC to > assign from by including > the pool name in the VSA attribte "Framed-Pool-Name" (0x9024). The RADIUS must > support 3com style VSA's. > Thanks for your reply. How do I know if the Cistron RADIUS server supports 3com style VSA's? If it doesn't support it, what would be my next step? Thanks, --t.j. -- T.J. Weber | James: "I hear that if you play the Interplanetary Media | NT 4.0 CD backwards, you phone: 847.205.5200 | get a Satanic message!" fax: 847.205.5201 | Marc: "That's nothing. If you e-mail: tjw@ipmedia.net | play it forward, it installs web: http://www.ipmedia.net | NT 4.0!" He's not dead, he's / You have the right to remain electroencephalographically / silent. Anything you say will challenged. / be misquoted and used against you.

I have seen this also in Harc log but I didn't associate entry with dsp's going empty, which has also happened with no help from imagination. Running 4.1.59-6 and 1.2.59 here. Any info whats it all about is appreciated because I'm having all sort of trouble here with our chassis. There is the dead modem issue that I haven't found an answer yet. If I make a cold start (had to last week) then all seemed to be fine. But in time(week or so) there just couple of modems on some dsp's that begin to die. BTW dead modems seem to like company - there is always a pair of them. "list pbus sess" show for those modems very little packets processed and I guess the reason for their existence is because they are generated in first couple of TCHs uptime days. This issue has probably come up in this list but I couldn't get any search output from list archive today. Has anyone clue why these modems "die"? > I have just noticed this error is syslogs, it seems to reset the whole card. > Though I was imagining things, first the card was full, next it was empty?? > > At 20:40:00, Facility "Driver", Level "CRITICAL":: Deactivating Timer Fired > on interface: slot:15/mod:16 > > > Sean Herr > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. __________________________________ Kalev Nurklik MicroLink Online Sakala 19, 10141 Tallinn, Estonia Tel: +372 6 308 909 Fax: +372 6 308 901 E-mail: k.nurklik@online.ee http://www.online.ee

Steve Johnson said once upon a time: > > >I have a TC Network hub, with a HyperArc, and 2 Hyper DSP cards installed. >Plugged in my 2 new PRI's and the phone company is getting remote busy on D >channel. Is there a setting that I am over looking for this? How can I >unbusy the D channel, the phone co. is saying it is my cards causing the >remote busy on D channel. Anyone have any clues? Make sure your switch type matches what the telco is using. Make sure your cards are configured for "messageOriented" rather than "robbed bit".

On Thu, 25 Mar 1999, Mike Wronski wrote: > What network is the NAS on? Is it 47.x or something else? If its something else > make sure that proxy arp is turned on. Also, do you use RIP or static routes? If > static make sure that the next hop router knows where to send the replys to.. > > Can you ping the dial clients from the NAS? And vice-versa? > > -M > I'm getting really confused by this whole thing now. Proxy arp is on and we use rip. Here's more info yet again: WinNT 4 with LCP Extensions and Software Compression on connecting via an analog USR Sportster I cannot ping the NAS nor can the NAS ping back. However I can see the activity light on NT blink for each ping. It never sends an acknowledgement back though. Turn off LCP and software compression and it works fine everytime - can ping both ways. I followed the thread about disabling the LCP extensions but I thought it was only for HiperArc/DSP that the problem showed up. This box is a Netserver with Quads. A customer with a Cisco 704 ISDN router. I cannot ping them from the NAS but they can move around on the Internet 100% fine and speeds are according to them "incredibly fast." Is this maybe dropping ICMP requests? So far I have noticed no consistent pattern for why I cannot ping some customers and ping others. I don't know the hardware for all customers either which would obviosuly help immensely. Right now the box has an ip address pool in the 70.x range and some customers are working fine on it when they get assigned out of that pool. I just have found no consistent pattern on this problem so I now I'm even doubting whether it's a NAS problem or just a few client problems. Why they are suddenly showing up within the last 22 hours is beyond me and it's the reason that I've been hammering away at it for that long. Thanks for the continued assistance and any other suggestions you might have. Steve

Once upon a time T.J. Weber shaped the electrons to say... >Hi, I'm in seek of if a RADIUS daemon that supports realms. What I need >to be able to do is authenticate users by domain, for example >user@my-domain.com and user@reseller-domain.com. Simple accounting is >all that is needed which will send basic information back to the acc't >server with the user@domain. I would like to stay in the low price >range (as in free). I know that Merit AAA supports this, how about the >basic Merit server? Cistron? Any others I should know about? Cistron does it - and is free. It has more features than the basic (free) Merit by far. The free Lucent 2.1b6 server does it as well - but you need to own a PM. After that you get into commercial turf - Radiator, RADIUS ABM, Port Authority, RadiusNT, Steel-Belted RADIUS, etc. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

In a message dated 3/25/99 3:40:49 PM US Eastern Standard Time, linuxnut@sonic.net writes: > I have a TC Network hub, with a HyperArc, and 2 Hyper DSP cards installed. > Plugged in my 2 new PRI's and the phone company is getting remote busy on D > channel. Is there a setting that I am over looking for this? How can I > unbusy the D channel, the phone co. is saying it is my cards causing the > remote busy on D channel. Anyone have any clues? > How have they set up the Pri's? They didn't set them up from NFAS did they? > -Steve

This is a short history lesson since I couldn't explain the position without context. Feel free to skip.  Once upon a time Dan Hollis shaped the electrons to say... >Any lamer than doing RIPv1 but not RIPv2? I never understood this. How >long does it take to do a RIPv2 implementation from a RIPv1 one? A day or >two max? Why Livingston blew it off for *years*, in favor of the long >development time of a far more complex protocol, Ill never understand. When it finally got done it was done in one afternoon, as I recall. And no, pointy hairs were not involved - Steve Willens wasn't just the founder, CEO and President, he was also Chief Engineer. Everything fell under him. Frankly, Livingston was a small company with only a few full time engineers. I was the 5th person in the support engineering group - and at that time that group was tech support, SQA, Beta, documentation, some new product development, product test, etc. I was the entire email support 'group' for quite a while - I created it basically. I also created their first real website and ran that. It was a fairly small number of people doing an incredible amount of work. I think the development folks were three people, counting Steve. Then one person, Andy, doing host tools and Carl doing RADIUS. Others - myself, Brian Rice, etc - would contribute where we could - debugging, testing, etc. I did the PCMCIA modem testing for the OR-M and developed the first modem table entries for ComOS, etc. It was a fun time, but damn busy. I'd do 48 or 72 shifts frequently. I went a bit too far early on and actually collapsed during a meeting from exhaustion and illness. At first there really wasn't demand for RIPv2. When demand for VLSM/CIDR appeared Steve started on it, but it was one of those things that just got bumped by more important things again and again. Not from any desire not to do it, but from the need to do other things first and having finite resources. Livingston was very lean, which I'm sure helped them maintain their low prices, and the quality of the people made for good products - but it did limit what could be done. We focused on the core product features and producing a solid, reliably product - and that grew the business and allowed for steady growth. I think they had something like 33 consecutive profitable quarters and steady growth. It was a different world - I'd come over from Xylogics which had something like 300 people in the Burlington, MA offices - and had other offices around the world. Livingston had 50-60 people, but had a wider range of products, which had a higher performance and more features (in the IP/IPX world - Xylo did have Appletalk, LAT, etc - ick). It was so much more efficient. Growth really took off with the PM-3. Engineering expanded, along about the same time new departments were created and populated - Beta, SQA, Docs, Web, etc. It was in that era that a dedicated routing engineer position was established, and hence OSPF and BGP appeared in short order. Once the resources werein place OSPF was basically running in a few weeks, ready for release in a couple of months. With that short a development cycle there was no point in releasing RIPv2 right away. The philosophy was always not to support things unless there was enough demand. Keep ComOS lean and fast, and don't bloat it unnecessarily. Since OSPF was popular and RIPv2 demand all but completely dried up, it was shelved. And I was one of those who had been saying we should have RIPv2 released - I changed my mind based on the success of OSPF in ComOS. Other projects died along the way as well. We had Appletalk running in ComOS for a few years, even Apple was using some PMs, but it was decided to shelve AT indefinitely rather than direct engineering resources to polishing it and completing it for open shipment. Obviously it has not appeared in ComOS to this day. The PowerLink128 ISA ISDN BRI card was canceled just before going into production - I still have one in the actual retail box it was to ship in. I've still not seen an ISDN ISA card with performance as high as the PL128. But the market changed during development, which had been prolonged a few times (notably it was about to ship when Win95 shipped - and no one wanted something not PnP for Win95), competing products had appeared and prices had dropped. So they decided to stick with the server market and leave the low-end user to someone else. Such is the business world. I think it is great that they pushed OSPF. Even now I believe RIPv2 is only on the PM-4 - it isn't listed in the notes for ComOS 3.9 on the other platforms. I know that this caused a number of sites to switch to OSPF, or to try OSPF when they would have defaulted to RIPv2. Thereby getting more sites to use a better protocol, and reducing the number running RIPv2 - which I consider braindead. IMHO this is a good thing overall. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time T.J. Weber shaped the electrons to say... >Thanks for your reply. How do I know if the Cistron RADIUS server >supports 3com style VSA's? If it doesn't support it, what would be my It does. BTW, it says so in the READMEs. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

Once upon a time Pete Ashdown shaped the electrons to say... >C Thompson said once upon a time: >>1) Auth-Type = "Reject:you did not pay your bill" I don't know what this is supposed to be. I've never seen a RADIUS server that would understand this. >>2) Reply-Message = "Go away" Now this is allowed by the RFCs to be sent in an Access-Reject. And the NAS should display it ot the user. >Man that would be cool. Does Win95/98/NT have the ability to pass messages >on to the user? But this is the rub - no, it does not. In fact, MOST PPP clients WILL NOT display the message text displayed by the NAS. To see this on Windoze you'd need to have it set to open the console window after dialing. Even on a NAS that does display the text, a normal user using DUN will never see it. Same for the normal MacOS dialer, etc. -MZ -- -=*X I'm going down... under that is! <URL:http://www.aussie-isp.net/> X*=- <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me.. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/> "A little nonsense now and then, is relished by the wisest men" 781-788-0130 <URL:http://www.megazone.org/> <URL:http://www.gweep.net/> Hail Discordia!

On a dual cht1/PRI card, does the RX monitor have the signal received by the NIC from the CO? Thanks.

C Thompson said once upon a time: >Has anyone gotten > >1) Auth-Type = "Reject:you did not pay your bill" >2) Reply-Message = "Go away" > >types of messages to work with Total Control chasses? Man that would be cool. Does Win95/98/NT have the ability to pass messages on to the user?

Has anyone gotten 1) Auth-Type = "Reject:you did not pay your bill" 2) Reply-Message = "Go away" types of messages to work with Total Control chasses? I don't see either type of message either in the Win98 dialer -OR- in a standard HyperTerminal dialup window. I thought I would at least see the message in the latter. It just says "Request Denied" at the HyperTerminal screen, and the Win98 dialer keeps popping up the login/password box. Any ideas? Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net One-seventh of your life is spent on Monday.

We recently upgraded our HARC and ever since (maybe coincidentally) we are getting allot of strange authentication problems. We are set to PAP auth all the way around and are receiving allot of corrupted passwords. 10% of all logons fail due to a bad password (that was input on the uses side correctly). I've run the test a million times using different modems and conditions and none seem to be a specific culprit. Below is an example of the output from our logs. This only appears to happen on the password and not the usernames. I used to call this line noise but it's too consistent to be the case. example excerpts from logs: teen��X� a"�s- hafro& tim� We are at HARC 4.1.59 DSP 1.2.59 and using PRI's for our services. Thanks, Robb Bryn

On Thu, 25 Mar 1999, MegaZone wrote: > But this is the rub - no, it does not. In fact, MOST PPP clients WILL NOT > display the message text displayed by the NAS. To see this on Windoze you'd > need to have it set to open the console window after dialing. Even on a > NAS that does display the text, a normal user using DUN will never see it. > Same for the normal MacOS dialer, etc. > The only dialer that I've seen that actually does this is Trumpet Winsock. I remember being very disappointed when Win95 came out. A simple pop-up display of some sort giving the reason why the connection was denied would have been a wonderful thing for ISPs. I don't know why they didn't add it. Andy -- =========================================================================== Andy Berkvam | "Only two things are infinite, the universe | and human stupidity, and I'm not sure about Email: | the former." aberkvam@coredcs.com | - Albert Einstein (MIME Attachments OK)|-WWW Pages: <http://www.coredcs.com/~aberkvam/> ===========================================================================

I doubt it. PAP is just a simple text based authentication method. YOu would need some sort of app/web page with CGI to do that. Paul D. Farber II Farber Technology Ph. 570-628-5303 Fax 570-628-5545 farber@admin.f-tech.net On Thu, 25 Mar 1999, Pete Ashdown wrote: > C Thompson said once upon a time: > > >Has anyone gotten > > > >1) Auth-Type = "Reject:you did not pay your bill" > >2) Reply-Message = "Go away" > > > >types of messages to work with Total Control chasses? > > Man that would be cool. Does Win95/98/NT have the ability to pass messages > on to the user? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake MegaZone >This is a short history lesson since I couldn't explain the position without >context. Feel free to skip. Twas a nice reminder of past times. :) >Others - myself, Brian Rice, etc - Wow, there's a name I haven't heard in a while. :) >At first there really wasn't demand for RIPv2. When demand for >VLSM/CIDR appeared Steve started on it, but it was one of those things >that just got bumped by more important things again and again. I remember a lot of things getting bumped because there were more important things...and this I don't fault. >Once the resources werein place OSPF was basically running in a few >weeks, ready for release in a couple of months. With that short a >development cycle there was no point in releasing RIPv2 right away. >The philosophy was always not to support things unless there was enough >demand. Keep ComOS lean and fast, and don't bloat it unnecessarily. Since >OSPF was popular and RIPv2 demand all but completely dried up, it was >shelved. And I was one of those who had been saying we should have RIPv2 >released - I changed my mind based on the success of OSPF in ComOS. Keep in mind we had pretty much quit using Livingston gear for USR gear by the time OSPF showed up, so I can't say that I was there for this, but I do disagree somewhat with this mindset. Like it or not, RIPv2 is consider the least common denominator of routing protocols, and support really *should* be in equipment for it. That's the specific case...in the general case, I wasn't particularly fond of Livingston's complete obsession with remaining lean. Really, that was, in the overall scheme of things, what made us quit using Livingston equipment. I can point to several things that specifically were involved, but I won't go into them...heck, MZ, you may remember some of my rants (yes, 3Com isn't the only target of my rants) on portmaster-users :). Suffice it to say that Livingston's obsession with keeping their gear so lean made it an absolute bear to deal with them. Any time you'd ask for a feature, or tech support on a feature that was perhaps not that typical way a feature was used, the attitude gotten back was something along the lines of "Why are you doing it that way? That's not how you're supposed to use the equipment." To be fair...I *still* get this attitude in response to requests to vendors (most notably, 3Com definitely falls into this category :). I made some feature requests from Livingston, and got, quite literally, responses such as "Why on earth would you want that?" As if to say I didn't know what I was talking about, and that the person I was talking to knew how to do my job better than I did. That really irked me when I got responses like that...and they were commonplace at Livingston. When I've made feature requests of 3Com, I typically will end up getting someone asking me how I'm wanting to use it, but usually its more of an effort to be sure they understand how I'm asking to have the feature implemented. For example, when I was working with Buster Joseph to get the prompt_delay feature added to the HiPer Arc code, we went through, in depth, how our dial-in setup was configured on the NETServers so he could be sure he understood how the feature should be implemented on the HiPer Arc. I have no problem with that. The feature got implemented. Several times with Livingston, I was responded to incredulously as above, and the feature never got implemented...I can only assume, based on the response that I was given, that they considered me a crackpot or something for wanting a feature that they didn't immediately understand a need for. FWIW, one of the features I asked of Livingston was the same type of prompt_delay type of thing that I asked for and got implemented in the HiPer Arcs. To my knowledge, ComOS to this day doesn't have anything that would work for this. >I think it is great that they pushed OSPF. Hey, don't get me wrong, I *love* OSPF, and I've got as much of my network running it as possible, and will be thrilled to banish RIPv2 to the nether regions on my network once its available on the Arcs, but these products really do need to support RIPv2 as the lowest common denominator still. >Even now I believe RIPv2 is only on the PM-4 - it isn't listed in the >notes for ComOS 3.9 on the other platforms. I know that this caused a >number of sites to switch to OSPF, or to try OSPF when they would have >defaulted to RIPv2. That's great to get people moved over to OSPF, but I wonder how many sites are now having to run RIPv2 and OSPF and redistribute through a Cisco router to get their Livingston/Lucent gear talking with other gear (perhaps 3Com stuff) that only talks RIPv2. While its great to get people moving over to OSPF, its not yet widespread enough to be the lowest common denominator routing protocol on a system. >Thereby getting more sites to use a better protocol, and reducing the >number running RIPv2 - which I consider braindead. Oh, RIPv2 *is* braindead...won't argue you there, but unfortunately, it is still the LCD of routing protocols, and not having it in equipment is a good way to cut out a significant market. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Thu, 25 Mar 1999, Robb Bryn wrote: > We recently upgraded our HARC and ever since (maybe coincidentally) we are > getting allot of strange authentication problems. We are set to PAP auth > all the way around and are receiving allot of corrupted passwords. 10% of > all logons fail due to a bad password (that was input on the uses side > correctly). I've run the test a million times using different modems and > conditions and none seem to be a specific culprit. Below is an example of > the output from our logs. This only appears to happen on the password and > not the usernames. I used to call this line noise but it's too consistent > to be the case. I'm seeing this as well, along with some other bizarre auth-related difficulties, on which I sent a relatively long report yesterday. HARC 4.1.59-6, DSP 1.2.59 and 1.2.43 Are you running 4.1.59-6 of the HARC code as well? If so, I think I'll try reverting to 4.1.72-7 and see what happens..

On Thu, 25 Mar 1999, Tatai SV Krishnan wrote: > The NAS (Hiper ARc) uses the secret to encrypt the password. Make sure > that you can really decode the password. What you are seeing here could > be the hashed password. Do you really see this when you do a mon ppp on > the hiper arc and also are you using pap when this is done? Pardon my jumping in on this one, but I see it in a mon ppp, and I also have a version of radius that I use for testing that syslogs the attempted password if it fails (after decryption of course) and it comes through garbled there as well...

On Wed, 24 Mar 1999, ROC Services wrote: > I've got a problem with users fairly frequently getting disconnected > immediately after performing PAP, with this message getting syslogged: > > Mar 24 16:00:28 gb-hiper At 22:00:28, Facility "Auth Facility", Level > "COMMON":: Port slot:4/mod:9 successful RADIUS authentication > for user: Pxxxxxxxxx > > Mar 24 16:00:28 gb-hiper At 22:00:28, Facility "PPP", Level "UNUSUAL":: > ../../src/ppp_main.c: PPP Get Option Rejected, (bad status). This is fine - if you have syslog set to critical you will not see this. This says just that one of the ppp options was rejected - which is fine. > > They can usually get connected on the second try. There doesn't seem to > be a pattern to the slot/mod numbers -- they're more or less random > throughout the group. We've got one where they get this every time, but > they're an ISDN customer with what I think may be a misconfigured router. > The others are analog dialups. > > A 'mon ppp' on one of these connection shows the ARC sending a PAP > auth-ack and then nothing after that. In our RADIUS server's log I can > see the auth request and ack, but no accounting records. Logging of > unauthenticated calls isn't enabled on this box. > Well if you see the HiPer arc does send a ack for the ppp user for pap. And it does not get anything back from the client. > Any info would be appreciated. If this is an RTFM issue, someone please > indicate which FM. I suspect it's not, though, as this just started > happening relatively recently. > Try these 1. Set up ppp to any default set ppp recevi any set ppp authe pre default or disable ppp offloading on the hiper arc and see what you get. I would not recommend disable ppp offloading but if you can try it will give a hint on what is happening. krish > [versions] > HARC 4.1.59-6 > DSP 1.2.43 and 1.2.59, some on PRI some on channelized. > Livingston RADIUS 2.0.1, soon to be Cistron RADIUS. > > [relevant config stuff] > PPP offloading: ENABLED > 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: DISABLE > > [mon PPP] > Outgoing PPP Data on interface: slot:4/mod:9 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 50 8a b1 9b > PROTO_COMP > AC_COMP > MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Incoming PPP Data on interface: slot:4/mod:9 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 01 1a 04 > PROTO_COMP > AC_COMP > CALLBACK 06 > > Outgoing PPP Data on interface: slot:4/mod:9 > LCP CFG_REJ CALLBACK 06 > > Incoming PPP Data on interface: slot:4/mod:9 > LCP CFG_REJ MPP_MRRU 05 ea > MPP_ENDPTID 00 > > Outgoing PPP Data on interface: slot:4/mod:9 > LCP CFG_REQ MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 50 8a b1 9b > PROTO_COMP > AC_COMP > > Incoming PPP Data on interface: slot:4/mod:9 > LCP CFG_REQ ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 01 1a 04 > PROTO_COMP > AC_COMP > > Outgoing PPP Data on interface: slot:4/mod:9 > LCP CFG_ACK ASYNC_MAP 00 0a 00 00 > MAGIC_NUM 00 01 1a 04 > PROTO_COMP > AC_COMP > > Incoming PPP Data on interface: slot:4/mod:9 > LCP CFG_ACK MRU 05 ea > ASYNC_MAP 00 00 00 00 > AUTH_TYPE c0 23 > MAGIC_NUM 50 8a b1 9b > PROTO_COMP > AC_COMP > > Incoming PPP Data on interface: slot:4/mod:9 > PAP REQUEST USERNAME = Pxxxxxxxx > PASSWORD = yyyyyyyyy > Outgoing PPP Data on interface: slot:4/mod:9 > PAP ACK ....Tracing the current/next session; > Escape to stop... > Tracing stopped, Return/Enter to re-start, ESCAPE to quit. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Thu, 25 Mar 1999, Robb Bryn wrote: > We recently upgraded our HARC and ever since (maybe coincidentally) we ar= e > getting allot of strange authentication problems. We are set to PAP aut= h > all the way around and are receiving allot of corrupted passwords. 10% o= f > all logons fail due to a bad password (that was input on the uses side > correctly). I've run the test a million times using different modems and > conditions and none seem to be a specific culprit. Below is an example o= f > the output from our logs. This only appears to happen on the password an= d > not the usernames. I used to call this line noise but it's too consisten= t > to be the case. The NAS (Hiper ARc) uses the secret to encrypt the password. Make sure=20 that you can really decode the password. What you are seeing here could=20 be the hashed password. Do you really see this when you do a mon ppp on=20 the hiper arc and also are you using pap when this is done? krish Ps: You can download the radius debugger code from Mike Wronski's site=20 ftp://coredump.ae.usr.com/raddebug and get a snoop/tcpdump to see what is exactly happening? If pap then=20 you can decode the password using this tool. >=20 > example excerpts from logs: > teen=15=9D=CCX=04=9F > a"=A0s- > hafro& > tim=B3 >=20 > We are at HARC 4.1.59 DSP 1.2.59 and using PRI's for our services. >=20 > Thanks, > Robb Bryn >=20 >=20 > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >=20

On Thu, 25 Mar 1999, ROC Services wrote: > On Thu, 25 Mar 1999, Tatai SV Krishnan wrote: > > > The NAS (Hiper ARc) uses the secret to encrypt the password. Make sure > > that you can really decode the password. What you are seeing here could > > be the hashed password. Do you really see this when you do a mon ppp on > > the hiper arc and also are you using pap when this is done? > > Pardon my jumping in on this one, but I see it in a mon ppp, and I also > have a version of radius that I use for testing that syslogs the attempted > password if it fails (after decryption of course) and it comes through > garbled there as well... > Ok - So if you can reproduce it let me know. I can work with you on your chassis to see what is happening. Would need access to your hiper arc. krish >

On Thu, 25 Mar 1999, Pete Ashdown wrote: > C Thompson said once upon a time: > > >Has anyone gotten > > > >1) Auth-Type = "Reject:you did not pay your bill" > >2) Reply-Message = "Go away" > > > >types of messages to work with Total Control chasses? > Man that would be cool. Does Win95/98/NT have the ability to pass messages > on to the user? > NT windows do not support this - but here is what you can do, you can do on the radius. I have seen a setup where when the user does not pay the bill, a script on the server check this and then changes the user to a tunnel user. Now when the user dials back he gets to a separate network, then when the user brings up say netscape of IE - regardless of what ever site he/she wishes to go, the bill payment webpage is displayed. This does require some changes in DNS server and in setup and was done using Hiper arcs. Very cool krish > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Paul Farber <farber@admin.f-tech.net> writes: > I doubt it. PAP is just a simple text based authentication method. Yes, but the Authenticate-Ack and Authenticate-Nak packets of PAP both include room for an optional text message. If I recall correctly (it was quite a while back I checked), I do think that the NETServer stuffed the value in a Reply-Message RADIUS attribute into the packet - not sure about the ARC. However, in my experience, Windows never makes use of that information. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Andy Berkvam <aberkvam@coredcs.com> writes: > The only dialer that I've seen that actually does this is Trumpet > Winsock. I remember being very disappointed when Win95 came out. A > simple pop-up display of some sort giving the reason why the connection > was denied would have been a wonderful thing for ISPs. I don't know why > they didn't add it. I'm not positive, but does Trumpet do PPP with PAP/CHAP or does it use a scripted login? There's a difference between scripting your way into a session (where there is an ASCII prompt/response sequence prior to the start of PPP frames) and using PPP with PAP/CHAP, where the only communication is PPP frames. In the former case, you can trap standard output from a NAS (which many present after the login attempt) including failure messages. In the latter case, there is no such output since you're already in a PPP session that has negotiated LCP and is exchanging frames - this is what DUN does. Of course, the annoying part is that as I noted in an earlier response, PAP does include a facility for including a message within the PPP frame that could be extracted if the clients wanted to. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Thus spake David Bolen >Andy Berkvam <aberkvam@coredcs.com> writes: >> The only dialer that I've seen that actually does this is Trumpet >> Winsock. I remember being very disappointed when Win95 came out. >> A simple pop-up display of some sort giving the reason why the >> connection was denied would have been a wonderful thing for ISPs. >> I don't know why they didn't add it. >I'm not positive, but does Trumpet do PPP with PAP/CHAP or does it use >a scripted login? The later versions would do either. I don't know much of anything about under which circumstances it would print a message from the login. >Of course, the annoying part is that as I noted in an earlier response, >PAP does include a facility for including a message within the PPP >frame that could be extracted if the clients wanted to. Agreed, it would be really nice if this was made use of, but alas, tis not. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

I'd be interested in any further info or examples of this implementation that you can give! Steve On Thu, 25 Mar 1999, Tatai SV Krishnan wrote: > On Thu, 25 Mar 1999, Pete Ashdown wrote: > > > C Thompson said once upon a time: > > > > >Has anyone gotten > > > > > >1) Auth-Type = "Reject:you did not pay your bill" > > >2) Reply-Message = "Go away" > > > > > >types of messages to work with Total Control chasses? > > > Man that would be cool. Does Win95/98/NT have the ability to pass messages > > on to the user? > > > > NT windows do not support this - but here is what you can do, you can do > on the radius. I have seen a setup where when the user does not pay the > bill, a script on the server check this and then changes the user to a > tunnel user. Now when the user dials back he gets to a separate network, > then when the user brings up say netscape of IE - regardless of what ever > site he/she wishes to go, the bill payment webpage is displayed. > > This does require some changes in DNS server and in setup and was done > using Hiper arcs. Very cool > > krish > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

I have to dig through my notes - but sure sometime this week I will come up with a write up and desing for this. krish \ T.S.V. Krishnan \ \ Network System Engineer \ ( : - : ) \ 3Com ............ \ ----------------------------------------------/ tkrishna@bubba.ae.usr.com ----------------------------/ http://interproc.ae.usr.com ----/ The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html Any Sufficiently advanced bug is indistinguishable for a feature. - Rick Kulawiec On Thu, 25 Mar 1999 vanhalen@coredcs.com wrote: > I'd be interested in any further info or examples of this implementation > that you can give! > > Steve > > > On Thu, 25 Mar 1999, Tatai SV Krishnan wrote: > > > On Thu, 25 Mar 1999, Pete Ashdown wrote: > > > > > C Thompson said once upon a time: > > > > > > >Has anyone gotten > > > > > > > >1) Auth-Type = "Reject:you did not pay your bill" > > > >2) Reply-Message = "Go away" > > > > > > > >types of messages to work with Total Control chasses? > > > > > Man that would be cool. Does Win95/98/NT have the ability to pass messages > > > on to the user? > > > > > > > NT windows do not support this - but here is what you can do, you can do > > on the radius. I have seen a setup where when the user does not pay the > > bill, a script on the server check this and then changes the user to a > > tunnel user. Now when the user dials back he gets to a separate network, > > then when the user brings up say netscape of IE - regardless of what ever > > site he/she wishes to go, the bill payment webpage is displayed. > > > > This does require some changes in DNS server and in setup and was done > > using Hiper arcs. Very cool > > > > krish > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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. >

Will you please send me a copy once you do. I'm sure the folks on the Radiator mailing list would be interested as well. I'm having to juggle back and forth between lists sometimes to get info... Thanks for your help. > I have to dig through my notes - but sure sometime this week I will come > up with a write up and desing for this. > > krish WingNET System Administrator 423-559-LINK (v) 423-559-5444 (f)

My users with a few different types of modems are still having trouble connecting to the TC. These same users can connect fine to an Ascend max4004. The two main types of modems involved are iMac modems,Rockwell56k PCI, and a few users with LT winmodems. Most users are OK. Anybody know of any probs with TC and these modems? Here are the usual specifics, let me know if more info would be helpful. TCtrl: 8 PRI - each with own D channel 8 DSP - ver 1.2.43(same prob. with 1.2.59) 1 HARC - ver 4.1.11 (?would this make a diff?) Unit purch. New last Dec. Ascend: 3 PRI - bound on 1 D channel 6 SL-12MOD-S56 modems Software ver 6.1.7 Thanks, Scott Boggs Information Systems Manager United Bank

> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Boggs > Sent: Friday, March 26, 1999 1:41 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) specific modem probs. > > > My users with a few different types of modems are still having trouble > connecting to the TC. These same users can connect fine to an Ascend > max4004. > The two main types of modems involved are iMac modems,Rockwell56k PCI, > and a few users with LT winmodems. Most users are OK. Anybody > know of any > probs > with TC and these modems? Here's the lowdown: LT Winmodems: download the latest driver: 5.39. You can get it from http://www.tidewater.net/56k.shtml. Rockwell 56k PCI: these can be either HCF or ITU modems. HCF are real crap. They need in init string of +ms=v34 to turn off all 56k attempts. The ITU (or non-HCF) Rockwells use an init string of +ms=11,1 or update the drivers from the manufacturer's site. iMac: download the modem updater 1.2.1 from Apple. Or get it on the CD that came with MacAddict(?) in January ( I think. I don't get the mag). Go to http://www.56k.com for more info on the init strings. Wayne Barber Coastal Telco Services

On Mon, 22 Mar 1999, Mike Andrews wrote: > I'm also having a problem that maybe someone else can help with here. The > above init string doesn't disable v.90/x2 correctly on the Quads. (Works > great on DSP's.) If I call in with a Courier, it chokes during the > handshake -- it sounds as if one side is attempting x2 (not v.90) and the > other side is trying v.34. (It dies during the line frequency probe > sequence, in other words.) If I call in with an LT Winmodem it seems to > be more or less OK. > > So... What's the *correct* AT sequence to completely kill all 56K > modulations on a Quad modem and leave v.34 intact? If anyone cares, I fixed this by disabling all 3 x2 modes -- client, server, and symmetric. Apparently disabling just server wasn't good enough for the Quads. Go figure... Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head."

On Fri, 26 Mar 1999, Wayne Barber wrote: > LT Winmodems: download the latest driver: 5.39. You can get it from > http://www.tidewater.net/56k.shtml. > The latest driver is actually 5.43. You can get it from <http://www.808hi.com/56k/x2-lucent.htm>. > iMac: download the modem updater 1.2.1 from Apple. Or get it on the CD that > came with MacAddict(?) in January ( I think. I don't get the mag). > For the iMac and PowerBook G3, you can get the Apple Modem Updater US 1.2.1 from <http://asu.info.apple.com/swupdates.nsf/artnum/n10665>. For other Macs with built-in 56K modems, you can get the Apple/GV 56K Updaters 1.1.3 from <http://asu.info.apple.com/swupdates.nsf/artnum/n11206>. Both of these update Apple modems to the Rockwell 2.2 code. MacAddict occasionally includes Apple Updates on its CD. I know I've seen the modem updates on the CDs but I don't know what months offhand. Andy -- =========================================================================== Andy Berkvam | Freedom of the press is guaranteed only to those | who own one. Email: | - Abbott Joseph Liebling aberkvam@coredcs.com | (MIME Attachments OK)|-WWW Pages: <http://www.coredcs.com/~aberkvam/> ===========================================================================

This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --416219727-1971951701-922491854=:30300 Content-Type: TEXT/PLAIN; charset=US-ASCII OK I am attaching a figure here - Use xfig to open the same. The idea here is to have the users who have not paid their bills to go to a Bill payment web site - irrespective of where ever they want to go. In order to do this you need two HiPer arcs, A radius server with a script that checks for expiration dates and converts the user settings, A DNS server that would fake all the DNS names and your Bill payment web server. The script on the radius server will check for users who have not paid their dues and change their user settings. The user settings are changed such that the users now will actually establish a L2tp or PPTP tunnel. So when the user dials in he/she will see normal ppp connections but in effect the user connection will be terminated on HiPer arc 2. which is a internal intranet. The user will not be able to go to the internet so to check status he/she will try to open their web browser - The DNS server will send all DNS request to the Bill payment web server. Thus no matter where the user wants to go they will see the bill payment server only. If the user tries to go out using a differenet dns or programs a static dns - it does not matter - because they will not go anywhere. The configuration on the HiPer arc side is very easy - Radius and scripts are also very easy but the DNS is a little tricky. Hope this helps. PS: Dont flame me for attachments. regards krish --416219727-1971951701-922491854=:30300 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="reply.fig" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.LNX.3.91.990326174414.30300C@bubba.ae.usr.com> Content-Description: I0ZJRyAyLjENCjgwIDINCjEgMyAwIDEgLTEgMCAwIDAgMC4wMDAwMCAxIDAu MDAwIDE3NCAxMjQgOTcgOTcgMTc0IDEyNCAyNjQgMTU5DQoyIDIgMCAxIC0x IDAgMCAwIDAuMDAwIDAgMCAwDQoJIDI1NCAzMzkgMjU0IDI5NCAxMjkgMjk0 IDEyOSAzMzkgMjU0IDMzOSA5OTk5IDk5OTkNCjIgMiAwIDEgLTEgMCAwIDAg MC4wMDAgMCAwIDANCgkgMjk0IDUwOSAyOTQgNDI0IDk5IDQyNCA5OSA1MDkg Mjk0IDUwOSA5OTk5IDk5OTkNCjIgMiAwIDEgLTEgMCAwIDAgMC4wMDAgMCAw IDANCgkgMTE5IDQyOSAxMTkgNDI5IDExOSA0MjkgMTE5IDQyOSAxMTkgNDI5 IDk5OTkgOTk5OQ0KMiAyIDAgMSAtMSAwIDAgMSAwLjAwMCAwIDAgMA0KCSAx MTkgNDI5IDEzNCA0MjkgMTM0IDQ3NCAxMTkgNDc0IDExOSA0MjkgOTk5OSA5 OTk5DQoyIDEgMCAxIC0xIDAgMCAwIDAuMDAwIC0xIDAgMA0KCSAxNzQgMjE5 IDE3NCAyOTQgMTc0IDI5NCAxNzkgMjg5IDk5OTkgOTk5OQ0KMiAxIDAgMSAt MSAwIDAgMCAwLjAwMCAtMSAwIDANCgkgMTc0IDMzOSAxNzQgNDE5IDk5OTkg OTk5OQ0KMiAyIDAgMSAtMSAwIDAgMCAwLjAwMCAwIDAgMA0KCSA0MzQgMTY0 IDQzNCAxMDkgMzI5IDEwOSAzMjkgMTY0IDQzNCAxNjQgOTk5OSA5OTk5DQoy IDIgMCAxIC0xIDAgMCAwIDAuMDAwIDAgMCAwDQoJIDQxNCA0NDkgNDE0IDM5 NCAzNjQgMzk0IDM2NCA0NDkgNDE0IDQ0OSA5OTk5IDk5OTkNCjIgMiAwIDEg LTEgMCAwIDAgMC4wMDAgMCAwIDANCgkgNTQ0IDM1NCA1NDQgMjQ5IDQ2NCAy NDkgNDY0IDM1NCA1NDQgMzU0IDk5OTkgOTk5OQ0KMiAyIDAgMSAtMSAwIDAg MCAwLjAwMCAwIDAgMA0KCSA3MDkgMjY0IDcwOSAxNTkgNjM0IDE1OSA2MzQg MjY0IDcwOSAyNjQgOTk5OSA5OTk5DQoyIDEgMCAxIC0xIDAgMCAwIDAuMDAw IC0xIDAgMA0KCSAxNzQgMjQ5IDM2NCAyNDkgMzY0IDI0OSAzNjkgMjQ5IDk5 OTkgOTk5OQ0KMiAxIDAgMSAtMSAwIDAgMCAwLjAwMCAtMSAwIDANCgkgMzY5 IDE2NCAzNjkgMzk0IDk5OTkgOTk5OQ0KMiAxIDAgMSAtMSAwIDAgMCAwLjAw MCAtMSAwIDANCgkgMzY5IDMwOSA0NjQgMzA5IDk5OTkgOTk5OQ0KMiAxIDAg MSAtMSAwIDAgMCAwLjAwMCAtMSAwIDANCgkgNTQ5IDI4NCA1NzQgMjg0IDk5 OTkgOTk5OQ0KMiAxIDAgMSAtMSAwIDAgMCAwLjAwMCAtMSAwIDANCgkgNjM0 IDIyNCA1OTQgMjI0IDU5NCAxNzkgOTk5OSA5OTk5DQoyIDEgMCAxIC0xIDAg MCAwIDAuMDAwIC0xIDAgMA0KCSA1OTQgMjI0IDU5NCA0MTQgOTk5OSA5OTk5 DQoyIDEgMCAxIC0xIDAgMCAwIDAuMDAwIC0xIDAgMA0KCSA1NzQgMjg0IDU5 NCAyODQgOTk5OSA5OTk5DQozIDIgMCAxIC0xIDAgMCAwIDAuMDAwIDAgMA0K CSAxODkgNDI0IDE5NCAyNjQgMzg0IDI2NCAzODQgMjk5IDQ3NCAyOTkgNDY5 IDI5OSA5OTk5IDk5OTkNCgkgMC4wMDAgMC4wMDAgMTU5Ljc0MiAzMzUuOTkz IDE2MC45OTIgMjk1Ljk5MyAyNDYuMjM2IDIxMy4zNzANCgkgMzMxLjc1MSAy MTEuNzUyIDM5My42MjUgMjczLjYyNSAzNzQuMzc1IDI4OS4zNzUgNDA4Ljc1 MCAzMjMuNzQ5DQoJIDQ3NC4wMDAgMjk5LjAwMCA0NzQuMDAwIDI5OS4wMDAg NDcyLjc1MCAyOTkuMDAwIDAuMDAwIDAuMDAwDQo0IDAgMCAxMiAwIC0xIDAg MC4wMDAwMCA0IDkgNDAgMTI0IDEwNCBJbnRlcm5ldAENCjQgMCAwIDEyIDAg LTEgMCAwLjAwMDAwIDQgOSA2MSAxNDkgMzE0IENvcmUgUm91dGVyAQ0KNCAw IDAgMTIgMCAtMSAwIDAuMDAwMDAgNCA5IDU3IDE1OSA0ODQgSGlQZXIgQVJD AQ0KNCAwIDAgMTIgMCAtMSAwIDAuMDAwMDAgNCA5IDcxIDM0NCAxMzQgUmFk aXVzIFNlcnZlcgENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAwIDQgOSAyNCAz NjkgNDE5IFdlYgENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAwIDQgOSA1NyA0 NzkgMjg5IEhpUGVyIEFSQwENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAwIDQg OSAyNSA2NDkgMTg5IEROUwENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAwIDQg MTIgMjkgNjQ5IDIwOSBQcm94eQENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAw IDQgOSAzMCA0MTQgMzI0IEV0aDogMgENCjQgMCAwIDEyIDAgLTEgMCAwLjAw MDAwIDQgOSAyNyA1NTQgMzA5IEV0aCAxAQ0KNCAwIDAgMTIgMCAtMSAwIDAu MDAwMDAgNCA5IDI3IDIxNCAyMzQgTDJUUAENCjQgMCAwIDEyIDAgLTEgMCAw LjAwMDAwIDQgOSAxNyAzNzQgNDM0IEJpbGwBDQo0IDAgMCAxMiAwIC0xIDAg MC4wMDAwMCA0IDkgNiA1MDQgMzI5IDIBDQo0IDAgMCAxMiAwIC0xIDAgMC4w MDAwMCA0IDkgNiAyNTkgNDg0IDEBDQo= --416219727-1971951701-922491854=:30300--

Any news about making Sportsters that use to connect fine in X2, 46-48K range connect above 28K with the latest v.90 TC code? I am starting tonight with telling a few tech-aware users how to disable v.90 on thier modems. -----Original Message----- >On Mon, 22 Mar 1999, Mike Andrews wrote: > >> I'm also having a problem that maybe someone else can help with here. The >> above init string doesn't disable v.90/x2 correctly on the Quads. (Works >> great on DSP's.) If I call in with a Courier, it chokes during the >> handshake -- it sounds as if one side is attempting x2 (not v.90) and the >> other side is trying v.34. (It dies during the line frequency probe >> sequence, in other words.) If I call in with an LT Winmodem it seems to >> be more or less OK. >> >> So... What's the *correct* AT sequence to completely kill all 56K >> modulations on a Quad modem and leave v.34 intact? > >If anyone cares, I fixed this by disabling all 3 x2 modes -- client, >server, and symmetric. Apparently disabling just server wasn't good >enough for the Quads. Go figure... > > >Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY >mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a >Microsoft operating system is like a dog without a brick tied to its head." > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

On Fri, 26 Mar 1999, Scott Boggs wrote: > My users with a few different types of modems are still having trouble > connecting to the TC. These same users can connect fine to an Ascend > max4004. Ascend and Rockwell modems would work fine - In this case you are connecting Rockwell to Rockwell, and most likely you are connecting K56. > The two main types of modems involved are iMac modems,Rockwell56k PCI, > and a few users with LT winmodems. Most users are OK. Anybody know of any > probs LT win modems with latest code does not have problems with USR equip. Get the latest LT code for your modems. Any LT code after octover 1998 should be fine. > with TC and these modems? Here are the usual specifics, let me know if more > info would be helpful. > As far as Rockwell is concerned - certain modems with new code should work but there are bugs on Rockwell side that have to be fixed. using 1.2.43 may help a bit but still some issues. krish > TCtrl: > 8 PRI - each with own D channel > 8 DSP - ver 1.2.43(same prob. with 1.2.59) > 1 HARC - ver 4.1.11 (?would this make a diff?) > Unit purch. New last Dec. > > Ascend: > 3 PRI - bound on 1 D channel > 6 SL-12MOD-S56 modems > Software ver 6.1.7 > > Thanks, > Scott Boggs > Information Systems Manager > United Bank > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I have a chassis on PRI's with Quad's and a ARC. All ports numbers are hitting Radius as port 1. My other chassis did this until I upped the code to 4.1.59 and did a reboot. I have done the same on this one with no luck. If I pop in the Netserver card all is fine. My GW Slot is 16 and the calls still terminate on the modems, even after the reboot. When I pop in the Netserver, calls are handled by the Netserver card. The thing that is even more confusing is that the port numbers should start on slot 2 which would actually be port 25???? I cannot figure this out for the life of me, and in the mean time have no concurrency login control. Sean Herr

I've always manged to get LT Winmodems to work. Just disable Flex and v.90. On Fri, 26 Mar 1999, Scott Boggs wrote: > My users with a few different types of modems are still having trouble > connecting to the TC. These same users can connect fine to an Ascend > max4004. > The two main types of modems involved are iMac modems,Rockwell56k PCI, > and a few users with LT winmodems. Most users are OK. Anybody know of any > probs > with TC and these modems? Here are the usual specifics, let me know if more > info would be helpful. > > TCtrl: > 8 PRI - each with own D channel > 8 DSP - ver 1.2.43(same prob. with 1.2.59) > 1 HARC - ver 4.1.11 (?would this make a diff?) > Unit purch. New last Dec. > > Ascend: > 3 PRI - bound on 1 D channel > 6 SL-12MOD-S56 modems > Software ver 6.1.7 > > Thanks, > Scott Boggs > Information Systems Manager > United Bank > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

On Fri, 26 Mar 1999, Tatai SV Krishnan wrote: <snipped excellent way to bite non-paying deadbeat lamers...> Krish, isn't this a little involved? We are currently using a Radius server that uses a flat file generated periodically from a database... in the future it will be a live connection, but instead of setting up a tunnel straight to your billing webserver and wasting a second ARC card, couldn't you just give your deadbeat customer an IP address from an IP address pool of unroutable IP adresses? Say... 10.10.10.10. (I think that's unroutable...) and provide a static route from your TC equipment to a computer that runs a hacked name server, pointing all requests to this system, which is also a webserver (showing a page describing the payment dilemma... and taking credit cards...), a mail server (only giving out a e-bill email) and telnet (logs in, spits out messages and disconnects). With the unroutable address, the customer shouldn't be able to do much else... or is there something here I am overlooking... me thinks this solution only requires updating the Radius records with a static IP, a static route on each ARC/Netserver and a spare system running some TCPIP services... Any thoughts? ----Steve Stephen Amadei Director of MIS Dandy Connections, Inc. Atlantic City, NJ

On Sat, 27 Mar 1999, Stephen Amadei wrote: > On Fri, 26 Mar 1999, Tatai SV Krishnan wrote: > > <snipped excellent way to bite non-paying deadbeat lamers...> > > Krish, isn't this a little involved? Yes it is little involved, the whole configuration including the DNS server etc takes about 5-10 hours of work. > > We are currently using a Radius server that uses a flat file generated > periodically from a database... in the future it will be a live > connection, but instead of setting up a tunnel straight to your billing > webserver and wasting a second ARC card, couldn't you just give your No you are not wasting another arc, you see The second arc has both the interfaces configured. The first interface goes to the private network and the second is still connected to the internet. Essentially you can use both the hiper arc's for regular connection. The beauty of this here is when the customer gets a unroutable address and when they try to access the web - they know what is wrong. This stops the phone calls to your customer service. > deadbeat customer an IP address from an IP address pool of unroutable > IP adresses? Say... 10.10.10.10. (I think that's unroutable...) and > provide a static route from your TC equipment to a computer that runs a > hacked name server, pointing all requests to this system, which is also > a webserver (showing a page describing the payment dilemma... and taking > credit cards...), a mail server (only giving out a e-bill email) and > telnet (logs in, spits out messages and disconnects). > Well the user does get a bogus address - and the only service available to the user is access to the billing server and nothing else. > With the unroutable address, the customer shouldn't be able to do much > else... or is there something here I am overlooking... me thinks this > solution only requires updating the Radius records with a static IP, a > static route on each ARC/Netserver and a spare system running some TCPIP > services... Any thoughts? > This would the easy way out and you do have to make sure that support does know about this and inform them about what to tell the customer. krish > ----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. >

Thus spake Sean Herr >I have a chassis on PRI's with Quad's and a ARC. All ports numbers are >hitting Radius as port 1. My other chassis did this until I upped the >code to 4.1.59 and did a reboot. I have done the same on this one with >no luck. >If I pop in the Netserver card all is fine. >My GW Slot is 16 That's a problem. The GW slot being set to 16 indicates to the PRI card that the card in slot 16 is supposed to terminate the ISDN calls. The Arc can't terminate ISDN calls though, only the Munich card on the NETServer can do that. Set the ISDN GW slot to 0 and that could very likely help. >and the calls still terminate on the modems, even after the reboot. >When I pop in the Netserver, calls are handled by the Netserver card. >The thing that is even more confusing is that the port numbers should >start on slot 2 which would actually be port 25???? Actually, it would be 257. The Arc reserves 256 port numbers for each slot in anticipation of higher density cards down the road. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

It was originally set to 0 but I set it to 16 to not terminate calls on the modems. I was not aware of the Munich card on the netserver was what controlled the calls, I just assumed that the ARC would handle it. Anyway, I set it to 0 with no help. All ports are hitting radius as port1. Any other suggestions? -----Original Message----- Sent: Saturday, March 27, 1999 8:17 AM Thus spake Sean Herr >I have a chassis on PRI's with Quad's and a ARC. All ports numbers are >hitting Radius as port 1. My other chassis did this until I upped the >code to 4.1.59 and did a reboot. I have done the same on this one with >no luck. >If I pop in the Netserver card all is fine. >My GW Slot is 16 That's a problem. The GW slot being set to 16 indicates to the PRI card that the card in slot 16 is supposed to terminate the ISDN calls. The Arc can't terminate ISDN calls though, only the Munich card on the NETServer can do that. Set the ISDN GW slot to 0 and that could very likely help. >and the calls still terminate on the modems, even after the reboot. >When I pop in the Netserver, calls are handled by the Netserver card. >The thing that is even more confusing is that the port numbers should >start on slot 2 which would actually be port 25???? Actually, it would be 257. The Arc reserves 256 port numbers for each slot in anticipation of higher density cards down the road. -- 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.

On Sat, 27 Mar 1999, Sean Herr wrote: > It was originally set to 0 but I set it to 16 to not terminate calls > on the modems. I was not aware of the Munich card on the netserver > was what controlled the calls, I just assumed that the ARC would > handle it. > > Anyway, I set it to 0 with no help. What is the pbus setting set to? Do a show pbus set on the hiper arc. > > All ports are hitting radius as port1. > When you say port1 Guess you are talking about the NAS port - this setting depends on the pbus setting that you have on the hiper arc. The default is sh pbus set PBUS SETTINGS Reported Base :1 Port Density :256 So the first port reported to radius would be 257 and so on. but you can change this also krish > Any other suggestions? > > > > > -----Original Message----- > From: Jeff Mcadams [mailto:jeffm@iglou.com] > Sent: Saturday, March 27, 1999 8:17 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) All Calls Showing Port 1 in radius > > > Thus spake Sean Herr > >I have a chassis on PRI's with Quad's and a ARC. All ports numbers are > >hitting Radius as port 1. My other chassis did this until I upped the > >code to 4.1.59 and did a reboot. I have done the same on this one with > >no luck. > > >If I pop in the Netserver card all is fine. > > >My GW Slot is 16 > > That's a problem. The GW slot being set to 16 indicates to the PRI card > that the card in slot 16 is supposed to terminate the ISDN calls. The > Arc can't terminate ISDN calls though, only the Munich card on the > NETServer can do that. Set the ISDN GW slot to 0 and that could very > likely help. > > >and the calls still terminate on the modems, even after the reboot. > >When I pop in the Netserver, calls are handled by the Netserver card. > > >The thing that is even more confusing is that the port numbers should > >start on slot 2 which would actually be port 25???? > > Actually, it would be 257. The Arc reserves 256 port numbers for each > slot in anticipation of higher density cards down the road. > -- > 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. >

> So when the user dials in he/she will see normal ppp connections but in > effect the user connection will be terminated on HiPer arc 2. which is a > internal intranet. Can't you just term the user on eth:2 of the same arc and make that an internal network? > > regards > > krish Brian Feeny (BF304) signal@shreve.net 318-222-2638 x 109 http://www.shreve.net/~signal Network Administrator ShreveNet Inc. (ASN 11881)

On Sat, 27 Mar 1999, Brian wrote: > > So when the user dials in he/she will see normal ppp connections but in > > effect the user connection will be terminated on HiPer arc 2. which is a > > internal intranet. > > Can't you just term the user on eth:2 of the same arc and make that an > internal network? You can - When we first did the setup the IEA feature was not present in the hiper arc. Come to think of it now yes you can. krish > > > > regards > > > > krish > > ----------------------------------------------------- > 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. >

On Sat, 27 Mar 1999, Charles Sprickman wrote: > It can be really simple if you have IEA. From what I understand, IEA can > basically throw people at a different gateway. Make the gateway a small > box that sits at your pop. Run a web and pop server. The POP server is > could be "DPOP" (a dummy popper that just returns an error message saying > 'pay your bill') and the web server has a page stating that the account is > delinquent. With either FreeBSD (or your os of choice) you simply > configure both of these as "transparent" proxies. No matter what the > person tries to do, the request is caught by the web server... You said, "sits at your pop". What if you have 20 pops? IEA, is cool, and I use it for Xstop, but the problem with VPN-Neighbor, is that it needs that gateway to be directly reachable, which makes it hard to do for a central gateway. I am wondering if actually creating a l2tp/pptp tunnel might be a better way, then all pops could link back to one central machine. I am using VPN-Neighbor for our Xstop users, to take them to an alternate gateway. The xstop box is hanging off the same /24 as the arc's, so this is not a problem. But now in our pops we have arc's which are on a different /24 than our xstop box and also across a router/serial link. Now, I suppose a simple VPN-Neighbor statment would work, if the routes for the network the xstop box or webserver in this case, were sent to the pop via routing protocols. To do this though would mean redistributing ospf routes into rip which is something I am trying to avoid. Right now, we take routes from the arc's at the pops (ripv2) and distribute them into ospf to talk back to our border and our lan. What would need to be done, is also the reverse, taking the routes from the lan (xstop, webserver etc) and distrbuting them into rip from ospf. Then you end up with: ospf--->rip rip---->ospf which can get ugly fast without some smart redistribution filters. And if anyone has a sample redistrubiton filter for two way ospf<--->rip, I would really appreciate a copy, just so I can envision it. When your just redistributing rip into ospf, and not the reverse also, you don't even really need a filter since their is no loop. > > Charles > > -- > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > On Sat, 27 Mar 1999, Tatai SV Krishnan wrote: > > > On Sat, 27 Mar 1999, Brian wrote: > > > > > > So when the user dials in he/she will see normal ppp connections but in > > > > effect the user connection will be terminated on HiPer arc 2. which is a > > > > internal intranet. > > > > > > Can't you just term the user on eth:2 of the same arc and make that an > > > internal network? > > > > You can - When we first did the setup the IEA feature was not present in > > the hiper arc. Come to think of it now yes you can. > > > > krish > > > > > > > > > > > > regards > > > > > > > > krish > > > > > > ----------------------------------------------------- > > > 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)

It can be really simple if you have IEA. From what I understand, IEA can basically throw people at a different gateway. Make the gateway a small box that sits at your pop. Run a web and pop server. The POP server is could be "DPOP" (a dummy popper that just returns an error message saying 'pay your bill') and the web server has a page stating that the account is delinquent. With either FreeBSD (or your os of choice) you simply configure both of these as "transparent" proxies. No matter what the person tries to do, the request is caught by the web server... Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------= On Sat, 27 Mar 1999, Tatai SV Krishnan wrote: > On Sat, 27 Mar 1999, Brian wrote: > > > > So when the user dials in he/she will see normal ppp connections but in > > > effect the user connection will be terminated on HiPer arc 2. which is a > > > internal intranet. > > > > Can't you just term the user on eth:2 of the same arc and make that an > > internal network? > > You can - When we first did the setup the IEA feature was not present in > the hiper arc. Come to think of it now yes you can. > > krish > > > > > > > > regards > > > > > > krish > > > > ----------------------------------------------------- > > 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. >

PBUS SETTINGS Reported Base :1 Port Density :24 Sean Herr @YourNET Connection, Inc. 847-524-3910 http://www.ync.net -----Original Message----- Sent: Saturday, March 27, 1999 12:56 PM Cc: 'usr-tc@lists.xmission.com' On Sat, 27 Mar 1999, Sean Herr wrote: > It was originally set to 0 but I set it to 16 to not terminate calls > on the modems. I was not aware of the Munich card on the netserver > was what controlled the calls, I just assumed that the ARC would > handle it. > > Anyway, I set it to 0 with no help. What is the pbus setting set to? Do a show pbus set on the hiper arc. > > All ports are hitting radius as port1. > When you say port1 Guess you are talking about the NAS port - this setting depends on the pbus setting that you have on the hiper arc. The default is sh pbus set PBUS SETTINGS Reported Base :1 Port Density :256 So the first port reported to radius would be 257 and so on. but you can change this also krish > Any other suggestions? > > > > > -----Original Message----- > From: Jeff Mcadams [mailto:jeffm@iglou.com] > Sent: Saturday, March 27, 1999 8:17 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) All Calls Showing Port 1 in radius > > > Thus spake Sean Herr > >I have a chassis on PRI's with Quad's and a ARC. All ports numbers are > >hitting Radius as port 1. My other chassis did this until I upped the > >code to 4.1.59 and did a reboot. I have done the same on this one with > >no luck. > > >If I pop in the Netserver card all is fine. > > >My GW Slot is 16 > > That's a problem. The GW slot being set to 16 indicates to the PRI card > that the card in slot 16 is supposed to terminate the ISDN calls. The > Arc can't terminate ISDN calls though, only the Munich card on the > NETServer can do that. Set the ISDN GW slot to 0 and that could very > likely help. > > >and the calls still terminate on the modems, even after the reboot. > >When I pop in the Netserver, calls are handled by the Netserver card. > > >The thing that is even more confusing is that the port numbers should > >start on slot 2 which would actually be port 25???? > > Actually, it would be 257. The Arc reserves 256 port numbers for each > slot in anticipation of higher density cards down the road. > -- > 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. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

On Mon, 29 Mar 1999, Info Perthlink wrote: > > > Hi Every one, can some one help me with the Basics of Authentication? > > I will need the following options to meet: > - Be able to cut out users when the system gets busy (Busy hour kick) ( is it done by radius)? TSMON can do this www.tsmon.com > - Downloaded megabytes all radius detail files should contain the amount of data transferred > - Able to generate a report from web (i need Perl?) or MySQL? man billing packages can do this, such as platypus, www.boardtown.com > - Double Connection Deny (and email the user about it) > - Billing (Automatic emailing and Print overdue accounts) TSMON once again > > Either i need to choose Merit AAA (free) - Cisteron radius - Radiusd (lucent) > And either i need aditional scripts. Perl or Mysql are those i thinking > will be the answer > > * additional q? > MySQL is a good Database., Can it have encrypted passwords? is it > suitable for radius as an isp? Thanks. > brian > Jelle Hempenius > > Perthlink.net (net) > aeon.net.au (isp) > paradox.net.au(isp) > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

Hi Every one, can some one help me with the Basics of Authentication? I will need the following options to meet: - Be able to cut out users when the system gets busy (Busy hour kick) ( is it done by radius)? - Downloaded megabytes - Able to generate a report from web (i need Perl?) or MySQL? - Double Connection Deny (and email the user about it) - Billing (Automatic emailing and Print overdue accounts) Either i need to choose Merit AAA (free) - Cisteron radius - Radiusd (lucent) And either i need aditional scripts. Perl or Mysql are those i thinking will be the answer * additional q? MySQL is a good Database., Can it have encrypted passwords? is it suitable for radius as an isp? Thanks. Jelle Hempenius Perthlink.net (net) aeon.net.au (isp) paradox.net.au(isp)

We are running 1.2.59 on our DSP's. Any good reason to upgrade to 1.2.43? It is an upgrade insn't it?

I use and like Radiator (http://www.open.com.au/radiator). It has all the code for Mysql built into it, as well as dual-login checking. It's easy to get any report you need if you log to Mysql. Throw in some PHP (http://www.php.net), and you can create all kinds of web-based administration and reporting tools. Randy

I tried to get info for a few months off and on regarding how to do this. Finally, after some trial and error, and using a customer's connection (with permission) to test, I have found out how to route a network to a customer's connection. Before using RADIUS to do it, I had to set a static route in each Hiper ARC (which stunk). This is an example of how to route a network / subnet to a customer's static IP address. This is using Radiator RADIUS and a 3COM Hiper Arc. Replace all IPs and xxx with valid numbers for your network. Please note that your 'dictionary' file may have slightly different syntax for some of the reply items (e.g. Framed-Address instead of Framed-IP-Address). user Auth-Type = System, Simultaneous-Use = 2 Framed-Protocol = PPP, Service-Type = Framed-User, Framed-IP-Address = 206.30.215.xxx, # customer's static IP address above Framed-Netmask = 255.255.255.255, Framed-Route = "206.30.xxx.0/24 206.30.215.xxx 1", # network to be routed, netmask, static IP of customer, metric Framed-Routing = None, # can be changed to valid entries as defined in the dictionary Routing-Protocol = Rip1, # can be Rip1 or Rip2 Idle-Timeout = 0 # don't drop dedicated customers... It will also work with the setting below. # Framed-Routing = Broadcast-Listen, If Framed-Routing is set to anything besides "None," this will affect the HARM, Networks, IP Networks, username-ip-.... settings. In other words, if set to Broadcast-Listen, then the customer's network will have those settings showing up in their network settings on the Hiper ARC. At this writing, I haven't tried Rip2 yet, but it should work. Rip1 is sending the route to the other Hiper ARCs. I hope this helps someone. If it does, please send me an e-mail and let me know. Have a great day, Craig Thompson WingNET Internet Services, P.O. Box 3000 // Cleveland, TN 37320-3000 423-559-LINK (v) 423-559-5444 (f) http://www.wingnet.net Classic - a book which people praise and don't read.

OK, I've been playing around a bit doing my darndest to work around MPIP brokenness. At this point I've gone to using SNMP to reset the MPIP server state in the MPIP server. This has two benefits...1) the MPIP server is only offline for approximately 5 seconds (long enough for a couple of snmpsets and snmpgets to the MPIP server) rather than the 2 minutes or so that resulted from a full HiPer Arc reboot (man those things take a long time to boot up), and 2) it allows me to put the MPIP server on a HiPer Arc that is actively taking calls since I don't have to reboot the whole thing resulting in disconnected calls. This allows me to replace one more NETServer without further expenditure. Neither of these two things results in huge improvements, but I can deal with incremental if quantum improvements aren't possible. With further exploration into the SNMP information stored in the HiPer Arcs, it seems that all of the MPIP server information (bundles, userids, EDO types and values, bundle owners, link owners, etc.) are all available through MPIP. This is a good thing. :) However, attempts to alter, delete, or anything like that have failed. This *could* be because I'm still pretty much a newbie at SNMP, but I don't think so. I'm looking at using SNMP for all of this because it is considerably more scriptable than dealing with the CLI. My questions come down to: 1) is it possible to alter the data that the MPIP server has in its data directly...ie, without altering it on the client side and letting the client transmit this information to the MPIP server? I ask this because we still have NETServers in service and altering the MPIP data from the client side on the NETServers is not possible. Also, because the problem with the MPIP protocol as a whole seems to be that the MPIP server is either missing, or mishandling deregistration request(s) from clients....the clients think the bundle is deregistered, but the server doesn't actually deregister it (from what I can tell anyway). 2) if the answer to the above question is that its not possible...can it be made to be possible? (call this a feature request I guess). Since MPIP is unreliable at best at the moment, the ability to manually go in and clean out the phantom, cruft MPIP bundles out of the MPIP server would be useful as a possible workaround. The ability to do this through SNMP would be most helpful as well (again, for scriptability reasons). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

OK...still getting a bit acclimated to the Arcs... Perhaps I'm missing an easy one here. Is there any way to see where a tunneled link is tunneled *from* on a HiPer Arc? Ie, on the NETServers you can do a show bun to see the MP bundle head, and then do a show netports to see which NAS the other links of the bundle are connecting from. This is very convenient since it lets you trace back from a traceroute to the bundle head, and then from the bundle head, see where the other links are connected. I know you can do a list mpip links on the MPIP server to show where all the links are connected, but if you do a lot of MPIP, that can get rather hairy to see where everything is matching up. There's also a list tunnel connections on the bundle head that shows the tunnel interfaces and usernames, but no way that I found to be able to match that up to the source of the tunnel. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

On Mon, 29 Mar 1999, Suncoast Networking USR Mailbox wrote: > Up until now we've used GTE for our PRI's setup as NI2. > Our first CLEC PRI went in today on a PRI NIC/NAC with an > existing GTE PRI already operating. e.Spire is showing we > have set the pri out of service locally, and all the lines > of course get the standard busy signal. I'm showing everything > looks good, except that no calls can get through. Are we talking HDM's or dual PRI cards here? if hdm, check out chdev span dis spnstats show us the output also dis atstat > > I'm showing D channel up, all DS0's In Service. The only > difference between the GTE PRI's and the e.Spire PRI is NI2 > vs. 5ESS. I can put the GTE PRI on either port, set it to NI2, > and it fires right up. I can put the e.Spire PRI on either > port, set for NI2 or 5ESS, and it won't come up. I've tried if on an hdm do: chdev span cmd svspcfg > changing the span to in service (option 17). I've also tried > bringing up the rack with just the new PRI, and swapped the > T1 interface card, still no go. Rebooting and power cycling > along the way. B8ZS, ESF. Any ideas would be welcomed. > ok, sounds like dual PRI, its been a while since I have done anything with that, but more than likely its a telco screwup since their isn't a whole lot that really matters with PRI (b8zs, esf, switchtype). How much buildout are you running? How far is the telco equipment from your tc? > Thanks, > Steve Kinkaid > Suncoast Networking > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

Up until now we've used GTE for our PRI's setup as NI2. Our first CLEC PRI went in today on a PRI NIC/NAC with an existing GTE PRI already operating. e.Spire is showing we have set the pri out of service locally, and all the lines of course get the standard busy signal. I'm showing everything looks good, except that no calls can get through. I'm showing D channel up, all DS0's In Service. The only difference between the GTE PRI's and the e.Spire PRI is NI2 vs. 5ESS. I can put the GTE PRI on either port, set it to NI2, and it fires right up. I can put the e.Spire PRI on either port, set for NI2 or 5ESS, and it won't come up. I've tried changing the span to in service (option 17). I've also tried bringing up the rack with just the new PRI, and swapped the T1 interface card, still no go. Rebooting and power cycling along the way. B8ZS, ESF. Any ideas would be welcomed. Thanks, Steve Kinkaid Suncoast Networking

Are the Netserver cards susceptible to ping attacks? If so which ones and what is the command to filter against them? I seem to be having a problem that looks like the oob attack on an NT machine. Throughput slows down to a crawl and then just stops. The Netserver card seems to freeze and must be rebooted. Russ Miescke Power Web Connect

Yes, this is a PRI NIC/NAC combo, not an HDM. I'm not sure what you mean by "how much" build out. The local loop goes to the local CO, which is only about 1000 yards from here. We have other PRI's out of there working fine. This new Exchange Carrier and their switch is about 30 miles from here. The Demarc/CPE is 10 feet from the racks. After following another suggestion I received of pulling just the PRI cards back and front, I'm getting an error repeated about 10 times after the PRI card boots of= ERR:ucc_gen_error,ucc_null,bad event;,err:3 Does anyone know what that means? Thanks Again, Steve Kinkaid Suncoast Networking > >> Up until now we've used GTE for our PRI's setup as NI2. >> Our first CLEC PRI went in today on a PRI NIC/NAC with an >> existing GTE PRI already operating. e.Spire is showing we >> have set the pri out of service locally, and all the lines >> of course get the standard busy signal. I'm showing everything >> looks good, except that no calls can get through. > >Are we talking HDM's or dual PRI cards here? > >if hdm, check out > >chdev span >dis spnstats > >show us the output > >also dis atstat > >> >> I'm showing D channel up, all DS0's In Service. The only >> difference between the GTE PRI's and the e.Spire PRI is NI2 >> vs. 5ESS. I can put the GTE PRI on either port, set it to NI2, >> and it fires right up. I can put the e.Spire PRI on either >> port, set for NI2 or 5ESS, and it won't come up. I've tried > >if on an hdm do: > >chdev span >cmd svspcfg > >> changing the span to in service (option 17). I've also tried >> bringing up the rack with just the new PRI, and swapped the >> T1 interface card, still no go. Rebooting and power cycling >> along the way. B8ZS, ESF. Any ideas would be welcomed. >> > >ok, sounds like dual PRI, its been a while since I have done anything with >that, but more than likely its a telco screwup since their isn't a whole >lot that really matters with PRI (b8zs, esf, switchtype). How much >buildout are you running? How far is the telco equipment from your tc? > > >Thanks, > Steve Kinkaid >> Suncoast Networking >> >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the 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. > >

For what its worth, I block ICMP 8 at the firewall/router to all the netserver net0 IP's... I believe that Microsoft stopped the oob attacks against NT and 95 in a patch several months ago. Have you tried the netstat command on the NT server to see what its talking to? Steve Kinkaid Suncoast Networking >Are the Netserver cards susceptible to ping attacks? If so which ones and >what is the command to filter against them? I seem to be having a problem >that looks like the oob attack on an NT machine. Throughput slows down to a >crawl and then just stops. The Netserver card seems to freeze and must be >rebooted. >Russ Miescke >Power Web Connect > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

I can't remember if they're vulnerable or not... but there's at least one other possible explanation for those symptoms: running out of RAM. Do a "show mem" every so often and see if you're losing lots of ram over the course of a few days. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a Microsoft operating system is like a dog without a brick tied to its head." On Mon, 29 Mar 1999, Russ Miescke wrote: > Are the Netserver cards susceptible to ping attacks? If so which ones and > what is the command to filter against them? I seem to be having a problem > that looks like the oob attack on an NT machine. Throughput slows down to a > crawl and then just stops. The Netserver card seems to freeze and must be > rebooted. > Russ Miescke > Power Web Connect > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

I thought about the ram problem. Doesn't seem to lose much at all. This was running fine until 3 weeks ago. The freeze ups seem to happen between 6-10pm. They do not happen on the weekend or ever during the day. Too much of a pattern for me. Russ Miescke Power Web Connect ----- Original Message ----- Sent: Tuesday, March 30, 1999 12:59 AM > I can't remember if they're vulnerable or not... but there's at least > one other possible explanation for those symptoms: running out of RAM. > Do a "show mem" every so often and see if you're losing lots of ram over > the course of a few days. > > > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a > Microsoft operating system is like a dog without a brick tied to its head." > > On Mon, 29 Mar 1999, Russ Miescke wrote: > > > Are the Netserver cards susceptible to ping attacks? If so which ones and > > what is the command to filter against them? I seem to be having a problem > > that looks like the oob attack on an NT machine. Throughput slows down to a > > crawl and then just stops. The Netserver card seems to freeze and must be > > rebooted. > > Russ Miescke > > Power Web Connect > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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.

I have the NT servers patched. This is only happening to the netserver Card. Russ Miescke Power Web Connect ----- Original Message ----- Sent: Tuesday, March 30, 1999 12:06 AM > For what its worth, I block ICMP 8 at the firewall/router to all the > netserver net0 IP's... I believe that Microsoft stopped the oob > attacks against NT and 95 in a patch several months ago. Have you > tried the netstat command on the NT server to see what its talking > to? > > Steve Kinkaid > Suncoast Networking > > >Are the Netserver cards susceptible to ping attacks? If so which ones and > >what is the command to filter against them? I seem to be having a problem > >that looks like the oob attack on an NT machine. Throughput slows down to a > >crawl and then just stops. The Netserver card seems to freeze and must be > >rebooted. > >Russ Miescke > >Power Web Connect > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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. >

Thus spake Suncoast Networking USR Mailbox >Up until now we've used GTE for our PRI's setup as NI2. >Our first CLEC PRI went in today on a PRI NIC/NAC with an >existing GTE PRI already operating. e.Spire is showing we >have set the pri out of service locally, and all the lines >of course get the standard busy signal. I'm showing everything >looks good, except that no calls can get through. If you've got all your cause codes set to 17 (normal busy), try changing them one by one to 58 (which should generate a fast busy or some sort of message depending on the switch) and place a call between each one and see when it changes. That will at least tell you what condition on the card is causing the problem...that is *if* the calls are at least getting to the card. I've never known a PRI to get a normal busy when the calls aren't even making it to the PRI card, typically you'll get a fast busy/all circuits busy message if the telco generates it since PRI's are trunk-side. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

All the cause codes are currently set to 58. Calls to the PRI get a normal busy. Should I try the reverse, setting them to 17? Thanks, Steve Kinkaid Suncoast Networking >Thus spake Suncoast Networking USR Mailbox >>Up until now we've used GTE for our PRI's setup as NI2. >>Our first CLEC PRI went in today on a PRI NIC/NAC with an >>existing GTE PRI already operating. e.Spire is showing we >>have set the pri out of service locally, and all the lines >>of course get the standard busy signal. I'm showing everything >>looks good, except that no calls can get through. > >If you've got all your cause codes set to 17 (normal busy), try changing >them one by one to 58 (which should generate a fast busy or some sort of >message depending on the switch) and place a call between each one and >see when it changes. That will at least tell you what condition on the >card is causing the problem...that is *if* the calls are at least >getting to the card. I've never known a PRI to get a normal busy when >the calls aren't even making it to the PRI card, typically you'll get a >fast busy/all circuits busy message if the telco generates it since >PRI's are trunk-side. >-- >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. > >

Ok Steve, your overnight nap is over... I set the cause codes to 17, no effect on calls. Still ringing regular busy to all access numbers. Here's the configuration. Again, except for switch type, this setup and configuration is working on the GTE pri's. The only difference is the switch types. Framing Mode ds1ESF Line COding Options b8zs Response to Loopback - ignore Jitter Attenuation attenJitterOnXmtr Transmitter Attenuation dB0 Primary Switch Type Set priSw5ESS Idle byte Patter 254 (0xFE) Call Proceeding/Connect on Setup on ALERTING Response on setup off Overlap RX mode diable --- Cause Codes - All = 58 (Also tried 17 no effect) ---- PRI Span Block Call Type - blocknone ---- NFAS ID - 0 NFAS D Channel Use - dchannel ---- DS0 Identification (Blanks) Block Call Type = blockNone across the row DS0 Assigned Slot Number = 2,3,4,etc (Ignored, using First Avail) DS0 Assigned Channel Number = 1,2,3,4,1,etc ---- DS0 Service Configuration - inService -> Across the row except dchannels, notSupported ---- ShortHaulNic - NotApplicable ____ Timing Priority - Tried 1-2, 2-1, no effect.... Steve Kinkaid Suncoast Networking >All the cause codes are currently set to 58. Calls to the >PRI get a normal busy. Should I try the reverse, setting >them to 17? > >Thanks, > Steve Kinkaid > Suncoast Networking > >>Thus spake Suncoast Networking USR Mailbox >>>Up until now we've used GTE for our PRI's setup as NI2. >>>Our first CLEC PRI went in today on a PRI NIC/NAC with an >>>existing GTE PRI already operating. e.Spire is showing we >>>have set the pri out of service locally, and all the lines >>>of course get the standard busy signal. I'm showing everything >>>looks good, except that no calls can get through. >> >>If you've got all your cause codes set to 17 (normal busy), try changing >>them one by one to 58 (which should generate a fast busy or some sort of >>message depending on the switch) and place a call between each one and >>see when it changes. That will at least tell you what condition on the >>card is causing the problem...that is *if* the calls are at least >>getting to the card. I've never known a PRI to get a normal busy when >>the calls aren't even making it to the PRI card, typically you'll get a >>fast busy/all circuits busy message if the telco generates it since >>PRI's are trunk-side. >>-- >>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. > >

Check out the Active Primary Switch type on your PRI. With one of the CLEC's we use it was seeing the PRI as 4ESS switch type. We changed the setting and everything worked great. > > Ok Steve, your overnight nap is over... I set the cause codes to 17, > no effect on calls. Still ringing regular busy to all access numbers. > > Here's the configuration. Again, except for switch type, > this setup and configuration is working on the GTE pri's. The only > difference is the switch types. > > Framing Mode ds1ESF > Line COding Options b8zs > Response to Loopback - ignore > Jitter Attenuation attenJitterOnXmtr > Transmitter Attenuation dB0 > Primary Switch Type Set priSw5ESS > Idle byte Patter 254 (0xFE) > Call Proceeding/Connect on Setup on > ALERTING Response on setup off > Overlap RX mode diable > --- > Cause Codes - All = 58 (Also tried 17 no effect) > ---- > PRI Span Block Call Type - blocknone > ---- > NFAS ID - 0 > NFAS D Channel Use - dchannel > ---- > DS0 Identification (Blanks) > Block Call Type = blockNone across the row > DS0 Assigned Slot Number = 2,3,4,etc (Ignored, using First Avail) > DS0 Assigned Channel Number = 1,2,3,4,1,etc > ---- > DS0 Service Configuration - inService -> Across the row > except dchannels, notSupported > ---- > ShortHaulNic - NotApplicable > ____ > > Timing Priority - Tried 1-2, 2-1, no effect.... > > Steve Kinkaid > Suncoast Networking > > > >All the cause codes are currently set to 58. Calls to the > >PRI get a normal busy. Should I try the reverse, setting > >them to 17? > > > >Thanks, > > Steve Kinkaid > > Suncoast Networking > > > >>Thus spake Suncoast Networking USR Mailbox > >>>Up until now we've used GTE for our PRI's setup as NI2. > >>>Our first CLEC PRI went in today on a PRI NIC/NAC with an > >>>existing GTE PRI already operating. e.Spire is showing we > >>>have set the pri out of service locally, and all the lines > >>>of course get the standard busy signal. I'm showing everything > >>>looks good, except that no calls can get through. > >> > >>If you've got all your cause codes set to 17 (normal busy), try changing > >>them one by one to 58 (which should generate a fast busy or some sort of > >>message depending on the switch) and place a call between each one and > >>see when it changes. That will at least tell you what condition on the > >>card is causing the problem...that is *if* the calls are at least > >>getting to the card. I've never known a PRI to get a normal busy when > >>the calls aren't even making it to the PRI card, typically you'll get a > >>fast busy/all circuits busy message if the telco generates it since > >>PRI's are trunk-side. > >>-- > >>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. > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Thus spake Suncoast Networking USR Mailbox >All the cause codes are currently set to 58. Calls to the >PRI get a normal busy. Should I try the reverse, setting >them to 17? No, 58 will generate a fast busy...meaning that the calls aren't even making it to the PRI card. Sounds like something is messed up in the provisioning somewhere. :/ -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

-> Thus spake Suncoast Networking USR Mailbox -> >Up until now we've used GTE for our PRI's setup as NI2. -> >Our first CLEC PRI went in today on a PRI NIC/NAC with an -> >existing GTE PRI already operating. e.Spire is showing we -> >have set the pri out of service locally, and all the lines -> >of course get the standard busy signal. I'm showing everything >looks good, -> except that no calls can get through. -> -> If you've got all your cause codes set to 17 (normal busy), try changing -> them one by one to 58 (which should generate a fast busy or some sort of -> message depending on the switch) and place a call between each one and see -> when it changes. That will at least tell you what condition on the card is -> causing the problem...that is *if* the calls are at least getting to the -> card. I've never known a PRI to get a normal busy when the calls aren't -> even making it to the PRI card, typically you'll get a fast busy/all -> circuits busy message if the telco generates it since PRI's are trunk-side. Jeff, Is there a listing of all of the cause codes available ? Jeff Binkley ASA Network Computing

On Tuesday, March 30, 1999 9:29 AM, usrtcmail@flasuncoast.Net [SMTP:usrtcmail@flasuncoast.Net] wrote: > Here's the configuration. Again, except for switch type, > this setup and configuration is working on the GTE pri's. The only > difference is the switch types. > ---- > DS0 Service Configuration - inService -> Across the row > except dchannels, notSupported > ---- What does your performance monitor tell you in the Timeslot Status and DS0 in service state status columns for each DS0? They should say idle and inService in each column respectively. Do the telco guys see the trunks and d channel as being up and idle?

Suncoast Networking USR Mailbox said once upon a time: > >For what its worth, I block ICMP 8 at the firewall/router to all the >netserver net0 IP's... I believe that Microsoft stopped the oob >attacks against NT and 95 in a patch several months ago. Have you >tried the netstat command on the NT server to see what its talking >to? I block *ALL* traffic at our borders that is headed to Total Control equipment. There is no good reason (at least on this network) that the TC's need to talk to the outside world.

On Tue, 30 Mar 1999, Pete Ashdown wrote: > Suncoast Networking USR Mailbox said once upon a time: > > > >For what its worth, I block ICMP 8 at the firewall/router to all the > >netserver net0 IP's... I believe that Microsoft stopped the oob > >attacks against NT and 95 in a patch several months ago. Have you > >tried the netstat command on the NT server to see what its talking > >to? > > I block *ALL* traffic at our borders that is headed to Total Control > equipment. There is no good reason (at least on this network) that the > TC's need to talk to the outside world. We use a whitelist on our access controls on our border, everything is denied, and only specifics are permitted, such as web to the webserver, etc. Nothing is permitted to the TC's. Of course the dynamic ip pools are unrestrictred. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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)

On Tue, 30 Mar 1999, Suncoast Networking USR Mailbox wrote: > Pete, > > On the Netserver? If you completely blocked the IP of net0, > which is essentially a gateway, how will your dial-up users > traffic route? > > Steve Kinkaid > Suncoast Networking right, its a gateway, that talks to an ethernet interface on/behind his border. There is no reason for packets to come from accross the border and too eth interfaces of his ARC's/Netservers. Traffic to the dialup ip pools I am sure is unrestricted, or with very little restriction (we block port 25 on outgoing from dynamic ip pools). Smart ISP's would block all traffic to their lan, accept for what is implicity allowed, such as mail to mail server, web to webserver, dns to nameservers, etc. the other approach is to allow all, and deny the bad guys, but that is a bad way of doing it, I would argue its better to treat all traffic as bad, accept for what you deam good. > > > >Suncoast Networking USR Mailbox said once upon a time: > >> > >>For what its worth, I block ICMP 8 at the firewall/router to all the > >>netserver net0 IP's... I believe that Microsoft stopped the oob > >>attacks against NT and 95 in a patch several months ago. Have you > >>tried the netstat command on the NT server to see what its talking > >>to? > > > >I block *ALL* traffic at our borders that is headed to Total Control > >equipment. There is no good reason (at least on this network) that the > >TC's need to talk to the outside world. > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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)

Pete, On the Netserver? If you completely blocked the IP of net0, which is essentially a gateway, how will your dial-up users traffic route? Steve Kinkaid Suncoast Networking >Suncoast Networking USR Mailbox said once upon a time: >> >>For what its worth, I block ICMP 8 at the firewall/router to all the >>netserver net0 IP's... I believe that Microsoft stopped the oob >>attacks against NT and 95 in a patch several months ago. Have you >>tried the netstat command on the NT server to see what its talking >>to? > >I block *ALL* traffic at our borders that is headed to Total Control >equipment. There is no good reason (at least on this network) that the >TC's need to talk to the outside world. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

I set up the MPIP stuff and have noticed that on the hub acting as the server, it keeps bundles alive even though the user has dropped. Any ideal on how to manually remove MPIP links from the server? Thanks, Mark Green Apple Inc

usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes: > Ok Steve, your overnight nap is over... I set the cause codes to 17, > no effect on calls. Still ringing regular busy to all access numbers. If you can receive and/or log SNMP traps, enable the PRI span level traps for the card in question, at a minimum either "callArriveEvent" or "callTermFailedEvent". The arrive trap is generated the instant that the PRI card gets an inbound call signal (setup message on the D channel) from the telco - regardless of whether or not it is going to be able to service the call. The failed trap is generated anytime the PRI gets a call arrival indication (D channel setup) but is unable for any reason to service the call, connecting it to some other device (modem or NETServer) in the hub. If you don't receive either of these traps, then the telco isn't even sending calls to your card, and the problem is earlier than the card. If you do receive the traps, the failed trap contains some reason information for the failure that may help. You might also check the debug screen (Ctrl-D) option 11 (call control counters) and print the error counters. That might give some insight into any cases where the PRI got a call but couldn't deliver it successfully to a modem. You can then track these to specific modems using option 10 (IGW/QBMDM information) suboption 11 (Mdm Dev Table) to get various call counters on a per modem basis. There are some other counters to check calls that may have been dropped for other reasons. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Now that is cool!! (Control-D) Thank you! Option 11 shows no errors. Option 10 GPF's the card. Option 4 shows some interesting call control debugging information. When I unplug or plug in Span 0, it detects it, and reports the span is down, up, etc. But calling the associated numbers to that PRI don't show up here at all. I'll have to spend a little more time to see what I can glean from those SNMP strings. I kicked it back to the CLEC this morning. They said they would get back with me. They turned it over to the switch guys. I've continued to work on it on and off today, but now I'm pretty certain the problem is not with the TC. The response has been fantastic! Thanks for all the great suggestions! Steve Kinkaid Suncoast Networking Largo, Florida >usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes: > >> Ok Steve, your overnight nap is over... I set the cause codes to 17, >> no effect on calls. Still ringing regular busy to all access numbers. > >If you can receive and/or log SNMP traps, enable the PRI span level >traps for the card in question, at a minimum either "callArriveEvent" >or "callTermFailedEvent". > >The arrive trap is generated the instant that the PRI card gets an >inbound call signal (setup message on the D channel) from the telco - >regardless of whether or not it is going to be able to service the >call. > >The failed trap is generated anytime the PRI gets a call arrival >indication (D channel setup) but is unable for any reason to service >the call, connecting it to some other device (modem or NETServer) in >the hub. > >If you don't receive either of these traps, then the telco isn't even >sending calls to your card, and the problem is earlier than the card. >If you do receive the traps, the failed trap contains some reason >information for the failure that may help. > >You might also check the debug screen (Ctrl-D) option 11 (call control >counters) and print the error counters. That might give some insight >into any cases where the PRI got a call but couldn't deliver it >successfully to a modem. You can then track these to specific modems >using option 10 (IGW/QBMDM information) suboption 11 (Mdm Dev Table) >to get various call counters on a per modem basis. There are some >other counters to check calls that may have been dropped for other >reasons. > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | UUNET Technologies, Inc. \ Phone: (914) 701-5327 | > / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ >\-----------------------------------------------------------------------/ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >