October 1998

Subject: RE: (usr-tc) MRTG cfg
From: Eric Billeter <ebilleter@cableone.net>
Date: 1998-10-01 09:47:31

This is a multi-part message in MIME format. ------=_NextPart_000_0251_01BDED20.82BA3660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Here is my solution.. you can see the results at http://mrtg.cableone.net Any input on better code is appreciated.. I am NOT a programmer, I prefer to work on the hardware type stuff. 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 Jamie Orzechowski Sent: Wednesday, September 30, 1998 12:39 PM I was wondering if anyone is using MRTG to graph modem usage via MRTG .. if so could somone post sample MRTG cfg files ... thanks! Jamie Orzechowski RipNET Internet System Administrator Tel.: (613)342-3946 ext 293 Tel.: (800)267-4434 ext 293 Fax.: (613)342-8672 Page.: (613)341-0883 EMail.: mailto:mhz@recorder.ca Web.: http://www.moonchilli.com There is a $50 Fee for the processing of unsolicited EMail send to this 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. ------=_NextPart_000_0251_01BDED20.82BA3660 Content-Type: application/x-zip-compressed; name="TCH-mrtg.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="TCH-mrtg.zip" UEsDBBQAAAAIAKprGiW7yOjnhQMAAP8HAAALAAAAaGlwZXJkc3AucGyNVVtv2zYUfp4B/4dTx6kl xJNjdS02Ow7cZUGxhyZFvexl3gxZOrKJyKQiUku8IPvtO7zo4jQtJkDiIfmd+0fq6FU8WeZYZMs1 491Ot3MEW0bzROZBntFUr1wUGClMYL0HuIiKTMjgIuJROb+84aiCXME9U1uI080uusUCIC3EDn4T axZJuEbFaFHbORNWniMGqLb/BPH2HAgibzFDJbhz91EkLGXWHxYsDtYso33Si6N1hoJjQG4duEBV FlxOtPx3lJU4rqVQ51NKhMXVx0+rBUrJBJ/apZ8vPztpIeJbVG4iFfnTk27nWPJdvkE1mVz/+ssC ZuABDKyHAczOaTIO3gTvgnHwg37Dn+gb/hiENLwZDLsdeP74xuxu7/VjsduVnKn9sF+IkhLzybzM M6ZgtJyPhtB///nD73+c/kkaCUM4O7tZvP9wCVDyjLKAxgC8fg3OhrFu7cu9vIp2ONTCTa6YFhkn TBrFKId9m4UbQ3Juo3UJK11kz1kdtoKtsreJ4ANT3qmVZbk+0H7UBnUkWyFV2wS5NMnOV9MKwvFB rQRLhn3kZhAF25gFcEXsFyhzwSVSYYilCeMb2YgkmbhoZM5AqfRYaZe5XaXP3EQ37Cvc5cI3Iej6 9m74LRf33BCFuFNok8WS91wEVdkPGPGoMU/Ghn7rsCk75LFIUE+8qquB7uoL+jYIm/qstmEWZRHx xPNdoUjbEpjst/n8/bnIkYMtNbzEu+dPqx3wP+Djd2MbQyoKbzr1AR6tFkvJq6yioLxMJwu8K1Hq 0fbM82xyvu9Xiq2OUjKNiTwpV+syTQ2XLdCrG+4fQBM0FSantSPCVqL/pf7wwJBTlzpWHmPbTUu1 YaYhWEtxvV9pCmV0K7ZcQO/4+njea0wcwV1J3RfaxT1CVCAQNyVLENSWXk3GCptF1D5HNLqcJhNL okQHsMoLTNnDKveaw1FH17iztKYoCa7UnrTo0HsueHNOLY6lXoXFOxi8HYD/6O6EmRvhBMZAKk/d znfP4OGgQocOHX4D/fYbaDgMfPavHC3VCEab6Qsb/Csbfy3lyWj0koY86bc28lJuwZ1/h3J7T4AZ 0acmp7kRrgREXN7Tz8z8y6oLme6ESssO1cmtumF2zV5D1ph+mMQTf0oJm/K4Guv61OUZU99OQd8n DSQ8hIQ1xGak2ws9p95EdrgRVhv2RwmerYFv2/UfUEsDBBQAAAAIAMVrGiWjAcHY1QEAAH8JAAAI AAAAbXJ0Zy5jZme11UFLwzAUB/B7od8hIHhRJ0mGyhARd9lAqWA9iBNN29gFsyakGXN+eteu0WXW NILbDhsv/7w82h/tQqi3jKkBSAeT2XJBk1fGaRkG90WZEk6zx+enwXK2yMIgDPZ6//GpOsVE5VQ/ 6nQKnwbgRVLFqwGq3wlnyWS1cCQV60kO5DzhLL2E6LQHq+9LGNyQ96ulpqXZ3z/ZmHddW48cM82p ScVCEw6GotBKcDCaJ2APhsEtyWkspAmdj+BFPBxBcCMyOgP3mnH2QTQTBTg/Xq2FwcM1zWlhzlnH hkSSlOllGESyyprJcjLP6WGuxEKxfKrD4G4qlP7ZYHW910XYVPeLpJTW6XXFxJAVM6fbGWxnRFHQ tJ7NjvU9Wo39poqcrXbDB7XymbLV36yULX7Qlh/U+PmigtqpIIsK+qaCvKggJxXUTQW1UkF+VJAH FeRHpaPV2G+qyNlqN1Twr08aDVug4C0o1fb+2QYU3A4FW1DwNxTsBQU7oeBuKLgVCvaDgj2gYD8o Ha3GflNFzla7gaKrm/rn19LBH2yhtrTjobVt0UwI8SZIU/2Jsq6UFkwTrnHWG3x0NrscQptEl9LN RrbUZsVHqxV1iLVzTrUeLcf+U0adLT8BUEsDBBQAAAAIAKNrGiWpWD9dhgMAAAEIAAAKAAAAdGNo LXByaS5wbI1VW2/bNhR+rgH/hzPHqSXElWN1DVA7DtxlQdeHJkXc7GXeDFk6sonIpCJSS7wg++07 vMiSs7SoYYmH5HfuH6mDn+LRPMcimy8Zb7farQP4ev7bmy/Xn4I8o5n9w3mBkcIElluA86jIhAzO Ix6V04sbjirIFdwztYY4XW2iWywA0kJs4KtYskjCFSpGi9rOqbDyFDFAtf4niNdnQBB5ixkqwZ27 zyJhKbP+sGBxsGQZ7ZNeHC0zFBwDcuvABaqy4HKk5b+jrMThTgp1RqVEmF1+/rKYoZRM8LFd+uXi 2kkzEd+ichOpyJ+etFuHkm/yFarR6OrTrzOYgAfQsx56MDmjyTB4G5wEw+Bn/YTv6T08CUIa3vb6 7RY8//nGbLu12XrdWGw2JWdq2+8WoqTUfHIg84wpGMyngz50P1x//P2P4z9JJ2EIp6c3sw8fLwBK nlEeUBuA16/B2WjYl1t5GW2wr4WbXDEtMk6YNIpR9rs2DzeG5NzG61JWusyes9pvBFvlb1PBB6a8 YyvLcrmn/agN6kjWQqqmCXJpkp0uxhWE44NaCJb0u8jNIAq2MgvgytgtUOaCS6TCEFMTxleyFkky cdHInIFS6bHSLnO7Sq+pia7fVbjJhW9C0PXt3PBbLu65oQqxp9AmiznvuAiqsu9x4lFjnowN/ezC puyQxyJBPfGqrga6qy/o2yBs6pOdDbMoi4gnnu8KRdqWwmS/yeg3ZyJHDrbU8BLznv8a7YAfgA9P hjaGVBTeeOwDPFotlpJXWUVBeZlOFnhXotSj7Znn2eR8368UGx2lZGoTeVIulmWaGi5boLdruL8H TdBUmJzuHBG2Ev3/6/f3DDl1qWPlMTbdNFRrZhqCNRSX24WmUEb3YsMFdA6vDqed2sQB3JXUfaFd 3CNEBQJxU7IEQa3p0WSssFlE7XNEo+tpNLIkSnQAi7zAlD0scq8+HLvoaneW1hQlwZXakhYdes8F b86pxbHUq7B4B713PfAf3Z0wcSMcwRBI5andevUMHtbw0MHD78DffR/ejHzyrxzM1QAGq/ELG/wb G3/N5dFg8JKGPOo2NvJSrsFdAA7l9p4AM+LPjp3mSrgUEHF5T98z8zmrbmS6FCotO1RHt2qH2TV7 NVtj+mYSUfyxVqhK5Aqta9Tb1Z+adwz6Umlgwn1MWGNMg6HjdG1o+4thFa/9UIJnC+Db4v8HUEsD BBQAAAAIALBrGiWMRNkDiwMAAA4IAAAJAAAAdGNoLXQxLnBsjVVbb9s2FH6uAf+HU8epJcSVY7Up MDsO3GZBt4cmQ53sZd4MWTqyicikIlJLvCD77Tu8yJLTtJgAiYfkd+4fqYPX8WieY5HNl4y3W+3W AVyf//L2ehjkGU3Mil48LzBSmMByC3AeFZmQwXnEo3J6ccNRBbmCe6bWEKerTXSLBUBaiA1ciyWL JFyhYrSo7ZwKK08RA1Trf4J4fQYEkbeYoRLcufsiEpYy6w8LFgdLltE+6cXRMkPBMSC3DlygKgsu R1r+O8pKHO6kUCdQSoTZ5ZffFjOUkgk+tkufLr46aSbiW1RuIhX505N261DyTb5CNRpd/frzDCbg AfSshx5MzmgyDN4FH4Jh8F6/4U/0PQlC+r7r9dsteP74xmq7tdl63VhsNiVnatvvFqKkzHyyL/OM KRjMp4M+dD9+/fz7H8d/kk7CEE5Pb2YfP18AlDyjNKA2AG/egLPh7FsPcisvow32tXCTK6ZFxgmV RjHKftcm4saQ3NuIXc5K19lzdvuNcKsC2GTwgSnv2MqyXO5pP2qDOpK1kKppglyadKeLcQXh+KAW giX9LnIziIKtzAK4QnYLlLngEqk0xNWE8ZWsRZJMXDQyZ6BUeqy0y9yu0mdqout3FW5y4ZsQdIU7 N/yWi3tuuEL0KbTJYs47LoKq8HukeNSYJ2NDv7uwKTvksUhQT7yqr4Hu6wv6Ngib+mRnwyzKIuKJ 57tCkbblMNlvUvrtmciRgy01vMS950+jHfA/4MMPQxtDKgpvPPYBHq0WS8mrrKKgvEwnC7wrUerR 9szzbHK+71eKjY5SMrWJPCkXyzJNDZst0Ns13N+DJmgqTE53jghbif63+v09Q05d6lh5jE03DdWa mYZgDcXldqEplNHF2HABncOrw2mnNnEAdyV1X2gX9whRgUDclCxBUGt6NRkrbBZR+xzR6H4ajSyJ Eh3AIi8wZQ+L3KsPxy662p2lNUVJcKW2pEWH3nPBm3NqcSz1KizeQe+kB/6juxMmboQjGAKpPLVb r57BwxoeOnj4A/jJj+H7sU/+lYO5GsBgNX5hg39n46+5PBoMXtKQR93GRl7KNbgrwKHc3hNgRgza 8dNcCpcCIi7v6Zdm/mjVrUzXQqVlh+rwVg0xu2av5mtMv02iij8GfVvYGrlK6yL1dg2g7h2DvlUa mHAfE+4wJtZXps3QcQbq8J7thNWO/WmCZyvh2z78B1BLAQIUABQAAAAIAKprGiW7yOjnhQMAAP8H AAALAAAAAAAAAAEAIAC2gQAAAABoaXBlcmRzcC5wbFBLAQIUABQAAAAIAMVrGiWjAcHY1QEAAH8J AAAIAAAAAAAAAAEAIAC2ga4DAABtcnRnLmNmZ1BLAQIUABQAAAAIAKNrGiWpWD9dhgMAAAEIAAAK AAAAAAAAAAEAIAC2gakFAAB0Y2gtcHJpLnBsUEsBAhQAFAAAAAgAsGsaJYxE2QOLAwAADggAAAkA AAAAAAAAAQAgALaBVwkAAHRjaC10MS5wbFBLBQYAAAAABAAEAN4AAAAJDQAAAAA= ------=_NextPart_000_0251_01BDED20.82BA3660--

Subject: Re: (usr-tc) dial up message
From: sagarwal@crash.ae.usr.com
Date: 1998-10-01 09:47:58

Brian, Use the command: Set modem_group all message "<Your Message>. From HARM you can viw the message on the interfaces. To change the messages through HARM go to tables---> Modems---->Modem groups---> Select all. Type the message you need in the "Login Message " field. Regards Sanjay Agarwal On Wed, 30 Sep 1998, Brian Biggs wrote: > Hi, > > How does one go about removing the message that is displayed > _before_ the login prompt on HiPerARC via CLI? It seems that v1.1.8 of the > HARC software does not allow you to change this. > > Thanks! > -Brian > -- > # Brian Biggs | Sonic / Sonoma Interconnect # > # Sys Admin / Programmer | v707.522.1000 fax707.547.2199 d707.522.1001 # > # mailto:bb@sonic.net | http://www.sonic.net mailto:support@sonic.net # > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Friggin' V.90
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-10-01 10:34:06

Well, in dual-mode k56 / v.90 modems, the k56 code is usually much better than the v.90 part. Best bet for now is to disable the k56/v.90 part until the code gets better (AT+MS=12 on most rockwells...) iMacs work fine with the 2.100 version of code... It's the same stroy all over again, like X2, the MOTD is "Upgrade, upgrade, upgrade as fast as you can..." :-) Hope this helps, Robert > -----Original Message----- > From: Pete Ashdown [SMTP:pashdown@xmission.com] > Sent: Thursday, October 01, 1998 1:37 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Friggin' V.90 > > We have had zero success with Rockwell v.90's connecting to our HiPer > pool. The same story with the iMacs and anything else that is > upgraded to > v.90 from Flex. I seem to remember a similar discussion on this issue > recently. Was there ever any resolution? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) IDLE/CONNECT time on a TCH
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-01 11:30:48

You can get it via telnet on the NETserver; just use "pmcom" which works with PM2's, PM3's, and NETservers, and parse the output of "show sessions". You can't get it via SNMP on the NETserver. (You can't get much of *anything* via SNMP on the NETserver... and probably never will since code development is stopping/slowing at the end of the year...) You can get about everything *except* idle time via SNMP on the ARC. Idle time isn't there, unless it's been added in ARC code 4.1.78 and I just can't find it. (Yeah, I'm not happy about it either.) Total session time isn't there, but the session *start* time is, and you can calculate total session time pretty easily from that (current time - start time = total session time). You just need to make sure that your clock and your ARC clock is synced up with NTP. (Reading the clock off the ARC is a royal pain; it's far easier to just run NTP. ;-) If you want sample perl code that does this, look for "arcwho" at http://www.dcr.net/~mandrews/usrtoys. Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..." On Wed, 30 Sep 1998, Richard Stuplich wrote: > I have been searching, with snmpwalk, everywhere for the idle and total > connect time for a current call for Total Control racks with HiperARC or > Netserver cards. > > We have far more Lucent/Livingston PM2 and PM3 units and this information > is available in the enterprise mib values for them. > > That USR/3COM doesn't have this data available will result in our decision > to not purchase any more of these units. We use a package to manage modems > and times that requires the availability of idle times and total connect > times. Note: setting call and idle limits at login time is completly > unacceptable when we have a dynamic monitoring tool available. > > It is completely unacceptable that a device marketed as just as good, if > not better, than the other alternatives would lack such a feature. > > Please, someone prove me wrong! Post the MIB var for IDLE or TOTAL CONNECT > TIME for a netserver or hyperarc card in a total control rack or mail me > directly. > > Richard "frustrated with 3com tech support" Stuplich > dick@dwave.net > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Dumb question: PRIs and analog calls
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-01 11:35:11

On Wed, 30 Sep 1998, Mark R. Lindsey wrote: > Thanks for the help. > > Would I be right to guess that v.90 and X2 work on such lines, too. Yup. In theory it should work *better* with PRI than with CT1, because of the extra 8K of bandwidth per channel. (23 channels of 64K instead of 24 channels of 56K (b8zs) or 48K (ami)). We've never actually tried using CT1 here so I can't back that up with personal experience, but I can say that we have people getting 53333 connects with v.90 on our PRI's... [munch] > : >Thus spake Mark R. Lindsey > : >>Can a cht1 card, and the quad modems it talks to, or an HDM, be configured > : >>to terminate a PRI that takes calls both from analog modems and ISDN > : >>users? > : > > : >>Excuse my ignorance, please; I've never worked with ISDN. I've been under > : >>the impression that PRI == ISDN calls only, but our BellSouth salespeople > : >>told us that they can send analog calls down the B channels.

Subject: Re: (usr-tc) Sportster 128K ISDN
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-01 11:39:52

On Wed, 30 Sep 1998, Vito Maselli wrote: > Just make sure that Sync to Async PPP is enabled on the HDM. The SP128K > only supports SyncPPP. It is: andrew% snmpwalk -v 1 fra3-nmc XXXXX .1.3.6.1.4.1.429.1.19.1.1.1.7 enterprises.429.1.19.1.1.1.7.1001 = 1 enterprises.429.1.19.1.1.1.7.1002 = 1 enterprises.429.1.19.1.1.1.7.1003 = 1 enterprises.429.1.19.1.1.1.7.1004 = 1 enterprises.429.1.19.1.1.1.7.1005 = 1 > Does it fail at verifying user name and password? If it does then run a > ppp trace from your NT machine. If it doesn't get that far then use the > protocol monitor that comes with the SP128K and capture the Q.931 messages. It doesn't get to the PAP stage, but it does bring the channel up. I'll see if I can make any sense out of the q.931 messages if I get over there before they buy something like a Bitsurfr Pro... :) Mike Andrews (MA12) icq 6602506 -------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----- http://www.termfrost.org/ "If Barbie is so popular, why do you have to buy her friends?..."

Subject: Re: (usr-tc) RIP updates
From: Charles Hill <chill@ionet.net>
Date: 1998-10-01 12:16:24

Robert, If you don't want all the additional traffic for packets bouncing between your Cisco router and your NAS, just route your 195.15.81, 82, 83, and 84 networks to Null0, and turn off aggregate routing of your IP pools. When the more specific /32 routes are picked up by your Cisco router, they will take preference and when an assigned address is not in use, traffic going to that address gets dropped on the floor. No more ping pong packets clogging your ethernet and a more professional look when tracing routes with a minor expense of a larger routing table. -CH On Thu, 1 Oct 1998, Robert von Bismarck wrote: > Following good advice on this list, I finally implemented RIP on my > TC's. > Now I'm curious about two things : > - can I redistribute the RIP announces from my TC's into my cisco EIGRP > network without being flooded by RIP updates ? > - RIP works fine, but a traceroute from external machines bounces from > my cisco to the ARC and back until max_hops is reached. This does not > impair routed connections, it just doesn't look professional. > > Here's my setup on the ARC : > > HiPer>> set ip network ip routing_protocol ripv2 > HiPer>> set ip network ip rip_policies_update no_ripv1_receive > HiPer>> set ip network ip rip_policies_update no_send_compat > HiPer>> reconfigure ip network ip interface eth:1 > > The ARC's are in the 144.85.80.0 class > > The dial-up pools are : 195.15.81.0/24 > 195.15.82.0/24 > 195.15.83.0/24 > 195.15.84.0/24 > > The cisco has this : > > ! > router rip > version 2 > timers basic 30 30 2 60 300 > passive-interface serial 1/0 > passive-interface serial 1/1 > passive-interface serial 1/2 > passive-interface serial 1/3 > network 144.85.0.0 > network 195.15.81.0 > network 195.15.82.0 > network 195.15.83.0 > network 195.15.84.0 > no auto-summary > ! > ip route 195.15.81.0 255.255.255.0 144.85.80.ARC1-Address > ip route 195.15.82.0 255.255.255.0 144.85.80.ARC2-Address > ip route 195.15.83.0 255.255.255.0 144.85.80.ARC3-Address > ip route 195.15.84.0 255.255.255.0 144.85.80.ARC4-Address > ! > > > Thanks for any pointers, > > Robert > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Friggin' V.90
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-10-01 14:29:58

Just personal experience and the fact that v.90 is a much younger protocol than k56flex... Best v.90 modem I've seen so far is the 3com 56k voice faxmodem (one of the sportsters)... It works like a charm, connecting in the low 50's with throughput rates of 6.7kb/s via FTP... Just my 0.02e worth, Robert > -----Original Message----- > From: Bob Purdon [SMTP:bobp@southcom.com.au] > Sent: Thursday, October 01, 1998 12:15 PM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Friggin' V.90 > > > > Best bet for now is to disable the k56/v.90 part until the code gets > > better (AT+MS=12 on most rockwells...) > > Interesting that you say that K56flex works better than V.90 in most > Rockwell modems. I've been trying a Rockwell based modem here, and > it's > V.90 is rock solid. Never tried K56flex, but I can't imagine the > Rockwell > V.90 I've got here being any better... > > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) RIP updates
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-10-01 15:12:53

Following good advice on this list, I finally implemented RIP on my TC's. Now I'm curious about two things : - can I redistribute the RIP announces from my TC's into my cisco EIGRP network without being flooded by RIP updates ? - RIP works fine, but a traceroute from external machines bounces from my cisco to the ARC and back until max_hops is reached. This does not impair routed connections, it just doesn't look professional. Here's my setup on the ARC : HiPer>> set ip network ip routing_protocol ripv2 HiPer>> set ip network ip rip_policies_update no_ripv1_receive HiPer>> set ip network ip rip_policies_update no_send_compat HiPer>> reconfigure ip network ip interface eth:1 The ARC's are in the 144.85.80.0 class The dial-up pools are : 195.15.81.0/24 195.15.82.0/24 195.15.83.0/24 195.15.84.0/24 The cisco has this : ! router rip version 2 timers basic 30 30 2 60 300 passive-interface serial 1/0 passive-interface serial 1/1 passive-interface serial 1/2 passive-interface serial 1/3 network 144.85.0.0 network 195.15.81.0 network 195.15.82.0 network 195.15.83.0 network 195.15.84.0 no auto-summary ! ip route 195.15.81.0 255.255.255.0 144.85.80.ARC1-Address ip route 195.15.82.0 255.255.255.0 144.85.80.ARC2-Address ip route 195.15.83.0 255.255.255.0 144.85.80.ARC3-Address ip route 195.15.84.0 255.255.255.0 144.85.80.ARC4-Address ! Thanks for any pointers, Robert

Subject: Re: (usr-tc) Friggin' V.90
From: Leon McCalla <ascend@caribbeanlink.com>
Date: 1998-10-01 16:22:43

very strange that 56Kflex modems may slow down when upgraded to v.90. all the USRs i've seen so far seem to go faster once the V.90 code is installed (provided that they work). I've seen a few cases where v.90 being installed drops the modem to 28.8 or no connects as all. Leon -----Original Message----- >Just personal experience and the fact that v.90 is a much younger >protocol than k56flex... >Best v.90 modem I've seen so far is the 3com 56k voice faxmodem (one of >the sportsters)... >It works like a charm, connecting in the low 50's with throughput rates >of 6.7kb/s via FTP... >

Subject: Re: (usr-tc) Dumb question: PRIs and analog calls
From: Mike Hamrich <mhamrich@drfast.net>
Date: 1998-10-01 19:33:09

How do you install the V.90 3.8.1 release. Is there any magic order of cards that should be followed. Also is it OK to go from 2.5.1 to 3.8.1 my predecessor did not keep the chassis to current :) Dave Winston -----Original Message----- >On Wed, 30 Sep 1998, Mark R. Lindsey wrote: > >> Thanks for the help. >> >> Would I be right to guess that v.90 and X2 work on such lines, too. > >Yup. In theory it should work *better* with PRI than with CT1, because of >the extra 8K of bandwidth per channel. (23 channels of 64K instead of 24 >channels of 56K (b8zs) or 48K (ami)). We've never actually tried using >CT1 here so I can't back that up with personal experience, but I can say >that we have people getting 53333 connects with v.90 on our PRI's... > > >[munch] >> : >Thus spake Mark R. Lindsey >> : >>Can a cht1 card, and the quad modems it talks to, or an HDM, be configured >> : >>to terminate a PRI that takes calls both from analog modems and ISDN >> : >>users? >> : > >> : >>Excuse my ignorance, please; I've never worked with ISDN. I've been under >> : >>the impression that PRI == ISDN calls only, but our BellSouth salespeople >> : >>told us that they can send analog calls down the B channels. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Friggin' V.90
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-01 20:15:21

> Best bet for now is to disable the k56/v.90 part until the code gets > better (AT+MS=12 on most rockwells...) Interesting that you say that K56flex works better than V.90 in most Rockwell modems. I've been trying a Rockwell based modem here, and it's V.90 is rock solid. Never tried K56flex, but I can't imagine the Rockwell V.90 I've got here being any better... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: (usr-tc) NAS-Port = 1
From: Alan D. Criado <acriado@elink.net>
Date: 1998-10-02 01:55:42

Perhaps someone here has already run across this and can give me a hand. I've got a 2861 bundle (1 NMC, 1 HiperArc and 2 HiperDsps). Today I upgraded the software versions on all of them: NMC = ver. 5.5.5 HiperArc = ver. 4.1.11 HiperDsps = ver. 1.25 Since doing so, the chassis now reports all connections as coming in on NAS-Port = 1. It used be the first connection was on NAS-Port = 3845 and the next on 3846 and so on. However, now it's assign 1 for every connection made. Does anyone know why this is and how it can be correct to show individual port addresses for each connection? Thank you Alan D. Criado

Subject: Re: (usr-tc) NAS-Port = 1
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-02 07:59:24

Alan D. Criado was heard to say: >Since doing so, the chassis now reports all connections as coming in on >NAS-Port = 1. > >It used be the first connection was on NAS-Port = 3845 and the next on 3846 >and so on. However, now it's assign 1 for every connection made. > >Does anyone know why this is and how it can be correct to show individual >port addresses for each connection? It's a bug. The HARC reports an "Interface-Index" that uniquely ids the port (1000 + 256*<slot> + <channel>). --Ricky

Subject: (usr-tc) NAS-Port = 1
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-10-02 08:10:00

I believe the answer is 4.1.78 of HiPerArc code. Jeff Binkley ASA Network Computing u>Perhaps someone here has already run across this and can give me a u>hand. u>I've got a 2861 bundle (1 NMC, 1 HiperArc and 2 HiperDsps). u>Today I upgraded the software versions on all of them: u>NMC = ver. 5.5.5 u>HiperArc = ver. 4.1.11 u>HiperDsps = ver. 1.25 u>Since doing so, the chassis now reports all connections as coming in u>on NAS-Port = 1. u>It used be the first connection was on NAS-Port = 3845 and the next on u>3846 and so on. However, now it's assign 1 for every connection made. u>Does anyone know why this is and how it can be correct to show u>individual port addresses for each connection? u>Thank you u>Alan D. Criado 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

Subject: Re: (usr-tc) NAS-Port = 1
From: Alan D. Criado <acriado@elink.net>
Date: 1998-10-02 09:33:05

You are correct Jeff. I put 4.1.78 on and it fixed this particular problem. You would think that when I was on the phone with 3Com/USR tech support just yesterday, that they would have told me to use 4.1.78, instead they told me to use 4.1.11. Thanks to all who replied. Alan D. Criado At 08:10 AM 10/2/98 -0500, Jeff Binkley wrote: > > >I believe the answer is 4.1.78 of HiPerArc code. > >Jeff Binkley >ASA Network Computing > > > >u>Perhaps someone here has already run across this and can give me a >u>hand. > >u>I've got a 2861 bundle (1 NMC, 1 HiperArc and 2 HiperDsps). > >u>Today I upgraded the software versions on all of them: > >u>NMC = ver. 5.5.5 >u>HiperArc = ver. 4.1.11 >u>HiperDsps = ver. 1.25 > >u>Since doing so, the chassis now reports all connections as coming in >u>on NAS-Port = 1. > >u>It used be the first connection was on NAS-Port = 3845 and the next on >u>3846 and so on. However, now it's assign 1 for every connection made. > >u>Does anyone know why this is and how it can be correct to show >u>individual port addresses for each connection? > >u>Thank you > >u>Alan D. Criado > > > >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. >

Subject: Re: (usr-tc) NAS-Port = 1
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-02 09:42:35

Thus spake Alan D. Criado >You are correct Jeff. Gak...too many Jeff's. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Modem speed problem
From: Greg Coffey <greg@coffey.com>
Date: 1998-10-02 10:03:14

What firmware versions are installed in the modems? At 05:54 PM 10/2/98 +0200, you wrote: >I've just installed one Netserver 16 with v.34 analogic 33.6kbs >modems. This box replaced an old Access Beyond with 28.8kbs >modems. > >For my surprise, a lot of our customers complained of getting >connection at rates lower than even 28.8kbs (mostly 24000). When >we had the AccessBeyond box they all had a solid 28.800 >connection. > >All my ports are set to a max speed of 115200. If I set this speed >to something lower (57600), is it possible to get better connection >rates ? > >There is something that can be done here ? I've even tried with an >USR V.Everything modem and the best I got was 28.800. Do I >need some software to upgrade my modems or what ? > >I'm running 3.3.0 software version on this Netserver. > >This is a desperate situation. PLEASE HELLLPPP !!!! > > >--------------------------------------------------------------------- > Bogdan Pelinescu <bpelin@itcnet.ro> | > R&D Engineer | Tel: (401) 232 2770 > Institute for Computers | > Networks & Communications Dept. | Fax: (401) 230 7845 > Bucharest, Romania | >--------------------------------------------------------------------- > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > ______________________________________________________ Thanks, Greg Coffey 307-234-5443 Fax 307-234-5446 CoffeyNet v.90 56k Access for Casper & Douglas 142 S. Center St. Casper, WY 82601 http://www.coffey.com

Subject: Re: (usr-tc) Modem speed problem
From: Greg Coffey <greg@coffey.com>
Date: 1998-10-02 10:40:39

Check the firmware version in the modems. We just flashed ours last week. I can't remember how to check the ver but flashing them is a piece of cake. Get the latest firmware off 3Com's site. I don't know what else it could be, we have 6 of these running with no complaints. I just called one with a v.everything and got a 33.6 connect. At 05:54 PM 10/2/98 +0200, you wrote: >I've just installed one Netserver 16 with v.34 analogic 33.6kbs >modems. This box replaced an old Access Beyond with 28.8kbs >modems. > >For my surprise, a lot of our customers complained of getting >connection at rates lower than even 28.8kbs (mostly 24000). When >we had the AccessBeyond box they all had a solid 28.800 >connection. > >All my ports are set to a max speed of 115200. If I set this speed >to something lower (57600), is it possible to get better connection >rates ? > >There is something that can be done here ? I've even tried with an >USR V.Everything modem and the best I got was 28.800. Do I >need some software to upgrade my modems or what ? > >I'm running 3.3.0 software version on this Netserver. > >This is a desperate situation. PLEASE HELLLPPP !!!! > > >--------------------------------------------------------------------- > Bogdan Pelinescu <bpelin@itcnet.ro> | > R&D Engineer | Tel: (401) 232 2770 > Institute for Computers | > Networks & Communications Dept. | Fax: (401) 230 7845 > Bucharest, Romania | >--------------------------------------------------------------------- > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > ______________________________________________________ Thanks, Greg Coffey 307-234-5443 Fax 307-234-5446 CoffeyNet v.90 56k Access for Casper & Douglas 142 S. Center St. Casper, WY 82601 http://www.coffey.com

Subject: (usr-tc) Modem speed problem
From: Bogdan Pelinescu <bpelin@itcnet.ro>
Date: 1998-10-02 17:54:12

I've just installed one Netserver 16 with v.34 analogic 33.6kbs modems. This box replaced an old Access Beyond with 28.8kbs modems. For my surprise, a lot of our customers complained of getting connection at rates lower than even 28.8kbs (mostly 24000). When we had the AccessBeyond box they all had a solid 28.800 connection. All my ports are set to a max speed of 115200. If I set this speed to something lower (57600), is it possible to get better connection rates ? There is something that can be done here ? I've even tried with an USR V.Everything modem and the best I got was 28.800. Do I need some software to upgrade my modems or what ? I'm running 3.3.0 software version on this Netserver. This is a desperate situation. PLEASE HELLLPPP !!!! Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |

Subject: (usr-tc) Modifying defaultroute in radius
From: Brian <signal@shreve.net>
Date: 1998-10-02 19:03:08

Is their any way known to take a certain user, and have all his traffic go to a certain gateway via RADIUS? Here is scenerio: Your users dial into your NAS. The NAS's default route is your router, which is great. But their are some users, whom you would like to be routed to your filter box, so that all porn etc can be removed. Is their a way in radius to modify the users "next hop" as they leave the NAS? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Charles Hill <chill@ionet.net>
Date: 1998-10-02 19:45:03

I don't see why you couldn't give those users a static IP address in a particular subnet and filter for that subnet, but that would mean routing all the traffic through the filter box, because I've never seen a multi-homed NAS in action. -CH On Fri, 2 Oct 1998, Brian wrote: > Is their any way known to take a certain user, and have all his traffic go > to a certain gateway via RADIUS? Here is scenerio: > > Your users dial into your NAS. The NAS's default route is your router, > which is great. But their are some users, whom you would like to be > routed to your filter box, so that all porn etc can be removed. Is their > a way in radius to modify the users "next hop" as they leave the NAS? > > Brian > > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Off-topic (sorta) -- Test equipment
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-02 21:15:22

If you have a recommendation on a manufacturer or model of T1 test equipment, please let me know. I want to be able to analyze the circuit and individual channels on channelized T1s and PRI. Thanks. --- Mark R. Lindsey, mark@datasys.net Voice: 912.241.0607; Fax: 912.241.0190

Subject: Re: (usr-tc) Off-topic (sorta) -- Test equipment
From: William Behrens <wbehrens@feist.com>
Date: 1998-10-02 21:52:10

HP. period. HP2301B Wananalyzer. Without a doubt HP makes the worlds best test equipment. -----Original Message----- >If you have a recommendation on a manufacturer or model of T1 test >equipment, please let me know. I want to be able to analyze the circuit >and individual channels on channelized T1s and PRI. > >Thanks. > > >--- >Mark R. Lindsey, mark@datasys.net >Voice: 912.241.0607; Fax: 912.241.0190 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Brian <signal@shreve.net>
Date: 1998-10-03 01:01:55

On Sat, 3 Oct 1998, Bob Purdon wrote: > > > Your users dial into your NAS. The NAS's default route is your > > router, which is great. But their are some users, whom you would like > > to be routed to your filter box, so that all porn etc can be removed. > > Is their a way in radius to modify the users "next hop" as they leave > > the NAS? > > ...or better still, some users who have not paid whom you wish to redirect > to a web server that serves out a page saying "Give us more money". Set > their default gateway to a Linux box configured similarly to a transparent > proxy... but my question was, can you change the default route in RADIUS, or do you have to rely on route-maps etc at the router level, or layer3/4 switching functions of a switch such as an alteon? > > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Brian <signal@shreve.net>
Date: 1998-10-03 01:03:47

On Fri, 2 Oct 1998, Charles Hill wrote: > > I don't see why you couldn't give those users a static IP address in a > particular subnet and filter for that subnet, but that would mean routing > all the traffic through the filter box, because I've never seen a > multi-homed NAS in action. I could give all the users I want filtered a static IP in a certain subnet, and then make a route-map that takes all of their traffic to the filter box........but I would like to offload this task from the route (no route-maps) and somehow get it to where I can accomplish this somehow with RADIUS or the NAS.....but I am not sure how it is possible if at all. > > -CH > > On Fri, 2 Oct 1998, Brian wrote: > > > Is their any way known to take a certain user, and have all his traffic go > > to a certain gateway via RADIUS? Here is scenerio: > > > > Your users dial into your NAS. The NAS's default route is your router, > > which is great. But their are some users, whom you would like to be > > routed to your filter box, so that all porn etc can be removed. Is their > > a way in radius to modify the users "next hop" as they leave the NAS? > > > > Brian > > > > > > -------------------------------------------------------------------------- > > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: (usr-tc) RE: (USR-TC) OFF-TOPIC (SORTA) -- TEST EQUIPMENT
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-10-03 05:28:00

-> HP. period. HP2301B Wananalyzer. Without a doubt HP makes the worlds best -> test equipment. At the risk of starting a major debate, TTC (Telecommunications Techniques Corp.) is considered the authority on T-1 test sets. Almost all of the RBOC, IEXCs and CLECs use their equipment. HP does make good equipment but they don't own the T-1 space. TTC can be found at: www.ttc.com . Jeff Binkley ASA Network Computing

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-03 07:37:48

Thus spake Brian >I could give all the users I want filtered a static IP in a certain >subnet, and then make a route-map that takes all of their traffic to the >filter box........but I would like to offload this task from the route (no >route-maps) and somehow get it to where I can accomplish this somehow with >RADIUS or the NAS.....but I am not sure how it is possible if at all. On the Netservers, no, absolutely not. On the HARC's (from the documentation I've read, which is already out of date...can't 3Com keep documentation up to date?!) there is no way of doing this either. At least not in the fashion that you have thought about. Let me throw this out as a possibility...haven't explored the full config of this, but this might at least get you looking in a direction that you will find will work...then again, I might be totally off my rocker...you can decide :) PPTP tunnel the users that you want to filter over to a Linux/NT/whatever type of box and do the filtering on that box. I say PPTP because I *know* Netservers have support for it, but just about any tunnel'ing type of setup should work, I think the Netservers only support PPTP, but HARC's seem to support more from what I understand (again, working with limited documentation here). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Modem speed problem
From: Greg Coffey <greg@coffey.com>
Date: 1998-10-03 08:08:26

I meant to check the firmware in the Netserver 16 modems. At 08:46 AM 10/3/98 +0200, you wrote: >> Check the firmware version in the modems. We just flashed ours last week. >> I can't remember how to check the ver but flashing them is a piece of cake. >> Get the latest firmware off 3Com's site. I don't know what else it could >> be, we have 6 of these running with no complaints. I just called one with >> a v.everything and got a 33.6 connect. >> > >This is a sample from one of our modems (btw, the command >seems to be set s1 at "ati7\r" for revision number of modem 1). > >Command> set s2 at "ati7\r" >Command> >Port S2 AT response:ati7 >USRobotics Courier V.Everything Configuration Profile... > >Product type US/Canada Rackmount >Options HST,V32bis,Terbo,VFC,V34+ >Fax Options Class 1/Class 2.0 >Clock Freq 20.16Mhz >Eprom 256k >Ram 32k > >Supervisor date 05/07/96 >DSP date 11/29/95 > >Supervisor rev 1.0.7 >DSP rev 1.2.7 > >Can you check yours and give me a sign ? > >Thanks a lot, >Bogdan > > >--------------------------------------------------------------------- > Bogdan Pelinescu <bpelin@itcnet.ro> | > R&D Engineer | Tel: (401) 232 2770 > Institute for Computers | > Networks & Communications Dept. | Fax: (401) 230 7845 > Bucharest, Romania | >--------------------------------------------------------------------- > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > Thanks, Greg Coffey v.90 56k access in Casper & Douglas CoffeyNet Casper, Douglas, Rawlins, Lusk, Lander, Pinedale 142 S. Center St http://www.coffey.com Casper, WY 82610 Open 8-6 M-F 10-2 Sat 307-234-5443 Til 8PM on Thurs

Subject: Re: (usr-tc) Modem speed problem
From: Bogdan Pelinescu <bpelin@itcnet.ro>
Date: 1998-10-03 08:46:50

> Check the firmware version in the modems. We just flashed ours last week. > I can't remember how to check the ver but flashing them is a piece of cake. > Get the latest firmware off 3Com's site. I don't know what else it could > be, we have 6 of these running with no complaints. I just called one with > a v.everything and got a 33.6 connect. > This is a sample from one of our modems (btw, the command seems to be set s1 at "ati7\r" for revision number of modem 1). Command> set s2 at "ati7\r" Command> Port S2 AT response:ati7 USRobotics Courier V.Everything Configuration Profile... Product type US/Canada Rackmount Options HST,V32bis,Terbo,VFC,V34+ Fax Options Class 1/Class 2.0 Clock Freq 20.16Mhz Eprom 256k Ram 32k Supervisor date 05/07/96 DSP date 11/29/95 Supervisor rev 1.0.7 DSP rev 1.2.7 Can you check yours and give me a sign ? Thanks a lot, Bogdan Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-03 09:59:02

What you are looking for is calle IEA or internet equal exchange. This will allow you to set a default gateway per user. I think this support is still in Alpha/pre Alpha in 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 Sat, 3 Oct 1998, Brian wrote: > On Sat, 3 Oct 1998, Bob Purdon wrote: > > > > > > Your users dial into your NAS. The NAS's default route is your > > > router, which is great. But their are some users, whom you would like > > > to be routed to your filter box, so that all porn etc can be removed. > > > Is their a way in radius to modify the users "next hop" as they leave > > > the NAS? > > > > ...or better still, some users who have not paid whom you wish to redirect > > to a web server that serves out a page saying "Give us more money". Set > > their default gateway to a Linux box configured similarly to a transparent > > proxy... > > but my question was, can you change the default route in RADIUS, or do you > have to rely on route-maps etc at the router level, or layer3/4 switching > functions of a switch such as an alteon? > > > > > > Regards, > > > > Bob Purdon, > > Technical Manager, > > Southern Internet Services. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-03 10:44:51

> Your users dial into your NAS. The NAS's default route is your > router, which is great. But their are some users, whom you would like > to be routed to your filter box, so that all porn etc can be removed. > Is their a way in radius to modify the users "next hop" as they leave > the NAS? ...or better still, some users who have not paid whom you wish to redirect to a web server that serves out a page saying "Give us more money". Set their default gateway to a Linux box configured similarly to a transparent proxy... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-03 11:58:56

Brian was heard to say: >I could give all the users I want filtered a static IP in a certain >subnet, and then make a route-map that takes all of their traffic to the >filter box........but I would like to offload this task from the route (no >route-maps) and somehow get it to where I can accomplish this somehow with >RADIUS or the NAS.....but I am not sure how it is possible if at all. Can you say "L2TP"? I knew that you could. --Ricky

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Brian <signal@shreve.net>
Date: 1998-10-03 12:17:22

On Sat, 3 Oct 1998, Tatai SV Krishnan wrote: > What you are looking for is calle IEA or internet equal exchange. This > will allow you to set a default gateway per user. I think this support > is still in Alpha/pre Alpha in the hiper arc. > > krish well its interesting to know that its in the pipeline. Thanks, and I will anxiously await it! > > ----------------------------------------- > \ 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 Sat, 3 Oct 1998, Brian wrote: > > > On Sat, 3 Oct 1998, Bob Purdon wrote: > > > > > > > > > Your users dial into your NAS. The NAS's default route is your > > > > router, which is great. But their are some users, whom you would like > > > > to be routed to your filter box, so that all porn etc can be removed. > > > > Is their a way in radius to modify the users "next hop" as they leave > > > > the NAS? > > > > > > ...or better still, some users who have not paid whom you wish to redirect > > > to a web server that serves out a page saying "Give us more money". Set > > > their default gateway to a Linux box configured similarly to a transparent > > > proxy... > > > > but my question was, can you change the default route in RADIUS, or do you > > have to rely on route-maps etc at the router level, or layer3/4 switching > > functions of a switch such as an alteon? > > > > > > > > > > Regards, > > > > > > Bob Purdon, > > > Technical Manager, > > > Southern Internet Services. > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider > > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Brian <signal@shreve.net>
Date: 1998-10-03 12:17:22

Subject: (usr-tc) Is RIP broken or am I dumb ???
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-10-03 12:21:33

Here's the situation : We have a PoP with 2 TC's and a connection to the remainder of our network. Our network runs EIGRP internally, as it's very easy to configure and we only use cisco routers. We have to use RIP so the cisco will talk to the HiPer's. Here's the hardware setup : 20 PRI Lines come into 20 HiPerDSP boards 4 ARC's manage 5 DSP's each they are connected to a catalyst 1900 ethernet switch into which come a cisco 3640. IP setup is this : Dial up pools are 4 C classes one for each ARC, (195.15.81.0/24 to 195.15.84.0/24) The ARC's are on the same subnet as the 3640 and the PM2 (144.85.80.0/24 subnetted for each rack and with secondary ip's on the ethernet int of the cisco). One pool is available for dial-up with fixed IP's. This pool is the same for all the ARC's (144.85.89.0/24) The cisco routes one dial-up class to each ARC and the fixed class to all the ARC's. When I do a "show ip route rip" on the cisco, it works fine and I see all the current addresses that are in use When I do a "list ip routes" on an ARC, I see only the local pool, and one RIP pool that's right next to the ARC (same chassis). The other pools are not seen at all. Is this normal or is it a bug ? Furthermore I am routing pools into ISDN routers (like cisco 7xx or Zyxel prestige boxes) and I have trouble tracerouting the addresses inside those routers, even though the connection works fine and the customers are happy... Thanks for any pointers, Robert PS : if anyone has a template configuration for a cisco 7xx router, I'd be glad to have a copy, mine has been done with the ciscoCD and doesn't work if I don't use PAT, which is silly for a routed pool...

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Brian <signal@shreve.net>
Date: 1998-10-03 12:39:28

> > PPTP tunnel the users that you want to filter over to a > Linux/NT/whatever type of box and do the filtering on that box. I say > PPTP because I *know* Netservers have support for it, but just about any > tunnel'ing type of setup should work, I think the Netservers only > support PPTP, but HARC's seem to support more from what I understand > (again, working with limited documentation here). That is an interesting thought. I could do this transparent to the user. I haven't tested any of the tunneling in the ARC, but certainly can give it a try. The filter box is a BSDI machine (X-Stop), and hopefully it supports tunneling with the ARC. It just saves so much cpu to direct them to the right place in the first place, than to snag them at the router and route-map them back to the filter box. > -- > 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-03 13:58:58

Thus spake Brian >> PPTP tunnel the users that you want to filter over to a >> Linux/NT/whatever type of box and do the filtering on that box. I say >> PPTP because I *know* Netservers have support for it, but just about any >> tunnel'ing type of setup should work, I think the Netservers only >> support PPTP, but HARC's seem to support more from what I understand >> (again, working with limited documentation here). >That is an interesting thought. I could do this transparent to the user. >I haven't tested any of the tunneling in the ARC, but certainly can give >it a try. The filter box is a BSDI machine (X-Stop), and hopefully it >supports tunneling with the ARC. The beauty of it is that you only have to set up one tunnel and send multiple users through it...at least as I understand it. Again, I haven't worked with any of this stuff directly, but it *should* work. :) >It just saves so much cpu to direct them to the right place in the first >place, than to snag them at the router and route-map them back to the >filter box. With IOS 11.3, its not so bad to do this...policy routing (at least some conditions of policy routing) are fast-switched in 11.3. Helps a lot. A pptp tunnel is gonna still be better for you though I bet. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Modifying defaultroute in radius
From: Brian <signal@shreve.net>
Date: 1998-10-03 14:45:50

> With IOS 11.3, its not so bad to do this...policy routing (at least some > conditions of policy routing) are fast-switched in 11.3. Helps a lot. > A pptp tunnel is gonna still be better for you though I bet. yes, policy routing is fast switched in 11.3. I have already a route-map in place to redirect port 80 to our squid box, and I would rather not do more route-maps. Also, I would have to allocate a special block of static ip's for the route-map to work off of. With the tunneling, I can use our normal static IP blocks and just add the appropriate RADIUS attributes for a tunnel. 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Modem speed problem
From: Bogdan Pelinescu <bpelin@itcnet.ro>
Date: 1998-10-03 17:34:38

> I meant to check the firmware in the Netserver 16 modems. > Something else besides ati7 ? I don't know how to do it. Anyway, what firmware have you flashed in your modems ? Where did you get it ? (I don't have a support contract with 3Com, so I don't have access to that damned locked files). Thanks, Bogdan Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |

Subject: Re: (usr-tc) Off-topic (sorta) -- Test equipment
From: Jeff Carneal <jeff@apex.net>
Date: 1998-10-03 17:39:41

On Fri, 2 Oct 1998, Mark R. Lindsey wrote: > If you have a recommendation on a manufacturer or model of T1 test > equipment, please let me know. I want to be able to analyze the circuit > and individual channels on channelized T1s and PRI. www.sunrisetelecom.com Their T10 unit can do T1, PRI, SS7, whatever. It's also a lot cheaper and easier to use than the T-Berds. -- Jeff Carneal - Sys Admin - Apex Internet jeff@apex.net http://www.apex.net (502) 442-5363 The opinions expressed above aren't really mine. They belong to someone else who also refuses to take responsibility for them.

Subject: Re: (usr-tc) RE: (USR-TC) OFF-TOPIC (SORTA) -- TEST EQUIPMENT
From: William Behrens <wbehrens@feist.com>
Date: 1998-10-03 19:30:03

Yes T-BERDS are fine pieces of test equipment. Different strokes for different folks :). I was an RF Engineer in a former life and Just sort of used to HP's test equipment. Don't want to start a major debate over this, but I do beleive that the 2301B offers more bang for the buck with its modular design, But thats my personal opinion. <SNIP> > >At the risk of starting a major debate, TTC (Telecommunications Techniques >Corp.) is considered the authority on T-1 test sets. Almost all of the >RBOC, IEXCs and CLECs use their equipment. HP does make good equipment >but they don't own the T-1 space. TTC can be found at: www.ttc.com . > > > Jeff Binkley > ASA Network Computing

Subject: Re: (usr-tc) RE: (USR-TC) OFF-TOPIC (SORTA) -- TEST EQUIPMENT
From: Brian <signal@shreve.net>
Date: 1998-10-03 21:32:40

On Sat, 3 Oct 1998, William Behrens wrote: > Yes T-BERDS are fine pieces of test equipment. Different strokes for > different folks :). I was an RF Engineer in a former life and Just sort of > used to HP's test equipment. Don't want to start a major debate over this, > but I do beleive that the 2301B offers more bang for the buck with its > modular design, But thats my personal opinion. I believe TTC makes a modular one called the Firebird. > > <SNIP> > > > > > >At the risk of starting a major debate, TTC (Telecommunications Techniques > >Corp.) is considered the authority on T-1 test sets. Almost all of the > >RBOC, IEXCs and CLECs use their equipment. HP does make good equipment > >but they don't own the T-1 space. TTC can be found at: www.ttc.com . > > > > > > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: (usr-tc) Only 23 modems used on HDM in round robin call routing?
From: Brian Uechi <brianu@lava.net>
Date: 1998-10-04 23:51:46

I run a program on the syslog output from the a Netserver running in a double up chassis (12 quad modem cards and 2 hdms). The hdms are configured for round robin call routing so all modems should used. I found the 24th modem on each hdm card shows no successful logins. Are calls being routed to the 24th modem but failing to connect or is it really never used. I'm running hdm 1.07 and netserver 3.7.24 and PRI spans. BTW, I still have not found a solution to the UDP latency problem when running the HDM v.90 code in a Netserver based chassis. Thanks, --- Brian K. Uechi Email: brianu@lava.net Technical Support Engineer Phone: 808-545-5282 LavaNet, Inc. FAX : 808-545-7020

Subject: (usr-tc) ISDN problems on 4.1.78?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-10-05 09:56:46

I just upgraded completely to 4.1.78 last night and now some of my ISDN customers can not connect. Any ideas?

Subject: Re: (usr-tc) ISDN problems on 4.1.78?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-05 11:57:04

On Mon, 5 Oct 1998, Pete Ashdown wrote: > I just upgraded completely to 4.1.78 last night and now some of my ISDN > customers can not connect. Any ideas? > I have not heard of any problems in this regard. May be the HDM lost the default config? Are the users if using a terminal able to see the login prompt? I can give you two suggestions. 1. Make sure that you have the DSP modems set to factory default 2. Try changing the init string on the hiper arc set init USR_int command "ats0=0x0" reset the modems and then try a call. Also make sure that the modems are all on the packet bus. 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. >

Subject: Re: (usr-tc) ISDN problems on 4.1.78?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-10-05 12:42:28

Tatai SV Krishnan said once upon a time: >I have not heard of any problems in this regard. May be the HDM lost the >default config? Are the users if using a terminal able to see the login >prompt? > >I can give you two suggestions. > >1. Make sure that you have the DSP modems set to factory default >2. Try changing the init string on the hiper arc > >set init USR_int command "ats0=0x0" > >reset the modems and then try a call. > >Also make sure that the modems are all on the packet bus. I will try your suggestions Krish. In the meantime, take a look at these syslog entries for one such problem user: Oct 5 12:37:42 slc4-tc.xmission.com At 18:37:42, Facility "Auth Facility", Level "COMMON":: Port slot:1/mod:14 successful RADIUS authentication for user: unionpte Oct 5 12:37:43 slc4-tc.xmission.com At 18:37:44, Facility "Auth Facility", Level "COMMON":: The connection for call id 858251, on if slot:1/mod:14 was dropped for user UNKNOWN The connection is established, then immediately disconnected for the same slot/modem. However, the user is now UNKNOWN.

Subject: (usr-tc) Modem speed
From: Bogdan Pelinescu <bpelin@itcnet.ro>
Date: 1998-10-05 13:01:04

I've put 1.0.8 on one modem and there is no change. Connect rates are still below 33.6kbps. Can anyone give me the 1.0.9 code for Netserver modems ? (if it exists) What version from the 3.x Netserver code do you know it's stable ? (maybe 3.2.5.3 ?) Thanks, Bogdan Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |

Subject: Re: (usr-tc) Only 23 modems used on HDM in round robin call
From: K Mitchell <mitch@keyconn.net>
Date: 1998-10-05 13:11:51

At 11:51 PM 10/4/98 -1000, Brian Uechi <brianu@lava.net> wrote: >I run a program on the syslog output from the a Netserver running in >a double up chassis (12 quad modem cards and 2 hdms). The hdms are >configured for round robin call routing so all modems should used. I >found the 24th modem on each hdm card shows no successful logins. Are >calls being routed to the 24th modem but failing to connect or is it >really never used. I'm running hdm 1.07 and netserver 3.7.24 and PRI >spans. The 24th channel of PRI spans is the data bearing channel, so you only have 23 useable channels. If each channel has 'bonded' to a modem, you'll have one that got hung out to dry. I don't think the round-robin call routing would affect this, at it's still only routing 23 channels through what it sees as 23 useable modems. Or, maybe I'm way off base here :) If so, I'm sure somebody will jump in to correct me. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: (usr-tc) NMC dead after failed download
From: Bob Fager <rdfager@cube.ice.net>
Date: 1998-10-05 13:55:47

I have a TC chassis with NetServer, NMC, DualPRI and quadmodems. Today I tried to update the NMC to 5.5.5 using TCM and the download failed. I tried loading the code again using TCM and TFTP without success. I then rebooted the entire chassis. Now the NMC is completely dead. The run/fail light is flashing. I can not ping the NMC or connect to it via serial connection. Obviously, TCM and TFTP still will not work. Any help you can give me in getting this NMC functioning again will be greatly appreciated. TIA, Bob

Subject: (usr-tc) NMC dead after failed download
From: Bob Fager <rdfager@cube.ice.net>
Date: 1998-10-05 13:55:47

Subject: (usr-tc) Can Client over-ride assigned IP Address?
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-10-05 14:13:14

We've just started logging Router errors where someone on the internal Network attempts to send out packets with an address that is not one of our assigned blocks. What I appear to be seeing is Clients that are able to over-ride their Assigned Address. Is this possible? Some of it appears innocent. Windows 98 now gives itself an address of 169.254.x.x if it isn't properly configured or doesn't get a Radius/Netserver response within a certain time. Others appear intentional, as they are RFC1918 Private Network IP's. I also showed a user who managed to get himself the address of .252 when our Pools only go up to .190. I thought when you set the user in Netserver/Radius to assigned Addresses, that was it, and nothing else could get through. Right? Wrong? Steve Kinkaid Steve@flasuncoast.net

Subject: (usr-tc) Can Client over-ride assigned IP Address?
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-10-05 14:13:14

Subject: Re: (usr-tc) ISDN problems on 4.1.78?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-05 14:32:21

On Mon, 5 Oct 1998, Pete Ashdown wrote: > Tatai SV Krishnan said once upon a time: > > >I have not heard of any problems in this regard. May be the HDM lost the > >default config? Are the users if using a terminal able to see the login > >prompt? > > > >I can give you two suggestions. > > > >1. Make sure that you have the DSP modems set to factory default > >2. Try changing the init string on the hiper arc > > > >set init USR_int command "ats0=0x0" > > > >reset the modems and then try a call. > > > >Also make sure that the modems are all on the packet bus. > > I will try your suggestions Krish. In the meantime, take a look at these > syslog entries for one such problem user: > > Oct 5 12:37:42 slc4-tc.xmission.com At 18:37:42, Facility "Auth Facility", Level "COMMON":: Port slot:1/mod:14 successful RADIUS authentication for user: unionpte > Oct 5 12:37:43 slc4-tc.xmission.com At 18:37:44, Facility "Auth Facility", Level "COMMON":: The connection for call id 858251, on if slot:1/mod:14 was dropped for user UNKNOWN > > The connection is established, then immediately disconnected for the same > slot/modem. However, the user is now UNKNOWN. > This basically means that the user was not completely started ppp. You should also get an entry for the user unauthenticated when he connects. Looks like the call came in and the user tried to start ppp and then failed. If you do a ati6 on the interface it will tell you what speed the connection came through an if the user had any problems with errors on the modem side. Clearly I would tend to believe that this isa problem on the hdm setup. restoring to default will fix the problem. 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. >

Subject: Re: (usr-tc) ISDN problems on 4.1.78?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-05 14:32:21

Subject: RE: (usr-tc) NMC dead after failed download
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-05 14:47:09

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Bob Fager |Sent: Monday, October 05, 1998 1:56 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) NMC dead after failed download | | |I have a TC chassis with NetServer, NMC, DualPRI and quadmodems. Today I |tried to update the NMC to 5.5.5 using TCM and the download failed. I |tried loading the code again using TCM and TFTP without success. I then |rebooted the entire chassis. Now the NMC is completely dead. The |run/fail light is flashing. I can not ping the NMC or connect to it via |serial connection. Obviously, TCM and TFTP still will not work. | |Any help you can give me in getting this NMC functioning again will be |greatly appreciated. You need to use the PCSDL.EXE program via console port.

Subject: RE: (usr-tc) Can Client over-ride assigned IP Address?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-05 15:01:30

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Suncoast Networking |USR Mailbox |Sent: Monday, October 05, 1998 2:13 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Can Client over-ride assigned IP Address? | | | We've just started logging Router errors where someone on |the internal Network attempts to send out packets with an |address that is not one of our assigned blocks. What I |appear to be seeing is Clients that are able to over-ride |their Assigned Address. Is this possible? | | Some of it appears innocent. Windows 98 now gives itself an |address of 169.254.x.x if it isn't properly configured or |doesn't get a Radius/Netserver response within a certain time. |Others appear intentional, as they are RFC1918 Private |Network IP's. | | I also showed a user who managed to get himself the address |of .252 when our Pools only go up to .190. I thought when you |set the user in Netserver/Radius to assigned Addresses, that |was it, and nothing else could get through. Right? Wrong? | I savy user can assign his own address. It must be valid and routable on your network or it wont be of any benifit to the user, but it can be done.. The RADIUS stuff and the address passed by IPCP are only suggestions that can be overridden with the right knowledge. This problem can be inhibited with filters that prevent the source address from being anything other than a pool member or the dynamic assignment of a filter on a per user basis. The dynamic assignment is the most thorough approach. Example : 010 permit src-address = 10.10.10.120; #assume 10.10.10.120 is the address assignd to the user. 020 deny; On HARC this would be the input filter assigned to a user dynamically via RADIUS. This requires a RADIUS server that can do this and you must turn on HINT ASSIGNED on the HARC/NETSERVER. -M

Subject: (usr-tc) Resets via CMU/UCD SNMP (NMC, etc)
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-05 15:30:37

I'm attempting to reset an NMC and learn how to reset other cards/ports on a chassis without using TCM. I looked back through the usr-tcm archives and found that it appeared that I should try... (THANKS DAVID!!!! :-) setenv PREFIX .iso.org.dod.internet.private.enterprises.usr.nas snmpset tc5b.i40 rwcomm nmc.nmccmd.nmccmdreqid i 6 snmpset tc5b.i40 rwcomm nmc.nmccmd.nmccmdforce i 1 snmpget tc5b.i40 rwcomm nmc.nmccmd.nmccmdresult The sets happened, however, the card did not reboot. Does anyone have any suggestions on this one? I also tried resetting the slot by using... snmpset tc5b.i40 rwcomm \ chs.uchascmd.uchascmdtable.uchascmdentry.uchascmdfunction.17 i 4 snmpset tc5b.i40 rwcomm \ chs.uchascmd.uchascmdtable.uchascmdentry.uchascmdforce.17 i 1 The uchasCmdResult.17 result I get back is notsupported(4). Imagine that - you can't hardware reset the NMC from TCM either. What's funny is that I got noerror(1) for the CmdCode... Hmmmmmmm...... Obviously, I'm doing something wrong. Unfortunately for me, I'm not finding good information which will help me determine what sequence I need to set things in and whether or not to set the MgtStationId. if I do need to set it, what do I set it to (some 8 byte value, but what)? I did open a ticket on this one, but alas - no response yet. In the end, I'd like to have my own set of web based tools to help us pass on some of the administrative functions to people who do not need to know all the ins and outs of TCM (nor do we want to give it all to them for security reasons). Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: (usr-tc) Resets via CMU/UCD SNMP (NMC, etc)
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-05 15:30:37

Subject: RE: (usr-tc) Can Client over-ride assigned IP Address?
From: Brian <signal@shreve.net>
Date: 1998-10-05 15:53:00

> > I savy user can assign his own address. It must be valid and routable on your > network or it wont be of any benifit to the user, but it can be done.. > > The RADIUS stuff and the address passed by IPCP are only suggestions that can be > overridden with the right knowledge. > > This problem can be inhibited with filters that prevent the source address from > being anything other than a pool member or the dynamic assignment of a filter on > a per user basis. The dynamic assignment is the most thorough approach. > Example : 010 permit src-address = 10.10.10.120; #assume 10.10.10.120 is the > address assignd to the user. > 020 deny; > > On HARC this would be the input filter assigned to a user dynamically via RADIUS. > This requires a RADIUS server that can do this and you must turn on HINT ASSIGNED > on the HARC/NETSERVER. And I might add, using a RADIUS such as Radiator, just makes all of this a breeze. Here is one of 300 dynamic users online right now: HiPer>> show remote user tanis User Name: tanis Service Type: Framed Framed Protocol: PPP Framed IP Address: 208.214.44.61 Framed IP Netmask: 255.255.255.255 Framed Routing: None Framed MTU: 1500 Framed Compression: VJ TCP/IP header Compression Max Channels: 1 Filter Rules : 1 REJECT src-addr!=208.214.44.61 As you can see, he has no choice but to use the address he has been assigned. You say, what about subnets? It handles that too: HiPer>> show remote user signal User Name: signal Service Type: Framed Framed Protocol: PPP Framed IP Address: 208.214.45.1 Framed IP Netmask: 255.255.255.248 Framed Routing: None Framed MTU: 1500 Framed Compression: VJ TCP/IP header Compression Max Channels: 2 Filter Rules : 1 REJECT src-addr!=208.214.45.1/255.255.255.248 I didn't "hard code" any of these filters, they were generated dynamically, on the fly. Brian > > -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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Resets via CMU/UCD SNMP (NMC, etc)
From: David Bolen <db3l@ans.net>
Date: 1998-10-05 16:40:46

Kevin Benton <s1kevin@tims.net> writes: > setenv PREFIX .iso.org.dod.internet.private.enterprises.usr.nas > snmpset tc5b.i40 rwcomm nmc.nmccmd.nmccmdreqid i 6 > snmpset tc5b.i40 rwcomm nmc.nmccmd.nmccmdforce i 1 > snmpget tc5b.i40 rwcomm nmc.nmccmd.nmccmdresult Hmm, you missed the most important object, which is "nmcCmdFunction" - that's what actually makes a request to perform an operation. All command tables in the MIBs are actually nicely consistent. The two primary objects for performing an operation are xxxFunction and xxxForce (assume xxx is the table prefix). Those are really the only two you need to include in a Set (and xxxForce only if you need to make the device do something it wouldn't normally want to do). The xxxMgtStationId is provided to try to help tools recognize a collision in operational requests - e.g., when you make a request include this object to some value to identify the requester. When you query the result, if the value is not what you sent then there must have been another tool doing an overlapping request. The xxxParam object can provide additional parameters for some commands. I don't know of any specific command functions that really make use of this - there are some undocumented ones though :-) The xxxReqId reflects the request id of the last SNMP PDU - I'm not entirely certain why this is read/write, but it's not something you normally need to worry about setting. It can be used in conjunection with xxxMgtStationId to help detect overlapping operations. The xxxResult and xxxCode objects are used to obtain the results of the requested operation, with xxxCode providing more detail on the result when applicable. In this case, setting nmcCmdFunction to the appropriate enumeration (softwareReset - 6) will trigger a reset of the NMC. As to the other objects in that table, you don't need to set nmcCmdReqID - it should assume a value from the underlying request id in the SNMP PDU that is automatically generated. You can set nmcCmdForce if you want (if you think that the request will be refused for some reason that a force can override - like online users on a quad card), but if so, you should set it in the same PDU as the nmcCmdFunction parameter (e.g., do them both in one Set operation). > I also tried resetting the slot by using... > > snmpset tc5b.i40 rwcomm \ > chs.uchascmd.uchascmdtable.uchascmdentry.uchascmdfunction.17 i 4 > snmpset tc5b.i40 rwcomm \ > chs.uchascmd.uchascmdtable.uchascmdentry.uchascmdforce.17 i 1 First, same point as above that if you're going to use force, it's best to include it in the same PDU as the function object. In most cases you don't need to include it, but it can be useful in a modem slot reset since the NMC may reject the request if it thinks the modem still has online users. > The uchasCmdResult.17 result I get back is notsupported(4). Imagine that > - you can't hardware reset the NMC from TCM either. What's funny is that > I got noerror(1) for the CmdCode... Hmmmmmmm...... The CmdCode is only going to have a value if it needs to further qualify the result code (e.g., if the result is a generic "failed" the code will be more detailed). In this case, notsupported is fairly clear :-) In this case, you're running into a special condition - the NMC actually processes the chassis command table, so while you can do slot based resets on all other slots, you can't have the NMC pull it's own reset pin. In such a case, you need to use the nmcCmdFunction as you experimented with above. But the uchasCmdFunction object can be used for all other slots. > Obviously, I'm doing something wrong. Unfortunately for me, I'm not > finding good information which will help me determine what sequence I need > to set things in and whether or not to set the MgtStationId. That object is just a convenience if you want to try to provide command locking between multiple tools (a losing battle, IMO, although at least USR/3Com made an attempt to make it possible). -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) ISDN problems on 4.1.78?
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-10-05 17:01:08

Tatai SV Krishnan said once upon a time: >> >1. Make sure that you have the DSP modems set to factory default >> >2. Try changing the init string on the hiper arc >> > >> >set init USR_int command "ats0=0x0" >> > >> >reset the modems and then try a call. >> > >> >Also make sure that the modems are all on the packet bus. >> >> I will try your suggestions Krish. In the meantime, take a look at these >> syslog entries for one such problem user: >> >> Oct 5 12:37:42 slc4-tc.xmission.com At 18:37:42, Facility "Auth Facility", Level "COMMON":: Port slot:1/mod:14 successful RADIUS authentication for user: unionpte >> Oct 5 12:37:43 slc4-tc.xmission.com At 18:37:44, Facility "Auth Facility", Level "COMMON":: The connection for call id 858251, on if slot:1/mod:14 was dropped for user UNKNOWN >> >> The connection is established, then immediately disconnected for the same >> slot/modem. However, the user is now UNKNOWN. >> > >This basically means that the user was not completely started ppp. You >should also get an entry for the user unauthenticated when he connects. >Looks like the call came in and the user tried to start ppp and then failed. None of your suggestions fixed the problem. >If you do a ati6 on the interface it will tell you what speed the >connection came through an if the user had any problems with errors on >the modem side. Clearly I would tend to believe that this isa problem on >the hdm setup. restoring to default will fix the problem. Nope. Restored to default and reset. Still happens. The "UNKNOWN" error only started happening after I upgraded the code, and only with ISDN. I'm backing out to 4.0.30.

Subject: Re: (usr-tc) Only 23 modems used on HDM in round robin call routing?
From: Brian Uechi <brianu@lava.net>
Date: 1998-10-05 18:01:36

On Mon, 5 Oct 1998, K Mitchell wrote: > At 11:51 PM 10/4/98 -1000, Brian Uechi <brianu@lava.net> wrote: > >I run a program on the syslog output from the a Netserver running in > >a double up chassis (12 quad modem cards and 2 hdms). The hdms are > >configured for round robin call routing so all modems should used. I > >found the 24th modem on each hdm card shows no successful logins. Are > >calls being routed to the 24th modem but failing to connect or is it > >really never used. I'm running hdm 1.07 and netserver 3.7.24 and PRI > >spans. > > The 24th channel of PRI spans is the data bearing channel, so you only > have 23 useable channels. If each channel has 'bonded' to a modem, you'll > have one that got hung out to dry. I don't think the round-robin call > routing would affect this, at it's still only routing 23 channels through > what it sees as 23 useable modems. Or, maybe I'm way off base here :) > If so, I'm sure somebody will jump in to correct me. On a dual PRI, 12 quad card config, all 48 modems are used in roound robin call routing even though only 46 modem can be used simultaneously. I expected the HDMs to work the same way. I guess not.

Subject: (usr-tc) SNMP Reset of nmc and slots (/bin/sh scripts)
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-05 18:25:45

For those who are wondering how I did it (thanks again, David), here are a couple of shell scripts which save me some walking (or driving)... Of course, this script requires a working snmpset command with associated mib library. It has been tested with CMU SNMP and UCD SNMP. Results may vary. Use with caution. Void where prohibited. Employees and their families are not eligible. Get a life. On to the scripts! :) --- /usr/local/bin/reset_nmc 0700 --- #!/bin/sh #set -x out=">/dev/null" export CHASS="$1" export COMM="PUT YOUR READ/WRITE COMMUNITY HERE" export PREFIX=".iso.org.dod.internet.private.enterprises.usr.nas" export MIBFILE="PUT THE LOCATION OF THE APPROPRIATE MIB FILE HERE" # send the reset command snmpset "$CHASS" "$COMM" nmc.nmccmd.nmccmdfunction i 6 $out # if the line below works, something is probably wrong. The nmc should # already be resetting... snmpset "$CHASS" "$COMM" nmc.nmccmd.nmccmdforce i 1 $out --- snip snip snip --- --- /usr/local/bin/reset_tc_slot 0700 --- #!/bin/sh #exec 2>/dev/null out=">/dev/null" export CHASS="$1" export COMM="PUT YOUR READ/WRITE COMMUNITY HERE" export SLOT="$2" export PREFIX=".iso.org.dod.internet.private.enterprises.usr.nas.chs.uchascmd" export PREFIX="$PREFIX.uchascmdtable.uchascmdentry" export MIBFILE="PUT THE LOCATION OF THE APPROPRIATE MIB FILE HERE" # send the reset command snmpset "$CHASS" "$COMM" uchascmdfunction."$SLOT" i 4 $out # if the line below works, something is probably wrong. The slot should # already be resetting... snmpset "$CHASS" "$COMM" uchascmdforce."$SLOT" i 1 $out --- snip snip snip --- Notes: I probably could have made reset_tc_slot a bit smarter by assuming that slot 17 is always an NMC, or at least warning the user that slot 17 is not valid for a hardware reset like that (since it can not successfully hardware reset itself). This script will improve much over time, but I thought a few people could benefit from the remnants of my trials. :) Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: (usr-tc) SNMP stuff
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-05 18:31:40

Hi, I'm just starting to poke at the usr stuff with the ucd-snmp package (3.5.3). Right now, I'm able to get the usr mibs to work by setting an environment variable (MIBS=ALL). I found an older message from David, and he mentioned appending the needed usr things to the "mib.txt" file, but there doesn't seem to be one of those in this release... How are folks doing this? I also have some generic snmp questions. I've moved ds0.txt, nmc.txt, and ds1.txt into my mib directory. I am now able to query many things via snmpwalk, but I'm confused about something. If I query "blah.blah.usr.nas.ds0", I get info. If I query "blah.blah.usr.nas.ds1", I simply get an error, even though both ds0.txt and ds1.txt are in my mibs dir. What am I missing? And when I query something and don't get a "verbal" reply: enterprises.usr.nas.ds0.ds0CmdTable.ds0CmdEntry.ds0CmdDs0Index.1002.17 = 17 enterprises.usr.nas.ds0.ds0CmdTable.ds0CmdEntry.ds0CmdDs0Index.1002.18 = 18 What does that mean? What is 1002.18=18 supposed to tell me? snmp newbie, Charles =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) NMC dead after failed download
From: Brian Uechi <brianu@lava.net>
Date: 1998-10-05 18:44:44

On Mon, 5 Oct 1998, Bob Fager wrote: > I have a TC chassis with NetServer, NMC, DualPRI and quadmodems. Today I > tried to update the NMC to 5.5.5 using TCM and the download failed. I > tried loading the code again using TCM and TFTP without success. I then > rebooted the entire chassis. Now the NMC is completely dead. The > run/fail light is flashing. I can not ping the NMC or connect to it via > serial connection. Obviously, TCM and TFTP still will not work. > > Any help you can give me in getting this NMC functioning again will be > greatly appreciated. If your NMC has only 4MB of DRAM you can't run 5.5.5. You have to run 5.4.1 or 5.4.95. All of our quad modem chassises came with only 4MB of DRAM on the NMC. At this point you have to reload the NMC via its serial port using pcsdl. This can also happen if you configured any NMC interfaces with an IP address of 0.0.0.0. I don't know what the optimal fix this is. I ended up loading older and older version of NMC code via pcsdl until it finally booted then erased the 0.0.0.0 addresses.

Subject: Re: (usr-tc) SNMP stuff
From: David Bolen <db3l@ans.net>
Date: 1998-10-05 18:58:48

Charles Sprickman <spork@inch.com> writes: > he mentioned appending the needed usr things to the "mib.txt" file, but > there doesn't seem to be one of those in this release... How are folks > doing this? The "mibs.txt" I referenced in that message would have been the default mibs.txt in the CMU package (not sure about the UCD package), not the 3Com stuff. It's not really necessary - I was just mentioning you could just append to an existing file if you had one, but if you're just building a file for the 3Com stuff you can just start afresh. In the CMU case, it loads a single mib.txt file by default rather than referencing separate files - UCD may be different than that. > I also have some generic snmp questions. I've moved ds0.txt, nmc.txt, and > ds1.txt into my mib directory. I am now able to query many things via > snmpwalk, but I'm confused about something. If I query > "blah.blah.usr.nas.ds0", I get info. If I query "blah.blah.usr.nas.ds1", > I simply get an error, even though both ds0.txt and ds1.txt are in my mibs > dir. What am I missing? I think you'd have to be more specific about the exact objects being queried, and whether or not you are getting an error from the UCD package (e.g., MIB lookup) or from the NMC (querying an object that isn't valid). > And when I query something and don't get a "verbal" reply: > > enterprises.usr.nas.ds0.ds0CmdTable.ds0CmdEntry.ds0CmdDs0Index.1002.17 = > 17 > enterprises.usr.nas.ds0.ds0CmdTable.ds0CmdEntry.ds0CmdDs0Index.1002.18 = > 18 > > What does that mean? What is 1002.18=18 supposed to tell me? Everything before the "=" is part of the OID of the returned object, generally referred to as the "instance" of the object. In this specific case, ds0CmdTable is a table that is indexed by two objects (ds0CmdDs1Index and ds0CmdDs0Index - check the "INDEX" keyword in the MIB definition for ds0CmdEntry). So when you query that table there are one or more rows (the SEQUENCE of objects making up the Ds0CmdEntry SYNTAX) instantiated in the table, each indexed by a unique pair of values for the index objects. So in your reply above, what you are getting back is the ds0CmdDs0Index object for two rows - one at "1002.17" and one at "1002.18" - the 1002 is the ds0CmdDs1Index (the entity, as USR defines it throughout the system is (1000 * slot) + device), and the 17/18 is the ds0CmdDs0Index (the specific DS0 channel). Of course, in your example what you're actually querying is the ds0CmdDs0Index object, whose purpose is just to act as a table index, so it will always have the same value as the second segment of the instance (17/18 above) since that's its definition. In other words, querying the actual index objects doesn't normally yield that much useful information, unless you want to use the value of the index without having to parse the instance off of the OID. (Actually, the ARC actually marks it's index objects as inaccessible, which annoys me to no end - while I often skip the index objects, in some cases, such as when an object is indexed by the numeric form of an ASCII name, the index object itself is much easier to handle/view). But getting back to your output, the value after the equals sign is the value of the object - in the above example, ds0CmdDs0Index. For other objects, it could be whatever that object represents. For integral objects, the MIB may also define a series of enumerations that represent the various integral values - whether or not the output displays the enumeration in addition to or as a replacement for the integral value is up to the tool you are using. Hope this wasn't too confusing. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: (usr-tc) Tunnels on BSDI
From: Brian <signal@shreve.net>
Date: 1998-10-05 19:46:37

This is kind of off-list content, but its sort of relative if you stretch the mind. I need to tunnel from the ARC into a BSDI box. So I need to know: 1. Is l2tp or pptp supported in BSDI? 2. If so has anyone sucessfully used it with the arc? 3. Any references or tips on how to do this on the BSDI side? Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) NMC dead after failed download
From: Bob Fager <rdfager@cube.ice.net>
Date: 1998-10-06 00:10:48

On Mon, 5 Oct 1998, Brian Uechi wrote: > On Mon, 5 Oct 1998, Bob Fager wrote: > > > I have a TC chassis with NetServer, NMC, DualPRI and quadmodems. Today I > > tried to update the NMC to 5.5.5 using TCM and the download failed. I > > tried loading the code again using TCM and TFTP without success. I then > > rebooted the entire chassis. Now the NMC is completely dead. The > > run/fail light is flashing. I can not ping the NMC or connect to it via > > serial connection. Obviously, TCM and TFTP still will not work. > > > > Any help you can give me in getting this NMC functioning again will be > > greatly appreciated. > > If your NMC has only 4MB of DRAM you can't run 5.5.5. You have to run > 5.4.1 or 5.4.95. All of our quad modem chassises came with only 4MB > of DRAM on the NMC. At this point you have to reload the NMC via its > serial port using pcsdl. > > This can also happen if you configured any NMC interfaces with an IP > address of 0.0.0.0. I don't know what the optimal fix this is. I > ended up loading older and older version of NMC code via pcsdl until > it finally booted then erased the 0.0.0.0 addresses. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 loaded 5.5.5 using pcsdl and it seems to be working well. Thanks for the help. Bob

Subject: Re: (usr-tc) Can Client over-ride assigned IP Address?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-06 08:16:21

Can you get your editor to word wrap sometime *before* the 80th column please? Thanks. Thus spake Andres Kroonmaa > Thankfully, netservers have an option to reject bogus IP's, although not >without > some braindead extras. If user comes in with his IP configured wrong, >netserver > rejects the _call_, dropping it. And if the end system refuses (config-nak's) the IP address that the netserver gives to it, what is the netserver supposed to do? If the end-station insists on its own IP number, the netserver has 2 options, accept it eventually (I would agree this is a problem) or drop the call. PPP negotiation *CANNOT* force a system to take a value that it doesn't want, if the end-station wants a different there's not a whole lot the netserver can do except drop the call. > So, I want to have answers for these questions: > 1) HOW can user override NAS hints? Depends on the software and how the PPP stack is set up to handle specified IP addresses. Some take that as a requested IP adress and try to conf-req that IP address from the other system...if it's nak'ed, they'll accept whatever the other system gives them. Some PPP stacks will absolutely insist on that IP address...if its nak'ed, it'll send the conf-req again with that IP address in it, this can lead to a nak war in ppp one side sends a req, the other side nak's it with a different value and the original side rej's it and sends a new req with the original value. What's the netserver supposed to do? drop the call is the only real answer...and syslog something or something like that so humans can get involved and clear up the misconfig. > 3) How will Harc handle rejection? Namely, would it drop a call or would >it insist on NAS-provided hint? The HARC *CAN'T* insist on NAS-provided hints for the IP address. If the end-station doesn't want to use that IP address, then the HARC can't force it to! This is inherent with PPP. >> This problem can be inhibited with filters that prevent the source address from >> being anything other than a pool member or the dynamic assignment of a filter on >> a per user basis. The dynamic assignment is the most thorough approach. >> Example : 010 permit src-address = 10.10.10.120; #assume 10.10.10.120 is the >> address assignd to the user. >> 020 deny; > This has no use in current context. What you described is basically >anti-spoofing > filter, and as such is a good idea anyway, but if HARC populates bogus route > into its routing tables this will not help at all. User either can't use >the net, > or he can't use the net AND additionally creates DoS for others. Unless the filter is built on the hinted IP address which prevents the harc from passing any packets for the IP address that the end-station eventually gets, if its not the hint'ed IP address, and thus, no DoS (assuming you also prevent it from being propogated in the routing protocol, which is seperately controllable I believe). -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) SNMP stuff
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-06 09:26:17

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Charles Sprickman |Sent: Tuesday, October 06, 1998 8:47 AM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) SNMP stuff | | |On Mon, 5 Oct 1998, David Bolen wrote: | |> The "mibs.txt" I referenced in that message would have been the |> default mibs.txt in the CMU package (not sure about the UCD package), |> not the 3Com stuff. | |Yep, UCD seems to just throw everything in a directory. It seems that to |add more mibs, you have to either recompile the tools or set some |environment variables like "MIBS=ALL". Actually UCD supports dynamic loading.. I just drop all the mib files into a directory and it loads them.. I think the environment VAR is MIBDIR if you use the default that is set at compile time, placing all your mib files there, it should work. (Does for me.)

Subject: RE: (usr-tc) Can Client over-ride assigned IP Address?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-06 09:26:18

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Andres Kroonmaa |Sent: Tuesday, October 06, 1998 2:24 AM |To: usr-tc@lists.xmission.com |Subject: RE: (usr-tc) Can Client over-ride assigned IP Address? | | |> This problem can be inhibited with filters that prevent the source |address from |> being anything other than a pool member or the dynamic assignment of |a filter on |> a per user basis. The dynamic assignment is the most thorough approach. |> Example : 010 permit src-address = 10.10.10.120; #assume 10.10.10.120 is the |> address assignd to the user. |> 020 deny; | | This has no use in current context. What you described is basically |anti-spoofing | filter, and as such is a good idea anyway, but if HARC populates bogus route | into its routing tables this will not help at all. User either can't |use the net, | or he can't use the net AND additionally creates DoS for others. | Using an address other than what is assigned is not spoofing??

Subject: Re: (usr-tc) SNMP stuff
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-06 09:46:36

On Mon, 5 Oct 1998, David Bolen wrote: > The "mibs.txt" I referenced in that message would have been the > default mibs.txt in the CMU package (not sure about the UCD package), > not the 3Com stuff. Yep, UCD seems to just throw everything in a directory. It seems that to add more mibs, you have to either recompile the tools or set some environment variables like "MIBS=ALL". > I think you'd have to be more specific about the exact objects being > queried, and whether or not you are getting an error from the UCD > package (e.g., MIB lookup) or from the NMC (querying an object that > isn't valid). I think my question is even more broad... I know there's a mib file called "ds0.mib", so after I set the prefix to ".iso.org.dod.internet.private.e nterprises.usr.nas" I can use snmpwalk like so: snmpwalk -v 1 host community ds0 and I see all sorts of ds0-level settings. Now I also have a mib called "ds1.mib". I was thinking I could do: snmpwalk -v 1 host community ds1 and I get: sub-identifier not found: ds1 Invalid object identifier: ds1 I'm probably making a wrong assumption about the naming convention I guess. I'd like to look at ds1 level info such as "is the ds1 up?" and whatnot... > But getting back to your output, the value after the equals sign is > the value of the object - in the above example, ds0CmdDs0Index. For > other objects, it could be whatever that object represents. For > integral objects, the MIB may also define a series of enumerations > that represent the various integral values - whether or not the output > displays the enumeration in addition to or as a replacement for the > integral value is up to the tool you are using. Understood, thanks! I've just now started playing with this stuff, and I've had a hell of a time finding a basic FAQ about the structure of the "tree" so to speak, but it's slowly coming together. > > Hope this wasn't too confusing. Not too bad, Charles > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, 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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: RE: (usr-tc) Can Client over-ride assigned IP Address?
From: Andres Kroonmaa <andre@ml.ee>
Date: 1998-10-06 10:23:36

On 5 Oct 98, at 15:01, Mike Wronski <usr-tc@lists.xmission.com> wrote: > |-----Original Message----- > | > | We've just started logging Router errors where someone on > |the internal Network attempts to send out packets with an > |address that is not one of our assigned blocks. What I > |appear to be seeing is Clients that are able to over-ride > |their Assigned Address. Is this possible? > | I also showed a user who managed to get himself the address > |of .252 when our Pools only go up to .190. I thought when you > |set the user in Netserver/Radius to assigned Addresses, that > |was it, and nothing else could get through. Right? Wrong? > | > > I savy user can assign his own address. It must be valid and routable on your > network or it wont be of any benifit to the user, but it can be done.. > > The RADIUS stuff and the address passed by IPCP are only suggestions that can be > overridden with the right knowledge. WHAT?! And Harc would not reject such PPP sequence? Harc would instead accept _user-provided-IP_ and will install a route into its routing tables?! Now imagine that a user sets his IP to be one of your primary DNS servers or Radius server. Yes, he has no benefit from it, but if you run RIP on your backbone, then all of the other customers (at least inside the same NAS) would turn their traffic for given IP to this user port. This is basically HUGE DoS. It has happened to us. Basically whole AS was out of service, cute isn't it? I loved USR/3com for that "feature". Thankfully, netservers have an option to reject bogus IP's, although not without some braindead extras. If user comes in with his IP configured wrong, netserver rejects the _call_, dropping it. Oh boy how stupid. I'm not sure how it is with latest sw, I hoped it was fixed once and forever. And now you say its not?! So, I want to have answers for these questions: 1) HOW can user override NAS hints? 2) How can I block that from happening? 3) How will Harc handle rejection? Namely, would it drop a call or would it insist on NAS-provided hint? > This problem can be inhibited with filters that prevent the source address from > being anything other than a pool member or the dynamic assignment of a filter on > a per user basis. The dynamic assignment is the most thorough approach. > Example : 010 permit src-address = 10.10.10.120; #assume 10.10.10.120 is the > address assignd to the user. > 020 deny; This has no use in current context. What you described is basically anti-spoofing filter, and as such is a good idea anyway, but if HARC populates bogus route into its routing tables this will not help at all. User either can't use the net, or he can't use the net AND additionally creates DoS for others. ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------

Subject: (usr-tc) Re: Same problem!
From: Pete Ashdown <pashdown@xmission.com>
Date: 1998-10-06 11:55:00

I think the problem sources to how 4.1.78 handles the Radius "Framed-IP-Address" when a connection is bonded. I think it is either ignoring it, not using it on the second channel, or not passing it properly over PPP. Bonded connections without static addresses worked just fine. In any case, I'm back on 4.0.30 :-(. Lamar Townsend said once upon a time: > >Pete, > > I'm having the exact same problem here, except here it is happening on >dialup and ISDN users. I switched back to 4.0.30 (from 4.1.78) tonight >and I'm waiting to see what happens today. If you find out what the deal >is would you please shoot me an email and let me know. I have been >fighting this for a few days. > >Lamar Townsend >Microgear Computers & Microgear.Net >lamar@microgear.net > > >> I will try your suggestions Krish. In the meantime, take a look at these >> syslog entries for one such problem user: >> Oct 5 12:37:42 slc4-tc.xmission.com At 18:37:42, Facility "Auth >Facility", Level "COMMON":: Port slot:1/mod:14 > successful RADIUS >authentication for user: unionpte >> Oct 5 12:37:43 slc4-tc.xmission.com At 18:37:44, Facility "Auth >Facility", Level "COMMON":: The connection for > call id 858251, on if >slot:1/mod:14 was dropped for user UNKNOWN >> The connection is established, then immediately disconnected for the same >> slot/modem. However, the user is now UNKNOWN. > >

Subject: Re: (usr-tc) Can Client over-ride assigned IP Address?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-06 12:21:54

Jeff Mcadams was heard to say: >And if the end system refuses (config-nak's) the IP address that the >netserver gives to it, what is the netserver supposed to do? If the >end-station insists on its own IP number, the netserver has 2 options, >accept it eventually (I would agree this is a problem) or drop the call. >PPP negotiation *CANNOT* force a system to take a value that it doesn't >want, if the end-station wants a different there's not a whole lot the >netserver can do except drop the call. Having had this discussion with Cisco, here's what IOS 11.3.5T does. If I setup my linux box to use 199.72.3.150 and the RADIUS settings for that user are for the address 199.72.3.15, then the two systems will "argue" about the address for over a minute and then give up. The Cisco installs a route to the RADIUS assigned address and goes on about its business. If my IP address is wrong (so sayeth RADIUS) then I'm not going to be able to get anywhere. A trace of the interface will very quickly show me using the wrong address. (FWIW, it took a few weeks to get the AS5300 to behave in this situation and it only behaves for analog calls so far. ISDN calls get dropped on the floor due to a slight bug in the attribute processing.) >> 3) How will Harc handle rejection? Namely, would it drop a call or would >>it insist on NAS-provided hint? > >The HARC *CAN'T* insist on NAS-provided hints for the IP address. If >the end-station doesn't want to use that IP address, then the HARC can't >force it to! This is inherent with PPP. No, but it can flag a "lan security violation" -- to use an Ascend term. Either drop the @#$@ call or install the RADIUS assigned route and go about your business. --Ricky

Subject: (usr-tc) PROXY Filtering
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-06 12:23:04

We are looking for a way to filter traffic on a per-user basis. We'd like to be able to send all outbound port 80 traffic to a web proxy server. We want to let all other traffic flow normally. How do I configure filters to redirect outbound traffic? Many of our cities are small enough that using a web proxy server will save us buying another T1 to feed it, but we'd like to have some users go to one filter, and other users hit a different filter. We do not want to proxy certain protocols because the server software is unreliable for those protocols. We'd like to do this on both NetServers and HiPer ARC's. (as submitted on case tracker system) Anyone have any ideas on how we can accomplish this? Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) PROXY Filtering
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-06 12:26:23

Thus spake Kevin Benton >We are looking for a way to filter traffic on a >per-user basis. We'd like to be able to send all >outbound port 80 traffic to a web proxy server. We >want to let all other traffic flow normally. How do >I configure filters to redirect outbound traffic? >Many of our cities are small enough that using a web >proxy server will save us buying another T1 to feed >it, but we'd like to have some users go to one filter, >and other users hit a different filter. We do not >want to proxy certain protocols because the server >software is unreliable for those protocols. >We'd like to do this on both NetServers and HiPer >ARC's. >(as submitted on case tracker system) >Anyone have any ideas on how we can accomplish this? Either route-maps on a cisco, or a pptp tunnel from the netserver, similar for the HARC, but don't know specifics on the HARC's. Check the archives from a day or two ago, this was discussed there. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Re: (TCS35Beta) HiperARC / Netserver Conversion Utility
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-06 12:43:39

On Tue, 6 Oct 1998, Ricky Beam wrote: > Dominic Ciresi was heard to say: > > 1.Extractor: Extract the NetServer configuration from a series of show > >screens. The configuration > > will be stored in a binary file on the application client machine. > > Can I make a suggestion... use the binary config file ala the Netserver > manager. You cannot see every configuration item with 'show'. For example, > what's the show command to see if ripv2 is on or off? (in two years, I've > never found that one.) > On the NETServer: show net0 sh net0 Ethernet Status: IP - Enabled IPX - Disabled Interface Addr: ip.207.24.79.204.ae.usr.com (207.24.79.204) Netmask: 255.255.255.0 Broadcast Address: 207.24.79.255 IPX Network: 00000000 IPX Frame Type: ETHERNET_802.2 Ethernet Address: 00:c0:49:02:f1:02 Routing: Broadcast, Listen (On), RIP V2 Input Filter: Output Filter: On the HiPer arc: show ip net <network name > SHOW IP NETWORK ip1 SETTINGS: Interface: eth:1 Network Address: 207.24.79.202/C Frame Type: ETHERNET_II Status: ENABLED Reconfigure Needed: FALSE Mask: 255.255.255.0 Station: 207.24.79.202 Broadcast Algorithm: IETF Max Reassembly Size: 3464 IP Routing Protocol: RIPV2 IP Routing Metric: 1 RIP Interface Export Metric: 0 IP RIP Routing Policies: SEND_ROUTES SPLIT_HORIZON POISON_REVERSE FLASH_UPDATE SEND_COMPAT RIPV1_RECEIVE RIPV2_RECEIVE > > 2.Translator: Derive a set of HiPer ARC CLI configuration commands from > >the extracted > > NetServer configuration. The mapping between the NetServer > >configuration parameters and the > > HiPer ARC CLI command set > > Umm, second suggestion... why not generate a "bulk configuration file"? > > >The ArcSwitcher gets the configuration data from the NETServer by > >establishing a telnet session to > >the card (using the !root user) and issuing a series of CLI show commands > > Can I ask why you're not using the 'management' interface (the thing the > netserver manager uses.) > The Netserver manager uses a tcp port. This uses snmp. krish > >The intent of the ArcSwitcher is that we automate transition between the > >NETServer and HiPer ARC > >as much as possible, while at the same time pointing out areas which cannot > > be converted or handled > >automatically. > > It's a good thing in the general sense, but installing HARC's all over one's > network without understanding the creature is a very bad idea. The translator > would be a good starting point to getting a base configuration. However, > it's going to leave more things unconfigured than it will translate from > the netserver. (esp. with 4.1) > > If most people are like me, they have a script file of the netserver CLI > commands that configured the netserver in the first place. Translating that > might be of value. FWIW, I've already taken my netserver configuration > generator and converted it's CLI input (line by line) to HARC 4.1 CLI > lines -- adding and removing here and there. It took me a few hours. > (I've been playing with that HARC for over a month, tho') > > I don't want to be the voice of oposition, but I have a feeling lots of > people are going to shoot themselves in the foot using this thing without > understanding the hiper ARC. HARC is very different from the netserver. > Read the 500 page pdf document. > > --Ricky >

Subject: (usr-tc) Re: (TCS35Beta) HiperARC / Netserver Conversion Utility
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-06 12:43:39

Subject: Re: (usr-tc) v.35 cables for NETServer
From: Curt Shambeau <curt@execpc.com>
Date: 1998-10-06 13:01:35

> What type of cable do the v.35 ports on the back of the NETServers use? > Will a standard v.35 cable work, or a Cisco v.35 cable work, or does it have > to be some USR/3COM specific cable? We are wanting to use these as > temporary T-1 links while we are waiting for our new T-1 ports to come in. The USR/3COM v.35 cables are interchangable with the Cisco ones. Either works fine. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Subject: (usr-tc) Re: (TCS35Beta) HiperARC / Netserver Conversion Utility
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-06 13:03:34

Dominic Ciresi was heard to say: > 1.Extractor: Extract the NetServer configuration from a series of show >screens. The configuration > will be stored in a binary file on the application client machine. Can I make a suggestion... use the binary config file ala the Netserver manager. You cannot see every configuration item with 'show'. For example, what's the show command to see if ripv2 is on or off? (in two years, I've never found that one.) > 2.Translator: Derive a set of HiPer ARC CLI configuration commands from >the extracted > NetServer configuration. The mapping between the NetServer >configuration parameters and the > HiPer ARC CLI command set Umm, second suggestion... why not generate a "bulk configuration file"? >The ArcSwitcher gets the configuration data from the NETServer by >establishing a telnet session to >the card (using the !root user) and issuing a series of CLI show commands Can I ask why you're not using the 'management' interface (the thing the netserver manager uses.) >The intent of the ArcSwitcher is that we automate transition between the >NETServer and HiPer ARC >as much as possible, while at the same time pointing out areas which cannot > be converted or handled >automatically. It's a good thing in the general sense, but installing HARC's all over one's network without understanding the creature is a very bad idea. The translator would be a good starting point to getting a base configuration. However, it's going to leave more things unconfigured than it will translate from the netserver. (esp. with 4.1) If most people are like me, they have a script file of the netserver CLI commands that configured the netserver in the first place. Translating that might be of value. FWIW, I've already taken my netserver configuration generator and converted it's CLI input (line by line) to HARC 4.1 CLI lines -- adding and removing here and there. It took me a few hours. (I've been playing with that HARC for over a month, tho') I don't want to be the voice of oposition, but I have a feeling lots of people are going to shoot themselves in the foot using this thing without understanding the hiper ARC. HARC is very different from the netserver. Read the 500 page pdf document. --Ricky

Subject: Re: (usr-tc) v.35 cables for NETServer
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-06 13:10:54

On Tue, 6 Oct 1998, Peter D. Mayer wrote: > What type of cable do the v.35 ports on the back of the NETServers use? > Will a standard v.35 cable work, or a Cisco v.35 cable work, or does it have > to be some USR/3COM specific cable? We are wanting to use these as > temporary T-1 links while we are waiting for our new T-1 ports to come in. > > Thanks, You can use the Cisco cable - the pin out is the same. The DTE cable is the one that you want to use. krish > > 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. >

Subject: (usr-tc) v.35 cables for NETServer
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-06 13:40:10

What type of cable do the v.35 ports on the back of the NETServers use? Will a standard v.35 cable work, or a Cisco v.35 cable work, or does it have to be some USR/3COM specific cable? We are wanting to use these as temporary T-1 links while we are waiting for our new T-1 ports to come in. Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Subject: (usr-tc) v.35 cables for NETServer
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-06 13:40:10

Subject: Re: (usr-tc) Hyper card dial in problems
From: Jack Singer <jsinger@usacars.com>
Date: 1998-10-06 14:00:14

We just upgraded from the quad total control to the hyper bundle. While most people can connect fine, there are a number of people that used to connect fine that are having problems connecting or being disconnected shortly after connection. Is the hyper system more sensitive to line conditions or something? Jack Singer

Subject: (usr-tc) Re: (TCS35Beta) HiperARC / Netserver Conversion Utility
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-06 14:11:47

On Tue, 6 Oct 1998, Ricky Beam wrote: > [distribution list cut back to just usr-tc. change it if you want.] > > Tatai SV Krishnan was heard to say: > >On Tue, 6 Oct 1998, Ricky Beam wrote: > >> manager. You cannot see every configuration item with 'show'. For example, > >> what's the show command to see if ripv2 is on or off? (in two years, I've > >> never found that one.) > [...] > >show net0 > [...] > > Routing: Broadcast, Listen (On), RIP V2 > > I knew were gonna say that... 'set net0 routing off' now tell me if ripv2 > is on or off. 'set ripv2 on' is a global setting. If RADIUS does not > reset it per connection, then that is what will be used. And until someone > dials up, you cannot see it. (That's just one of several things that show > will not show you. I don't remember what the others are off hand -- it's > been a year since I cared about 'show'.) > Good - now if you set net0 routing off - you have just said no routing what so ever. Now if you are not going to do routing why know what type of protocol you are going to use? even if you want to know why display if the protocol is not being used. Now the other thing about radius - you are talking about is not clear to me. What does radius has to do with routing? Could you be clear on this? thanks krish > >On the HiPer arc: > > HARC is irrelevant for the sake of this discussion... > > >> Can I ask why you're not using the 'management' interface (the thing the > >> netserver manager uses.) > >> > >The Netserver manager uses a tcp port. This uses snmp. > > Yes, port 1621 (or something)... it's some proprietary interface format. > I was not aware that the Netserver did anything but standard MIB-II. And > the notice said it was using the '!root' telnet interface. (Yes, the > HARC is completely SNMP manageable sans setting the management bit on > users.) > > --Ricky >

Subject: Re: (usr-tc) Can Client over-ride assigned IP Address?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-06 14:42:37

Thus spake Andres Kroonmaa > Right, _if_ the remote system rejects the hint and the ping-pong goes > endless. But not _right_ after NAS sends its first reject, ok? True...that would definitely be bad form...I've never seen the netserver do this, but I haven't seen it not do it either... > Its ok with me to drop a call for the persistent abuser, but its not > ok to drop a call for looser who happened to put an ip address into > his dialup networking config and is having problems only with USR/3com, > not with cisco, not with ascend, not with lucent, because they all > politely reject the remote hint and try to assign remote user an ip > address, until remote end ack's, drops the call himself or timeouts. > Its not so unusal that some PPP stacks would "deal" with NAS for some > time and eventually give up, kind of "ok, if you insist. I just thought > that maybe..." Yeah...I can follow that. > I understand what you are talking about. This is what is called PPP > negotiation. If remote end is allowed to negotiate for its IP address, > then yes, remote user is allowed to override NAS hints. > But if NAS is set to assign an IP to a remote user, how can remote > user override it? There's no concept in PPP of an "assigned" address....addresses are *always* negotiated. Now, one side may be *extremely* yielding in that negotatiation "I don't know what IP address you have, anything you pick will be fine with me" (to anthropomorphize a bit :) >This is what the question was about. > I got an impression (from the initial mail I replied to) that it is > possible somehow with 3com NAS. You can't judge me hard for being > worried, I've seen things much worse than that with TC. Oh, I'll agree on that...I've seen some really scary stuff from TC's. :) > could you give some examples? is win95 DUN such an insisting stack? Or > is it more of a requesting type? I don't know how win95 deals with it. > What I meant is 2 differing cases: > (user comes in with his hint on its remote IP address) > 1) NAS rejects the remote hint and provides its own hint instead, wait... > or, > 2) NAS rejects the remote hint and drops the call right away. Yes, I agree, rejecting the remote req and dropping the call would be broken IMHO. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Can Client over-ride assigned IP Address?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-06 14:42:37

Subject: (usr-tc) Re: (TCS35Beta) HiperARC / Netserver Conversion Utility
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-06 14:53:37

[distribution list cut back to just usr-tc. change it if you want.] Tatai SV Krishnan was heard to say: >On Tue, 6 Oct 1998, Ricky Beam wrote: >> manager. You cannot see every configuration item with 'show'. For example, >> what's the show command to see if ripv2 is on or off? (in two years, I've >> never found that one.) [...] >show net0 [...] > Routing: Broadcast, Listen (On), RIP V2 I knew were gonna say that... 'set net0 routing off' now tell me if ripv2 is on or off. 'set ripv2 on' is a global setting. If RADIUS does not reset it per connection, then that is what will be used. And until someone dials up, you cannot see it. (That's just one of several things that show will not show you. I don't remember what the others are off hand -- it's been a year since I cared about 'show'.) >On the HiPer arc: HARC is irrelevant for the sake of this discussion... >> Can I ask why you're not using the 'management' interface (the thing the >> netserver manager uses.) >> >The Netserver manager uses a tcp port. This uses snmp. Yes, port 1621 (or something)... it's some proprietary interface format. I was not aware that the Netserver did anything but standard MIB-II. And the notice said it was using the '!root' telnet interface. (Yes, the HARC is completely SNMP manageable sans setting the management bit on users.) --Ricky

Subject: Re: (usr-tc) SNMP stuff
From: David Bolen <db3l@ans.net>
Date: 1998-10-06 17:42:50

Charles Sprickman <spork@inch.com> writes: > and I see all sorts of ds0-level settings. Now I also have a mib called > "ds1.mib". I was thinking I could do: > > snmpwalk -v 1 host community ds1 > > and I get: > > sub-identifier not found: ds1 > Invalid object identifier: ds1 > > I'm probably making a wrong assumption about the naming convention I > guess. I'd like to look at ds1 level info such as "is the ds1 up?" and > whatnot... Yes, your problem is that the actual MIB tree defined in the ds1.mib file is not part of the USR enterprise specific trees, but rather the original experimental (rooted beneath iso.org.dod.internet.experimental) DS1 statistics tree (RFC1232). Thus, since you have your prefix set to the USR enterprise specific tree for the TC, the SNMP library can't find the object you were referencing. It's also a good idea in general not to necessarily assume that the name of the file containing the MIB definition is also an object in that MIB, but rather check out the contents itself. In terms of DS1 stats, the older experimental tree in ds1.mib applies to the dual-span T1/PRI cards. However, for HDM cards you want to use the newer tree in the transmission tree (iso.org.dod.internet.mgmt.mib-2.transmission), which is defined in rfc1406.mib. Both trees are rooted in an object named "ds1" but reside in different parts of the overall MIB hierarchy. The RFC1406 MIB objects all beyond the root all use a "ds1x" prefix to distinguish them unambiguously from the leaf objects in the older RFC1232 mib. In both cases (RFC1232 and RFC1406), there is a config table with general span information and then several tables for holding interval statistics. USR/3Com also provides enterprise specific information (for both the dual-T1/PRI and HDM) for DS1 span level information. This can be found in the uds1 tree (uds1.mib, leaf objects prefixed with "uds1") for dual-T1/PRI cards, and rds1 tree (rds1.mib, leaf objects prefixed with "usrds1") for HDM cards. These trees have extra configuration information, trap/command tables, and in the uds1 case addition interval tables to augment the information in the experimental DS1 interval tables. > Understood, thanks! I've just now started playing with this stuff, and > I've had a hell of a time finding a basic FAQ about the structure of the > "tree" so to speak, but it's slowly coming together. If you haven't already, you might want to obtain a copy of "The Simple Book" by Marshall Rose. Some of it is probably more than necessary (e.g., the underlying SNMP PDU and BER encoding rules and stuff) but it also covers a lot about the ASN.1 notation and general MIB trees and what not. I would also suggest reading the relevant SNMP RFCs, particularly RFC1902 covering the SMI (structure of management information) used in writing MIBs which will make it easier to make use of them. Officially, the TC only uses SNMPv1 (so the SMI is more properly RFC1155), but you'll probably run into just as many MIBs conforming to the SNMPv2 SMI (RFC1902) and it won't really affect the ability to read SNMPv1 MIBs - unless you're trying to write a parser/compiler and need to care :-) There should also be a note from me somewhere in the list archives that helps break down the MIB files supplied by 3Com against the various components, showing which file/tree applies to which component. Also, there should be an SNMP MIB reference manual along with the various NMC documentation (<= NMC 3.0) or information on the tables integrated with the individual parameter references in the NMC 5.x programmers guide. For the most part, I actually find reading the MIBs easier than the programmers guide (which is nothing more than a dump of the MIB) for the individual parameters, but the guide does also have some summary sections such as on LED handling and what not that can be good additional information. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: (usr-tc) Accounting and Radius problem...
From: Dragan D. Vecerina <vexi@yubc.net>
Date: 1998-10-06 18:11:44

Hi, Is there any workaround or suggestions for loss of accounting records from HiperArc Card (4.1.11). Problem is that it doesn't send (sometimes) ACCT OFF information to radius server when user disconnect. Is this bug only in 4.1.11, because if it is, maybe downgrade to 4.0.30 will solve this f*** problem? Is there anyone who have the same problem? This is very poor for ISP's and it drives me mad because i have so much information in base that users are online and thay are NOT! Dragan D. Vecerina System Admin YUBC System

Subject: (usr-tc) Accounting and Radius problem...
From: Dragan D. Vecerina <vexi@yubc.net>
Date: 1998-10-06 18:11:44

Subject: Re: (usr-tc) PROXY Filtering
From: Brian <signal@shreve.net>
Date: 1998-10-06 20:10:00

On Tue, 6 Oct 1998, Kevin Benton wrote: > We are looking for a way to filter traffic on a > per-user basis. We'd like to be able to send all > outbound port 80 traffic to a web proxy server. We > want to let all other traffic flow normally. How do > I configure filters to redirect outbound traffic? You don't. The only thing you can do now to influence where outbound is going (other than the defaultroute), is to use a tunnel protocol on the arc, and set that up in radius attributes. That's not per port tunneling however, its going to tunnel the entire connection. To do what you want, you need to setup a route-map on your cisco router, or use a layer3/4 switch. > > Many of our cities are small enough that using a web > proxy server will save us buying another T1 to feed > it, but we'd like to have some users go to one filter, > and other users hit a different filter. We do not > want to proxy certain protocols because the server > software is unreliable for those protocols. Then don't direct the protocols to the proxy. If you only want to proxy web, make a route-map that redirects port 80 traffic to your web cache. Anything else will just pass thru. I don't recommend this on anything less than a 4700/36xx router. > > We'd like to do this on both NetServers and HiPer > ARC's. well its going to have to be at the router level. > > (as submitted on case tracker system) > > Anyone have any ideas on how we can accomplish this? here is my "howto", which still applies to Squid2 but has to be re-done a bit: How to do Transparent Proxying using Linux and Cisco <signal@shreve.net> Here is how I have Transparent proxying working for me, in an enviroment where my router is a Cisco 2501 running IOS 11.1, and Squid machine is running Linux 2.0.33. Many thanks to the following individules and the squid-users list for helping me get redirection and transparent proxying working on my Cisco/Linux box. Lincoln Dale Riccardo Vratogna Mark White Henrik Nordstrom First, here is what I added to my Cisco, which is running IOS 11.1. In IOS 11.1 the route-map command is "process switched" as opposed to the faster "fast-switched" route-map which is found in IOS 11.2 and later. You may wish to be running IOS 11.2. I am running 11.1, and have had no problems with my current load of about 150 simultaneous connections to squid.: ! interface Ethernet0 description To Office Ethernet ip address 208.206.76.1 255.255.255.0 no ip directed-broadcast no ip mroute-cache ip policy route-map proxy-redir ! access-list 110 deny tcp host 208.206.76.44 any eq www access-list 110 permit tcp any any eq www route-map proxy-redir permit 10 match ip address 110 set ip next-hop 208.206.76.44 So basically from above you can see I added the "route-map" declaration, and an access-list, and then turned the route-map on under int e0 "ip policy route-map proxy-redir" ok, so the Cisco is taken care of at this point. The host above: 208.206.76.44, is the ip number of my squid host. My squid box runs Linux, so I had to do the following on it: my kernel (2.0.33) config looks like this: # # Networking options # CONFIG_FIREWALL=y # CONFIG_NET_ALIAS is not set CONFIG_INET=y CONFIG_IP_FORWARD=y CONFIG_IP_MULTICAST=y CONFIG_SYN_COOKIES=y # CONFIG_RST_COOKIES is not set CONFIG_IP_FIREWALL=y # CONFIG_IP_FIREWALL_VERBOSE is not set CONFIG_IP_MASQUERADE=y # CONFIG_IP_MASQUERADE_IPAUTOFW is not set CONFIG_IP_MASQUERADE_ICMP=y CONFIG_IP_TRANSPARENT_PROXY=y CONFIG_IP_ALWAYS_DEFRAG=y # CONFIG_IP_ACCT is not set CONFIG_IP_ROUTER=y You will need Firewalling and Transparent Proxy turned on at a minimum. Then some ipfwadm stuff: # Accept all on loopback ipfwadm -I -a accept -W lo # Accept my own IP, to prevent loops (repeat for each interface/alias) ipfwadm -I -a accept -P tcp -D 208.206.76.44 80 # Send all traffic destinated to port 80 to Squid on port 3128 ipfwadm -I -a accept -P tcp -D 0/0 80 -r 3128 it accepts packets on port 80 (redirected from the Cisco), and redirects them to 3128 which is the port my squid process is sitting on. I put all this in /etc/rc.d/rc.local and the squid is configured as: http_port 3128 icp_port 3130 httpd_accel virtual 80 httpd_accel_with_proxy on I am using v1.1.20 of the squid with the patch at: http://hem.passagen.se/hno/squid/squid-1.1.20.host_and_virtual.patch installed. You will want to install this patch if using a setup similar to mine. This works great. Many thanks again to all of those listed above in helping me. Brian /-------------------------- signal@shreve.net -----------------------------\ | Brian Feeny | USR TC Hubs | ShreveNet Inc. (318)222-2638 | | Network Administrator | Perl, Linux | Web hosting, online stores, | | ShreveNet Inc. | USR Pilot | Dial-Up 14.4-56k, ISDN & LANs | | 89 CRX DX w/MPFI, lots of |-=*:Quake:*=-| http://www.shreve.net/ | | mods/Homepage coming soon |LordSignal/SN| Quake server: 208.206.76.47 | \-------------------------- 318-222-2638 x109 -----------------------------/ > > Kevin > > E-Mail: s1kevin@tims.net > Web: http://users.sota-oh.com/~s1kevin/ > Unsolicited advertisements processing fee: $50 subject to change without notice > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Can Client over-ride assigned IP Address?
From: Andres Kroonmaa <andre@ml.ee>
Date: 1998-10-06 21:01:24

On 6 Oct 98, at 8:16, Jeff Mcadams <usr-tc@lists.xmission.com> wrote: > Thus spake Andres Kroonmaa > > Thankfully, netservers have an option to reject bogus IP's, although not > >without > > some braindead extras. If user comes in with his IP configured wrong, > >netserver > > rejects the _call_, dropping it. > > And if the end system refuses (config-nak's) the IP address that the > netserver gives to it, what is the netserver supposed to do? If the > end-station insists on its own IP number, the netserver has 2 options, > accept it eventually (I would agree this is a problem) or drop the call. > PPP negotiation *CANNOT* force a system to take a value that it doesn't > want, if the end-station wants a different there's not a whole lot the > netserver can do except drop the call. Right, _if_ the remote system rejects the hint and the ping-pong goes endless. But not _right_ after NAS sends its first reject, ok? Its ok with me to drop a call for the persistent abuser, but its not ok to drop a call for looser who happened to put an ip address into his dialup networking config and is having problems only with USR/3com, not with cisco, not with ascend, not with lucent, because they all politely reject the remote hint and try to assign remote user an ip address, until remote end ack's, drops the call himself or timeouts. Its not so unusal that some PPP stacks would "deal" with NAS for some time and eventually give up, kind of "ok, if you insist. I just thought that maybe..." > > So, I want to have answers for these questions: > > 1) HOW can user override NAS hints? I understand what you are talking about. This is what is called PPP negotiation. If remote end is allowed to negotiate for its IP address, then yes, remote user is allowed to override NAS hints. But if NAS is set to assign an IP to a remote user, how can remote user override it? This is what the question was about. I got an impression (from the initial mail I replied to) that it is possible somehow with 3com NAS. You can't judge me hard for being worried, I've seen things much worse than that with TC. > Depends on the software and how the PPP stack is set up to handle > specified IP addresses. Some take that as a requested IP adress and try > to conf-req that IP address from the other system...if it's nak'ed, > they'll accept whatever the other system gives them. Some PPP stacks > will absolutely insist on that IP address...if its nak'ed, it'll send > the conf-req again with that IP address in it, this can lead to a nak > war in ppp one side sends a req, the other side nak's it with a could you give some examples? is win95 DUN such an insisting stack? Or is it more of a requesting type? > different value and the original side rej's it and sends a new req with > the original value. What's the netserver supposed to do? drop the call > is the only real answer...and syslog something or something like that so > humans can get involved and clear up the misconfig. yes, drop the call, but _after_ login timeout. yes, log something. humans tend to call support line and yell at you that just 5 minutes back everything worked like a charm and not any more. And thats because their another call was placed on another chassis by telco. And there is almost nothing to debug, remote system starts its PPP session, and the NAS drops the call right away. > > 3) How will Harc handle rejection? Namely, would it drop a call or would > >it insist on NAS-provided hint? > > The HARC *CAN'T* insist on NAS-provided hints for the IP address. If > the end-station doesn't want to use that IP address, then the HARC can't > force it to! This is inherent with PPP. What I meant is 2 differing cases: (user comes in with his hint on its remote IP address) 1) NAS rejects the remote hint and provides its own hint instead, wait... or, 2) NAS rejects the remote hint and drops the call right away. What I was seeing is the 2nd case and that is what I'm angry about. More than that, the default is to accept anything the remote user "wishes". By "insisting" I meant that Harc should NOT accept dial-in user provided IP, unless it matches exactly NAS's hint or is from an IP pool and is free for use. As I can see, the correct way is to: 1) reject the remote hint, provide your own and wait for the remote end to ack. There is no good reason to drop a call until login timeout or retry limit is exceeded. Retry limit of 0 is definitely too bad. If the remote end does not accept what we require, they are free to leave, but this is way far from polite to slam a door at them just for their "asking wrong question". They might reconsider if you give them a chance... > >> This problem can be inhibited with filters that prevent the source address from > >> being anything other than a pool member or the dynamic assignment of a filter on > >> a per user basis. The dynamic assignment is the most thorough approach. > >> Example : 010 permit src-address = 10.10.10.120; #assume 10.10.10.120 is the > >> address assignd to the user. > >> 020 deny; > > > This has no use in current context. What you described is basically > >anti-spoofing > > filter, and as such is a good idea anyway, but if HARC populates bogus route > > into its routing tables this will not help at all. User either can't use > >the net, > > or he can't use the net AND additionally creates DoS for others. > > Unless the filter is built on the hinted IP address which prevents the > harc from passing any packets for the IP address that the end-station > eventually gets, if its not the hint'ed IP address, and thus, no DoS Passing or filtering packets is no problem. The problem appears when routing table says that legit backbone host resides on a dialup port of a NAS, and all traffic to it turns to that port as by better metric. Its no matter if the traffic is (or is not) filtered. This disrupts work for all others. (for eg. they can't reach real DNS server as long as the abusive user is online. If remote user used some gateway IP you need to go through to reach the NAS, you can't even telnet to it to drop the caller manually. etc.). And thats the problem. Filtering IP-spoofing has exactly zero effect here and is for totally other issues. > (assuming you also prevent it from being propogated in the routing > protocol, which is seperately controllable I believe). And this exact assumption is what I'm talking about. To support static IP users, you have to inject NAS rip updates into a backbone. You also expect (assumption again) that a system with several zeroes after $$ of its cost would do it right. You do not want to update routing filters in every place after you make some changes. Or should I, _just_ because you can't trust the TC chassis in any respect? And, if you have 400 modems in a single chassis, using single routing table, how can I filter on Harc what is added to its routing table and whats not? ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------

Subject: (usr-tc) Quake lag solved (maybe)
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-06 22:32:17

I just got the message below from a friend of mine. Although I haven't ever had a problem with my ping times in quake2 (I have a Voodoo1), almost every one of our tech pool has a voodoo 2, and this seems to solve their problems with 999 pings and such! I don't doubt that the UDP issue still exists in the NETServer, but this maybe a workaround. Keeps the data stream just calm enough that the asyncronous nature of the traffic doesn't get jammed up (I guess). Let me know what your findings are with this setting. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com >Try this to get better ping times in Quake: > >SET CL_MAXFPS "31" > >What is happening is the frame rate (fps) of your Voodoo 2 card is too high >and your modem can't handle the extra data that it has to send. It sucks not >being able to play Quake huh? Your Voodoo 2 card is too fast (GRIN). BTW, >the 31 number is the frame rate maximum. You can adjust it down to say 28 or >25 until your pings are good. I wouldn't go over 31 though.

Subject: (usr-tc) WAN ports on the netserver
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-06 22:39:48

Is it true (as the ComOS prompt seems to think) that "WAN ports only support frame_relay" as a protocol on the NETServer? I was actually hoping to do unnumbered PPP connections on these WAN ports. Anyone have any ideas on this? Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Subject: Re: (usr-tc) Quake lag solved (maybe)
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-06 22:51:54

Yeah, we found this (rather, one of our Voodoo 2 customers found this) a while ago. It takes care of Quake 2 for everyone that's tried it so far. Quake 1, on the other hand, is still a problem on a NETserver... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound? On Tue, 6 Oct 1998, Peter D. Mayer wrote: > I just got the message below from a friend of mine. Although I haven't ever > had a problem with my ping times in quake2 (I have a Voodoo1), almost every > one of our tech pool has a voodoo 2, and this seems to solve their problems > with 999 pings and such! I don't doubt that the UDP issue still exists in > the NETServer, but this maybe a workaround. Keeps the data stream just calm > enough that the asyncronous nature of the traffic doesn't get jammed up (I > guess). > Let me know what your findings are with this setting. > > Peter D. Mayer > NetWalk System Administrator > dmayer@netwalk.com > > > >Try this to get better ping times in Quake: > > > >SET CL_MAXFPS "31" > > > >What is happening is the frame rate (fps) of your Voodoo 2 card is too high > >and your modem can't handle the extra data that it has to send. It sucks > not > >being able to play Quake huh? Your Voodoo 2 card is too fast (GRIN). BTW, > >the 31 number is the frame rate maximum. You can adjust it down to say 28 > or > >25 until your pings are good. I wouldn't go over 31 though. > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Quake lag solved (maybe)
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-06 23:10:32

Man I just realized I haven't played Quake 1 in more than a year! Ouch. Maybe I missed this solution on the list? I read it pretty actively and I don't remember seeing this before. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- >Yeah, we found this (rather, one of our Voodoo 2 customers found this) a >while ago. It takes care of Quake 2 for everyone that's tried it so far. > >Quake 1, on the other hand, is still a problem on a NETserver... > > >

Subject: (usr-tc) dual E1/PRI card and UK2 interface
From: Stefanita Valcu <vsv@dnt.ro>
Date: 1998-10-06 23:25:54

Hello, My PTT is installing some sort of equipment called HYTAS ( http://www.ke-online.de ) in my basement which will provide some sort of E1 interface called Uk2. Does somebody ese such kind of interface, is it compatible with the dual E1/PRI card? I think that the interface card from the equipment is made by Alcatel. A put the interface's specifications at http://www.dnt.ro/~vsv/uk2.html Any help will be greatly appreciated. Thank you, -vsv --- Stefanita Valcu, http://www.dnt.ro/~vsv Network Engineer, Dynamic Network Technologies Calea Victoriei 155, bl.D1, sc.7, et.3, sector 1, 71102, Bucuresti, Romania tel: +40-1-6590696, fax: +40-1-3122745, E-mail: vsv@dnt.ro

Subject: Re: (usr-tc) WAN ports on the netserver
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-07 08:15:04

Thus spake Peter D. Mayer >Is it true (as the ComOS prompt seems to think) that "WAN ports only support >frame_relay" as a protocol on the NETServer? I was actually hoping to do >unnumbered PPP connections on these WAN ports. Anyone have any ideas on >this? Yup, frame-relay only. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) (USR-TC) ACCOUNTING AND R
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-10-07 08:40:00

U> Hi, U> Is there any workaround or suggestions for loss of accounting records U> from HiperArc Card (4.1.11). U> Problem is that it doesn't send (sometimes) ACCT OFF information U> to radius server when user disconnect. U> Is this bug only in 4.1.11, because if it is, maybe downgrade to U> 4.0.30 will solve this f*** problem? U> Is there anyone who have the same problem? This is very poor for U>ISP's and it drives me mad because i have so much information in base U>that users are online and thay are NOT! Wait. The problem cropped up during beta testing but didn't get fixed. I've had to turn off login tracking and just wait for it to be fixed. I'm going to do some testing tonight and send 3Com the detailed Radius logs. Note that it occurs with their Radius software too so I would expect they will be able to find it. Jeff Binkley ASA Network Computing CMPQwk 1.42 9999

Subject: Re: (usr-tc) WAN ports on the netserver
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-07 11:13:08

Which doesn't necessarily mean you can't run a point-to-point link with it. Just change the encaps on your other router to frame relay instead of ppp... Charles On Wed, 7 Oct 1998, Jeff Mcadams wrote: > Date: Wed, 7 Oct 1998 08:15:04 -0400 (EDT) > From: Jeff Mcadams <jeffm@iglou.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) WAN ports on the netserver > > Thus spake Peter D. Mayer > >Is it true (as the ComOS prompt seems to think) that "WAN ports only support > >frame_relay" as a protocol on the NETServer? I was actually hoping to do > >unnumbered PPP connections on these WAN ports. Anyone have any ideas on > >this? > > Yup, frame-relay only. > -- > 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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) WAN ports on the netserver
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-07 12:09:13

The problem with this idea is that I don't have any control over most of the equipment at the other end. <sigh> I can do a few of them on there. I guess I'll just have to hack it until we can get more ports in. Thanks, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- >Which doesn't necessarily mean you can't run a point-to-point link with >it. Just change the encaps on your other router to frame relay instead of >ppp... > >Charles >

Subject: (usr-tc) Hom much current of my 130A chassis?
From: cntlxh@163.net
Date: 1998-10-07 12:23:43

Hi, I use Hiper 130A DC power, but obviously one chassis cannot occupy 130A current, but hom much infact? I think it is 15~20A perhaps of one chassis. It is important to know these to install power to the chassis correctly. I need know how much current of one chassis in face. Can you tell me? Thanks. ________________________________________________ ��ӭ��ʹ�ù��Ӵ��ѵ��http://www.163.net

Subject: (usr-tc) Pt to Pt Test Link
From: Greg Coffey <greg@coffey.com>
Date: 1998-10-07 12:44:13

I'd like to setup a in-house 56k line that would be just to test some compression ideas. I'm trying to avoid installation fees if I can help it just to test. Can I set up something using 2 56k CSU's and routers? If not, is there a cheap box that I can buy that I can set this up with to test? ______________________________________________________ Thanks, Greg Coffey 307-234-5443 Fax 307-234-5446 CoffeyNet v.90 56k Access for Casper & Douglas 142 S. Center St. Casper, WY 82601 http://www.coffey.com

Subject: Re: (usr-tc) Pt to Pt Test Link
From: Frank Basso <frank@got.net>
Date: 1998-10-07 13:31:52

Look at black box, they have short haul v.35 modems -----Original Message----- >I'd like to setup a in-house 56k line that would be just to test some >compression ideas. I'm trying to avoid installation fees if I can help it >just to test. Can I set up something using 2 56k CSU's and routers? If >not, is there a cheap box that I can buy that I can set this up with to >test? >______________________________________________________ >Thanks, >Greg Coffey 307-234-5443 Fax 307-234-5446 >CoffeyNet v.90 56k Access for Casper & Douglas >142 S. Center St. >Casper, WY 82601 http://www.coffey.com > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) 10 DSP's & 1 ARC
From: Frank Basso <frank@got.net>
Date: 1998-10-07 13:35:08

We have this running with no problems. This is only an issue if you have MORE than 10... so say the Rumor Mill. -Frank -----Original Message----- >Wondering if anyone has had any experience running 10 DSP's and 1 ARC card >in one chassis? ... any recommendations? ... any problems? > >I will be using the lastest ARC beta code .... > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) convert to PRI- fast busy
From: Eric Billeter <ebilleter@cableone.net>
Date: 1998-10-07 13:38:39

Did you get circuit switched data and voice or just circuit switched data lines. Went through that one once .. luckily we caught it b4 activation. 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 Jeff Lynch Sent: Wednesday, October 07, 1998 1:22 PM Latest from the telco, They can connect 64K-data (we haven't verified yet, our test machine is down), but they see this message when trying to place an analog call: "Bearer capability not presently available" ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com On Wed, 7 Oct 1998, Curt Shambeau wrote: > > Dual-PRI > > Primary switch type (DMS100) > > Play with this - it should possibly be NI-2 instead of DMS100. > Ask your telco. > > > Modem call routing first available (as per telco) > > DNIS length 7 (also per telco) > > They have differing opinions on how to describe this. It may be that they > are *deleting* 7 instead, and your number should be ZERO. > > > Quads > > Line interface options PriTDM > > This would have been my first choice - make sure it stuck - that you > changed it, saved to NVRAM, and rebooted the cards. > > -------------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > | Executive 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. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) convert to PRI- fast busy
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-10-07 14:25:19

We're converting all our CT1s to PRIs. We've reflashed the Dual-T1/PRI code and have the D-channel is up. Called tech support and were told it should be taking calls (of course). Telco is on hold as I write this. Telco claims that all routing is in place yet we continue to get fast busy when trying to place a call. We have the 1866/1706 bundles with netserver/dual-pri/t1/quads. Here's what we changed: Dual-PRI Primary switch type (DMS100) ISDN-GW in slot 16 Analog modem calls enabled Modem call routing first available (as per telco) DNIS length 7 (also per telco) Quads Line interface options PriTDM Little help please? ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: Re: (usr-tc) convert to PRI- fast busy
From: Curt Shambeau <curt@execpc.com>
Date: 1998-10-07 14:39:51

> Dual-PRI > Primary switch type (DMS100) Play with this - it should possibly be NI-2 instead of DMS100. Ask your telco. > Modem call routing first available (as per telco) > DNIS length 7 (also per telco) They have differing opinions on how to describe this. It may be that they are *deleting* 7 instead, and your number should be ZERO. > Quads > Line interface options PriTDM This would have been my first choice - make sure it stuck - that you changed it, saved to NVRAM, and rebooted the cards. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Subject: Re: (usr-tc) convert to PRI- fast busy
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-10-07 15:22:12

Latest from the telco, They can connect 64K-data (we haven't verified yet, our test machine is down), but they see this message when trying to place an analog call: "Bearer capability not presently available" ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com On Wed, 7 Oct 1998, Curt Shambeau wrote: > > Dual-PRI > > Primary switch type (DMS100) > > Play with this - it should possibly be NI-2 instead of DMS100. > Ask your telco. > > > Modem call routing first available (as per telco) > > DNIS length 7 (also per telco) > > They have differing opinions on how to describe this. It may be that they > are *deleting* 7 instead, and your number should be ZERO. > > > Quads > > Line interface options PriTDM > > This would have been my first choice - make sure it stuck - that you > changed it, saved to NVRAM, and rebooted the cards. > > -------------------------------------------------------------------------- > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > | Executive 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. >

Subject: Re: (usr-tc) convert to PRI- fast busy
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-10-07 15:23:03

On Wed, 7 Oct 1998, Jamie Orzechowski wrote: > is the line coding set to B8ZS?? (or whatever your telco uses) ... Yes. No problems getting the D-chan up. > > -----Original Message----- > From: Jeff Lynch <jeff@mercury.jorsm.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, October 07, 1998 3:33 PM > Subject: (usr-tc) convert to PRI- fast busy > > > >We're converting all our CT1s to PRIs. We've reflashed the Dual-T1/PRI > >code and have the D-channel is up. Called tech support and were told > >it should be taking calls (of course). Telco is on hold as I write this. > >Telco claims that all routing is in place yet we continue to get fast > >busy when trying to place a call. We have the 1866/1706 bundles > >with netserver/dual-pri/t1/quads. > > > >Here's what we changed: > > > >Dual-PRI > > Primary switch type (DMS100) > > ISDN-GW in slot 16 > > Analog modem calls enabled > > Modem call routing first available (as per telco) > > DNIS length 7 (also per telco) > > > >Quads > > Line interface options PriTDM > > > > > >Little help please? > > > >========================================================================= > >Jeffrey A. Lynch JORSM Internet > >email: jeff@jorsm.com Northwest Indiana's Full-Service Provider > >Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 > >Autoresponse: info@jorsm.com http://www.jorsm.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. > ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: Re: (usr-tc) convert to PRI- fast busy
From: Jamie Orzechowski <mhz@recorder.ca>
Date: 1998-10-07 15:37:58

is the line coding set to B8ZS?? (or whatever your telco uses) ... -----Original Message----- >We're converting all our CT1s to PRIs. We've reflashed the Dual-T1/PRI >code and have the D-channel is up. Called tech support and were told >it should be taking calls (of course). Telco is on hold as I write this. >Telco claims that all routing is in place yet we continue to get fast >busy when trying to place a call. We have the 1866/1706 bundles >with netserver/dual-pri/t1/quads. > >Here's what we changed: > >Dual-PRI > Primary switch type (DMS100) > ISDN-GW in slot 16 > Analog modem calls enabled > Modem call routing first available (as per telco) > DNIS length 7 (also per telco) > >Quads > Line interface options PriTDM > > >Little help please? > >========================================================================= >Jeffrey A. Lynch JORSM Internet >email: jeff@jorsm.com Northwest Indiana's Full-Service Provider >Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 >Autoresponse: info@jorsm.com http://www.jorsm.com > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: solved Re: (usr-tc) convert to PRI- fast busy
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-10-07 15:48:24

T'was the dreaded non-stick teflon-coated quad settings. Had to save and reboot them. Thanks. ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com On Wed, 7 Oct 1998, Jeff Lynch wrote: > Latest from the telco, > > They can connect 64K-data (we haven't verified yet, our test machine > is down), but they see this message when trying to place an analog call: > > "Bearer capability not presently available" > > ========================================================================= > Jeffrey A. Lynch JORSM Internet > email: jeff@jorsm.com Northwest Indiana's Full-Service Provider > Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 > Autoresponse: info@jorsm.com http://www.jorsm.com > > On Wed, 7 Oct 1998, Curt Shambeau wrote: > > > > Dual-PRI > > > Primary switch type (DMS100) > > > > Play with this - it should possibly be NI-2 instead of DMS100. > > Ask your telco. > > > > > Modem call routing first available (as per telco) > > > DNIS length 7 (also per telco) > > > > They have differing opinions on how to describe this. It may be that they > > are *deleting* 7 instead, and your number should be ZERO. > > > > > Quads > > > Line interface options PriTDM > > > > This would have been my first choice - make sure it stuck - that you > > changed it, saved to NVRAM, and rebooted the cards. > > > > -------------------------------------------------------------------------- > > | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | > > | Executive 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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: solved Re: (usr-tc) convert to PRI- fast busy
From: Curt Shambeau <curt@execpc.com>
Date: 1998-10-07 16:04:48

Glad I could help. That bit me once or twice long ago when the only bundle deal you could get was the 1706 bundle which was for PRI. I needed them converted to Channelized T1, and spent much time doing so - flashing the Dual -PRI/T1 card, and reconfiguring the modems. Once in a while I would forget to save and reboot, and it was real confusing at first to troubleshoot. It was much easier when they created the 1866 bundle, and I could buy them pre-configured for CH-T1. > T'was the dreaded non-stick teflon-coated quad settings. Had to > save and reboot them. Thanks. > > > > Quads > > > > Line interface options PriTDM > > > > > > This would have been my first choice - make sure it stuck - that you > > > changed it, saved to NVRAM, and rebooted the cards. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Subject: (usr-tc) 10 DSP's & 1 ARC
From: Jamie Orzechowski <mhz@recorder.ca>
Date: 1998-10-07 16:18:42

Wondering if anyone has had any experience running 10 DSP's and 1 ARC card in one chassis? ... any recommendations? ... any problems? I will be using the lastest ARC beta code ....

Subject: (usr-tc) (USR-TC) ACCOUNTING AND R
From: Rick Payne <rickp@ops.netcom.net.uk>
Date: 1998-10-07 16:20:20

Jeff Binkley writes: > Wait. The problem cropped up during beta testing but didn't get fixed. > I've had to turn off login tracking and just wait for it to be fixed. > I'm going to do some testing tonight and send 3Com the detailed Radius > logs. Note that it occurs with their Radius software too so I would > expect they will be able to find it. The Arc doesn't even generate the accounting stops (well, according to the monitor radius) - though it will syslog that the call has disconected in the normal way. *sigh* Rick

Subject: (usr-tc) NFAS Support
From: Frank Basso <frank@got.net>
Date: 1998-10-07 16:28:57

Does anyone know how to enable and configure NFAS support on the HiPer Chassis. Thank you, -- Frank Basso Senior Network Engineer Got.Net? - The Internet Connection, Inc. Santa Cruz, California Voice: 831-460-2000 x117 FAX: 831-460-2004 When they took the fourth amendment, I was quiet because I didn't deal drugs. When they took the sixth amendment, I was quiet because I was innocent. When they took the second amendment, I was quiet because I didn't own a gun. Now they've taken the first amendment, and I can say nothing about it.

Subject: Re: (usr-tc) Hom much current of my 130A chassis?
From: Frank Basso <frank@got.net>
Date: 1998-10-07 16:33:37

They are rated @ 1080 Watts at 120Volts, or 10Amps Nominal, though they recommend a 15Amp circuit for each power supply. -----Original Message----- >Hi, > >I use Hiper 130A DC power, but obviously >one chassis cannot occupy 130A current, >but hom much infact? I think it is >15~20A perhaps of one chassis. > >It is important to know these >to install power to the chassis >correctly. > >I need know how much current of one >chassis in face. > >Can you tell me? > >Thanks. > >________________________________________________ >=BB=B6=D3=AD=C4=FA=CA=B9=D3=C3=B9=E3=D6=DD=CA=D3=B4=B0=C3=E2=B7=D1=B5=E7= =D7=D3=D3=CA=CF=E4http://www.163.net > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) RADIUS implementation in ARC 4.1.78 / Tricks
From: Carl Litt <carl@snel.execulink.com>
Date: 1998-10-07 20:04:26

I've spend the last several days trying to figure out this 'bug' I found in ARC 4.1.78. Like most, we have 2 RADIUS servers, a primary, and a secondary. The secondary is really only there for a safety net. It's not guaranteed to be current, however some is better than none. After upgrading to 4.1.78, I noticed the changes in SHOW AUTHEN, particularly a new value called "Active Authentication Server". For the first day, this value was my primary's IP number. Then, for no apparent reason, it changed to my secondary's IP number. After a bit of checking, I discovered the ARC was not authenticating to my primary RADIUS server anymore. There is no command to reset this. Well, it seems that the new code introduces a new 'feature' called SET RADIUS AUTHENTICATION_ALGORITHM. It has 2 choices. FALL_THROUGH is the expected behaviour (always try primary first, then secondary) as defined in the protocol and used most RADIUS clients, including previous ARC and NetServer code. The other choice which is the new default in 4.1.78 is ROUND_ROBIN, which says that if the primary does not respond once, switch all activity to the secondary until such time as it does not respond. This is what my ARC was doing. This is not what I want my ARC doing. After changing the algorithm back to FALL_THROUGH, my ARC is doing what I want it to do. The moral of this story is, if you upgrade to ARC 4.1.78, make sure you either reset this, or be darn sure your secondary is up-to-the-minute. Just another case of code trying to be too smart. BTW: Here are some unpublished tricks that may come in handy someday: To verify that a user & password is actually authenticated by RADIUS, use "_auth user password" 4.1.78 introduces MONITOR RADIUS, which can show you the full authentication and accounting packets, even in hex. Hey, it even tells you with RADIUS server was used! :)

Subject: Re: (usr-tc) DRAM&RAM upgrade kit
From: Jason W <jwatkins@iland.net>
Date: 1998-10-08 09:38:47

I believe the part-number for the USR memory upgrade kit for the Netserver cards is 002149-0 The latest release of software for the Netserver 16mb is 3.8.1 I believe. More info is available at 3com's site. http://totalservice.usr.com ********************************************************* Jason Watkins jwatkins@iland.net I-Land Internet Services http://www.iland.net Support & Network Operations Center ********************************************************* -----Original Message----- > >Hi! > >I have two TC's with quite old software release: > >Command>ver >U.S. Robotics >Total Control (tm) NETServer Card V.34 version 3.1.7 > Build date: Jan 5 1996 > Build time: 10:58:50 > > Licensed for 60 ports. > >I'd like to upgrade it, but I understand that I need to upgrade memory and flash >as well. I've found some relevant e-mails in the list's archive, but I still need >some answers: > >1. What are the part numbers for the upgrade? > I've seen in old messages that it could be 002453-2 (16 MB DRAM + 8 MB flash). > >2. What is the most recent SW release to be used with upgraded NAC? > >Thanks! > > Zvonko > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Dialback
From: Marcelo Maraboli <maraboli@dcsc.utfsm.cl>
Date: 1998-10-08 10:59:44

Read the following...

Subject: Re: (usr-tc) 10 DSP's & 1 ARC
From: Randy Doran <randydoran@usa.net>
Date: 1998-10-08 11:35:27

We had 3 chassis with 10 HiPerDSPs and one HiPerARC each. At first they appeared to work just fine but we started experiencing many modem errors and fast busies. We attributed this to the HiPerARCs having problems setting up the calls with that many HiPerDSPs in its ownership. After we added another HiPerARC to the chassis and had each ARC owning no more than 7 HiPerDSPs we never saw another modem error or fast busy. At the current HiPerARC code rev 4.1.11 I would not recommend more than 7 DSPs per HiPerARC. Randy Doran e.spire Communications \ CyberGate Network Operations Circuit Engineer \ Modem Network Administrator At 04:18 PM 10/7/98 -0400, Jamie Orzechowski wrote: >Wondering if anyone has had any experience running 10 DSP's and 1 ARC card >in one chassis? ... any recommendations? ... any problems? > >I will be using the lastest ARC beta code .... > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Lan to Lan, to a ascend P50
From: Joe Kvidera <joe.kvidera@solutionsgroup.net>
Date: 1998-10-08 12:08:13

We are attempting to establish a lan to lan connection with the total control dialing out to the ascend P50 (ISDN). The call is connected, the total control issues a LCP Configuration Request, and nothing happens. This is repeated about 5 times, and then the call drops. The only thing that is received is ppp_ifsend: Bad PPP Address. Any Ideas? Any help would greatly be appreciated. Joe Kvidera, MCP Solutions Group Corporation mailto:joe.kvidera@solutionsgroup.net http://www.solutionsgroup.net Ph: (612) 929-3670

Subject: (usr-tc) Filters
From: Total Control <totalc@solutionsgroup.net>
Date: 1998-10-08 12:16:41

has anyone succesfully attached filters to raduis users? We are using livingston raduis 1.1.6 and when ever we attach a filter to a specific user it nukes the user connection.

Subject: (usr-tc) DRAM&RAM upgrade kit
From: Zvonko Cvetanovski <zvonko@yugoslavia.eu.net>
Date: 1998-10-08 12:30:36

Hi! I have two TC's with quite old software release: Command>ver U.S. Robotics Total Control (tm) NETServer Card V.34 version 3.1.7 Build date: Jan 5 1996 Build time: 10:58:50 Licensed for 60 ports. I'd like to upgrade it, but I understand that I need to upgrade memory and flash as well. I've found some relevant e-mails in the list's archive, but I still need some answers: 1. What are the part numbers for the upgrade? I've seen in old messages that it could be 002453-2 (16 MB DRAM + 8 MB flash). 2. What is the most recent SW release to be used with upgraded NAC? Thanks! Zvonko

Subject: Re: (usr-tc) Filters
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-08 12:51:33

In your radius say you have a user with a filter Framed-Filter-Id = "std" now make sure you have two files in the NETServer/Hiper arc std.in and std.out Where std.in is the in filter and std.out is the out filter. This will fix your problem. 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, 8 Oct 1998, Total Control wrote: > has anyone succesfully attached filters to raduis users? We are using > livingston raduis 1.1.6 and when ever we attach a filter to a specific > user it nukes the user connection. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) DRAM&RAM upgrade kit
From: Wayne Barber <barberw@tidewater.net>
Date: 1998-10-08 13:08:19

With the card you currently have, the highest code you can go to is 3.3.3 (someone correct me if I'm wrong, but I went through some of this myself). If you want to put in more memory and go to the latest code, you need the Netserver PRI NAC/NIC combo (the NIC with the Frame Relay connections on it). Or at least the Frame Relay NIC with the old Netserver card. Good luck, Wayne Barber Coastal Telco Services > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jason W > Sent: Thursday, October 08, 1998 10:39 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) DRAM&RAM upgrade kit > > > I believe the part-number for the USR memory upgrade > kit for the Netserver cards is 002149-0 The latest release > of software for the Netserver 16mb is 3.8.1 I believe. > More info is available at 3com's site. > > http://totalservice.usr.com > > ********************************************************* > Jason Watkins jwatkins@iland.net > I-Land Internet Services http://www.iland.net > Support & Network Operations Center > ********************************************************* > -----Original Message----- > From: Zvonko Cvetanovski <zvonko@Yugoslavia.EU.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Thursday, October 08, 1998 5:38 AM > Subject: (usr-tc) DRAM&RAM upgrade kit > > > > > >Hi! > > > >I have two TC's with quite old software release: > > > >Command>ver > >U.S. Robotics > >Total Control (tm) NETServer Card V.34 version 3.1.7 > > Build date: Jan 5 1996 > > Build time: 10:58:50 > > > > Licensed for 60 ports. > > > >I'd like to upgrade it, but I understand that I need to upgrade > memory and flash > >as well. I've found some relevant e-mails in the list's > archive, but I still need > >some answers: > > > >1. What are the part numbers for the upgrade? > > I've seen in old messages that it could be 002453-2 (16 MB > DRAM + 8 MB flash). > > > >2. What is the most recent SW release to be used with upgraded NAC? > > > >Thanks! > > > > Zvonko > > > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) NFAS Support
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-08 14:09:08

NFAS is not currently supported on the HiPer DSP. It is in the wworks though. -----Original Message----- >Does anyone know how to enable and configure NFAS support on the HiPer >Chassis. > >Thank you, > >-- >Frank Basso >Senior Network Engineer >Got.Net? - The Internet Connection, Inc. >Santa Cruz, California >Voice: 831-460-2000 x117 >FAX: 831-460-2004 > >When they took the fourth amendment, I was quiet because I didn't deal >drugs. >When they took the sixth amendment, I was quiet because I was innocent. >When they took the second amendment, I was quiet because I didn't own a gun. >Now they've taken the first amendment, and I can say nothing about it. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Dialback
From: Bogdan Pelinescu <bpelin@itcnet.ro>
Date: 1998-10-08 14:10:22

Has anyone ever succeded in making a Netserver callback connection ? I have a Netserver 16, sodtware version 3.3.0 with V.34 modems. I've setup the location by the book and made a dialback netuser. The problem is that the Netserver authenticates the user, but Windows just disconnects, so when the Netserver dials back, there is no application using the modem. It seems that the Dial-up Networking application doesn't understand that this is a callback call. Here is my user configuration: add netuser zuzu password zuzu add location test set location test manual set location test destination some.ip.address set location test netmask 255.255.255.255 set location test protocol ppp set location test mtu 1500 set location test routing off set location test script 1 "atdt1223455\r" "CONNECT" set location test group 1 set location test maxports 1 set location test idletime 5 set user zuzu dialback test I have some modems in group 1 (s15, s16). Can anyone help ? Thanks, Bogdan Bogdan Pelinescu <bpelin@itcnet.ro> | R&D Engineer | Tel: (401) 232 2770 Institute for Computers | Networks & Communications Dept. | Fax: (401) 230 7845 Bucharest, Romania |

Subject: Re: (usr-tc) convert to PRI- fast busy
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-08 14:12:06

After downloading the PRI code and changing the switch settings you need to save no nvram and reboot the pri card. In addition, you may have to save your modems to nvram and reboot them after you change the line interface source to pritdm so th PRI card will remap it's tdm bus -----Original Message----- >We're converting all our CT1s to PRIs. We've reflashed the Dual-T1/PRI >code and have the D-channel is up. Called tech support and were told >it should be taking calls (of course). Telco is on hold as I write this. >Telco claims that all routing is in place yet we continue to get fast >busy when trying to place a call. We have the 1866/1706 bundles >with netserver/dual-pri/t1/quads. > >Here's what we changed: > >Dual-PRI > Primary switch type (DMS100) > ISDN-GW in slot 16 > Analog modem calls enabled > Modem call routing first available (as per telco) > DNIS length 7 (also per telco) > >Quads > Line interface options PriTDM > > >Little help please? > >========================================================================= >Jeffrey A. Lynch JORSM Internet >email: jeff@jorsm.com Northwest Indiana's Full-Service Provider >Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 >Autoresponse: info@jorsm.com http://www.jorsm.com > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Can Client over-ride assigned IP Address?
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-10-08 14:31:55

>On 5 Oct 98, at 15:01, Mike Wronski <usr-tc@lists.xmission.com> wrote: > WHAT?! And Harc would not reject such PPP sequence? Harc would instead accept > _user-provided-IP_ and will install a route into its routing tables?! > > Now imagine that a user sets his IP to be one of your primary DNS servers or > Radius server. Yes, he has no benefit from it, but if you run RIP on your backbone, > then all of the other customers (at least inside the same NAS) would turn their > traffic for given IP to this user port. > This is basically HUGE DoS. It has happened to us. Basically whole AS was out of > service, cute isn't it? I loved USR/3com for that "feature". > Thankfully, netservers have an option to reject bogus IP's, although not without > some braindead extras. If user comes in with his IP configured wrong, netserver > rejects the _call_, dropping it. Oh boy how stupid. I'm not sure how it is with > latest sw, I hoped it was fixed once and forever. And now you say its not?! > Ok, you see my concern. However it quickly turned to HARC's. We're running Netserver 3.5.34 on 3059 bundle TC racks and USR Radius. Static IP users are users setup on the Netserver itself with addresses outside the pool. All Radius Users (99% of our dial-up clients) are set to assigned address, as opposed to negotiated or specified address, through the USR Radius. I moved several users who were authenticated at the same times we logged the use of network 10.x.x.x usage and gave them static IP's, but it's still happening. I've narrowed it down to 3 possible users. So what "Braindead extras" do I need to prevent this? >> This problem can be inhibited with filters that prevent the source address from >> being anything other than a pool member or the dynamic assignment of a filter on >> a per user basis. The dynamic assignment is the most thorough approach. >> Example : 010 permit src-address = 10.10.10.120; #assume 10.10.10.120 is the >> address assignd to the user. >> 020 deny; > > This has no use in current context. What you described is basically anti-spoofing > filter, and as such is a good idea anyway, but if HARC populates bogus route > into its routing tables this will not help at all. User either can't use the net, > or he can't use the net AND additionally creates DoS for others. > Sooo... Is this something I can do? Are these Netserver Filters, or somthing in Radius? We do all our filtering on our Cisco router, so I've never had a reason to use the Netserver filters. Thanks Again, Steve Kinkaid

Subject: (usr-tc) Re: HARC ER fix Web TV
From: pferraro <pferraro@wna-linknet.com>
Date: 1998-10-08 14:43:37

Can someone tell me the correct size of this code? Somehow I have it as 2727635 on one and 2722328 on another?? this is the 4.1.78 code. Or could someone tell me were to get it again? It was file attached to me the first time around Thanks in adavnce! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: Re: (usr-tc) Re: HARC ER fix Web TV
From: pferraro <pferraro@wna-linknet.com>
Date: 1998-10-08 14:50:42

I figured it out... The smaller one is the 4.1.11 release. have both codes... Sorry for the extra email traffic! ============================================================================== 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, 8 Oct 1998, pferraro wrote: > > Can someone tell me the correct size of this code? Somehow I have > it as 2727635 on one and 2722328 on another?? > > this is the 4.1.78 code. Or could someone tell me were to get it again? > It was file attached to me the first time around > > Thanks in adavnce! > > ============================================================================== > Phillip Ferraro WorldNet Access, Inc > pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service > Voice (910) 346-0835 824 Gumbranch Square, Suite R3 > FAX (910) 455-1933 Jacksonville, Nc 28540-6269 > ============================================================================== > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Filters
From: Total Control <totalc@solutionsgroup.net>
Date: 1998-10-08 15:20:38

this has already been done, but it still kills the users connection every time we attach the filer ID in radius. -----Original Message----- Sent: Thursday, October 08, 1998 12:52 PM Cc: USR (E-mail) In your radius say you have a user with a filter Framed-Filter-Id = "std" now make sure you have two files in the NETServer/Hiper arc std.in and std.out Where std.in is the in filter and std.out is the out filter. This will fix your problem. 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, 8 Oct 1998, Total Control wrote: > has anyone succesfully attached filters to raduis users? We are using > livingston raduis 1.1.6 and when ever we attach a filter to a specific > user it nukes the user connection. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Problem with Modem Not Connecting
From: Cassandra M. Perkins <cassy@loop.com>
Date: 1998-10-08 15:29:00

I have a PRI card running software version 3.0.2 with both spans in use. The code running on my modems is version 5.10.9. The PRI card is configured for "first available" modem assignment. The second span works fine, but the first span stopped answering. When I dial in, I would either get a busy signal or dead air (no sound other than a click just before I'm disconnected.) I've seen this before when a single modem in the pool had a red led. Resetting the modem cleared it up. However, this time I cannot find the cause. Does anyone have an idea of why this is happening? Thanks in advance. | 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 |

Subject: (usr-tc) Accounting and Radius problem...
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-10-08 15:36:52

I realize your talking HARC, and we have Netservers, but this might be of some help. We were having a problem like this, and it was really skewing the accounting reports. We're using the Windows version of Radius with Microsoft Access. You didn't say which one your using. The problem in our case, was the Accounting Server database got quite large. The server spent so much time reading/writing to disk that whenever you tried to run reports, it would drop packets coming from the Hubs. Apparantly the Security/Accounting server does not acknowledge receipt of packets to the Netserver. We resolved the problem by upgrading the server hardware, and purging older records from the database. If you purge the Database, you need to compact the database, or it will still be huge and slow. (For MS Access, it's tools, database utilities, compact) Steve Kinkaid Steve@flasuncoast.net >X-POP3-Rcpt: usrtcmail@mail >Return-Path: owner-usr-tc@lists.xmission.com >From: "Dragan D. Vecerina" <vexi@yubc.net> >Subject: (usr-tc) Accounting and Radius problem... >To: usr-tc@xmission.com >Date: Tue, 6 Oct 1998 18:11:44 +0200 (CEST) >Cc: vexi@avala.yubc.net (Dragan D. Vecerina) >Sender: owner-usr-tc@lists.xmission.com >Precedence: bulk >Reply-To: usr-tc@lists.xmission.com > > > Hi, > Is there any workaround or suggestions for loss of accounting records > from HiperArc Card (4.1.11). > Problem is that it doesn't send (sometimes) ACCT OFF information > to radius server when user disconnect. > Is this bug only in 4.1.11, because if it is, maybe downgrade to > 4.0.30 will solve this f*** problem? > Is there anyone who have the same problem? This is very poor for ISP's > and it drives me mad because i have so much information in base that > users are online and thay are NOT! > > Dragan D. Vecerina > System Admin > YUBC System > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) Lan to Lan, to a ascend P50
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-08 17:09:06

Search on Interproc http://interproc.ae.usr.com/tkb.html Search for lan-to-lan 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, 8 Oct 1998, Joe Kvidera wrote: > We are attempting to establish a lan to lan connection with the total > control dialing out to the ascend P50 (ISDN). The call is connected, the > total control issues a LCP Configuration Request, and nothing happens. > This is repeated about 5 times, and then the call drops. The only thing > that is received is ppp_ifsend: Bad PPP Address. > > Any Ideas? Any help would greatly be appreciated. > > Joe Kvidera, MCP > Solutions Group Corporation > mailto:joe.kvidera@solutionsgroup.net > http://www.solutionsgroup.net > Ph: (612) 929-3670 > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Filters
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-08 17:10:58

You are doing something wrong there. Either the name of the filter is sent wrong or either you have a filter that is filtering the dialin user Need to take a look - Need either a snoop trace of the radius packet. or access to your netserver. 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, 8 Oct 1998, Total Control wrote: > this has already been done, but it still kills the users connection > every time we attach the filer ID in radius. > > -----Original Message----- > From: Tatai SV Krishnan [mailto:tkrishna@bubba.ae.usr.com] > Sent: Thursday, October 08, 1998 12:52 PM > To: Total Control > Cc: USR (E-mail) > Subject: Re: (usr-tc) Filters > > > In your radius say you have a user with a filter > > Framed-Filter-Id = "std" > > now make sure you have two files in the NETServer/Hiper arc > > std.in and std.out > > Where std.in is the in filter and std.out is the out filter. > > This will fix your problem. > > 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, 8 Oct 1998, Total Control wrote: > > > has anyone succesfully attached filters to raduis users? We are using > > livingston raduis 1.1.6 and when ever we attach a filter to a specific > > user it nukes the user connection. > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Quick disconnection of ISDN Call
From: cntlxh@163.net
Date: 1998-10-08 20:05:08

Hi: I have configed my ISDN Hiper DSP(code:1.2.78): I am using E1 Line in China. chdev span cmd rdefault set sigmode msgorien set swtype ictr4 set ltype mfe1 set nicfgtyp long set txlibo 0.0db set idlebyte 0x7E cmd svspcfg chdev root reboot at the same time, I have config Hiper ARC correctly(I think so). Now it is time to use my TA to do ISDN call, after established connection, I do browser some web site for a wile, but after less 3 minutes, Connection have been disconnected. Why? What should I do to find the problem? Hiper ARC code is 4.1.78. Best regards. LXH ________________________________________________ ��ӭ��ʹ�ù��Ӵ��ѵ��http://www.163.net

Subject: (usr-tc) Perhaps Hiper DSP Card Hardware failure!!
From: cntlxh@163.net
Date: 1998-10-08 21:12:44

I have one Hiper DSP for ISDN Call, but have some question described by my last e-mail. Now I have two Hiper DSP for PSTN Call, but quick disconnect after connection established. Why? I go to Hiper DSP console port, and knock: mdm4>ati6 at last display: nect Reason is PKT Bus-Received LS while Link up 0 What's meaning of the line information? Do it show my Hiper DSP is bad, which need ask 3COM to replace? Wait for your help! Best Regards. LXH ________________________________________________ ��ӭ��ʹ�ù��Ӵ��ѵ��http://www.163.net

Subject: Re: (usr-tc) Problem with Modem Not Connecting
From: Cassandra M. Perkins <cassy@loop.com>
Date: 1998-10-08 21:12:46

Brian, I'm not using DNIS information to determine access of the originating call. In my Call Control Options, the DNIS Based Incoming Call Digits is set to zero. The value is the same across my four TC units. Thanks for the response. | 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 Thu, 8 Oct 1998, Brian K McIntire wrote: > If the problem you are having is getting dead air, a busy a few seconds > later, while a modem goes off hook then the issue is most lekely related to > the DNIS based incoming call digit configuration under the modem > configurations. Make sure the number you select matches the number of DNIS > digits the telco is sending you. > -----Original Message----- > From: Cassandra M. Perkins <cassy@loop.com> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Thursday, October 08, 1998 5:39 PM > Subject: (usr-tc) Problem with Modem Not Connecting > > > >I have a PRI card running software version 3.0.2 with both spans in use. > >The code running on my modems is version 5.10.9. The PRI card is > >configured for "first available" modem assignment. The second span works > >fine, but the first span stopped answering. > > > >When I dial in, I would either get a busy signal or dead air (no sound > >other than a click just before I'm disconnected.) I've seen this before > >when a single modem in the pool had a red led. Resetting the modem > >cleared it up. However, this time I cannot find the cause. Does anyone > >have an idea of why this is happening? > > > >Thanks in advance. > > > >--------------------------------------------------------------------------- > - > >| 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 | > >--------------------------------------------------------------------------- > - > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Problem with Modem Not Connecting
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-08 22:45:45

If the problem you are having is getting dead air, a busy a few seconds later, while a modem goes off hook then the issue is most lekely related to the DNIS based incoming call digit configuration under the modem configurations. Make sure the number you select matches the number of DNIS digits the telco is sending you. -----Original Message----- >I have a PRI card running software version 3.0.2 with both spans in use. >The code running on my modems is version 5.10.9. The PRI card is >configured for "first available" modem assignment. The second span works >fine, but the first span stopped answering. > >When I dial in, I would either get a busy signal or dead air (no sound >other than a click just before I'm disconnected.) I've seen this before >when a single modem in the pool had a red led. Resetting the modem >cleared it up. However, this time I cannot find the cause. Does anyone >have an idea of why this is happening? > >Thanks in advance. > >--------------------------------------------------------------------------- - >| 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 | >--------------------------------------------------------------------------- - > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Accounting and Radius problem... (fwd)
From: Dragan D. Vecerina <vexi@yubc.net>
Date: 1998-10-08 23:44:39

OK, things are like this, THERE IS really bug in TC HiperArc 4.1.11 - 4.1.78 software. It doesn't have anything with version of radius server. You can test it with SA6 from 3COM or with livingston radius 2.0.1 as I do. The problem seems to be in some pointer or whatelse because I think and syslog messages shows that TC forget the username of connected user during the sessions in some cases. The problem (on my observation) was noticed during the beta test of 4.1.x and going on and on. Maybe, but only maybe, the Interim packets solves this problem but this is not a solution if 3COM count on this. Solution: Downgrade to 4.0.30 it works perfect! You'll lose some features but accounting information would be correct. Proposition: 3COM should take a look at their code for HiperArc cards:) > I realize your talking HARC, and we have > Netservers, but this might be of some help. > We were having a problem like this, and it > was really skewing the accounting reports. > > We're using the Windows version of Radius > with Microsoft Access. You didn't say which > one your using. > > The problem in our case, was the Accounting > Server database got quite large. The server > spent so much time reading/writing to disk > that whenever you tried to run reports, it > would drop packets coming from the Hubs. > Apparantly the Security/Accounting server > does not acknowledge receipt of packets to > the Netserver. > > We resolved the problem by upgrading the > server hardware, and purging older records > from the database. > > If you purge the Database, you need to compact > the database, or it will still be huge and slow. > (For MS Access, it's tools, database utilities, > compact) > > Steve Kinkaid > Steve@flasuncoast.net > > > > > >X-POP3-Rcpt: usrtcmail@mail > >Return-Path: owner-usr-tc@lists.xmission.com > >From: "Dragan D. Vecerina" <vexi@yubc.net> > >Subject: (usr-tc) Accounting and Radius problem... > >To: usr-tc@xmission.com > >Date: Tue, 6 Oct 1998 18:11:44 +0200 (CEST) > >Cc: vexi@avala.yubc.net (Dragan D. Vecerina) > >Sender: owner-usr-tc@lists.xmission.com > >Precedence: bulk > >Reply-To: usr-tc@lists.xmission.com > > > > > > Hi, > > Is there any workaround or suggestions for loss of accounting records > > from HiperArc Card (4.1.11). > > Problem is that it doesn't send (sometimes) ACCT OFF information > > to radius server when user disconnect. > > Is this bug only in 4.1.11, because if it is, maybe downgrade to > > 4.0.30 will solve this f*** problem? > > Is there anyone who have the same problem? This is very poor for ISP's > > and it drives me mad because i have so much information in base that > > users are online and thay are NOT! > > > > Dragan D. Vecerina > > System Admin > > YUBC System > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > >

Subject: RE: (usr-tc) DRAM&RAM upgrade kit
From: Zvonko Cvetanovski <zvonko@yugoslavia.eu.net>
Date: 1998-10-09 10:48:44

--- On Thu, 8 Oct 1998 13:08:19 -0400 Wayne Barber <barberw@tidewater.net> wrote: >With the card you currently have, the highest code you can go to is 3.3.3 >(someone correct me if I'm wrong, but I went through some of this myself). >If you want to put in more memory and go to the latest code, you need the >Netserver PRI NAC/NIC combo (the NIC with the Frame Relay connections on >it). Or at least the Frame Relay NIC with the old Netserver card. > > I tried to install 3.3.3, but it can not be loaded, I think because of too small flash. Also, with 3.2.3, NAC just hangs after few hours of work (I suspect that it is because of some memory leakage). But, if I correctly understand, you said that I can run 3.3.3 without adding flash and DRAM? Hardware version is 48.52.0, inventory reports 0 DRAM and 0 Flash RAM. Regards! Zvonko

Subject: Re: (usr-tc) 2nd subnet on ARC
From: Frank Basso <frank@got.net>
Date: 1998-10-09 11:34:09

You just need to define a second network on the unit, we do this to accomodate redundancy, though you can also enable the second ethernet port also. This is all covered in the 1.0 Hiper ARC manual. -Frank -----Original Message----- >Hello, can the ARC ethernet interface accommodate a second >subnet? If yes then how would I, syntactically, define it on the >card? I.E. for a Cisco 25xx eth interface I'd say: > >ip address 10.1.1.1 255.255.255.0 secondary > >Any tips? > >blake > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) 2nd subnet on ARC
From: Blake Fithen <fithen@networksplus.net>
Date: 1998-10-09 12:03:58

Hello, can the ARC ethernet interface accommodate a second subnet? If yes then how would I, syntactically, define it on the card? I.E. for a Cisco 25xx eth interface I'd say: ip address 10.1.1.1 255.255.255.0 secondary Any tips? blake

Subject: (usr-tc) General Questions
From: Chad J. LaFrenz <clafrenz@rof.net>
Date: 1998-10-09 12:39:21

Hello All-- First, thank you to Andres Kroonmaa for sending me the very helpful information on OSPF and routing. I have implemented some of it and believe to have the different IP subnet problem resolved (although time will tell hehe). Diving into some of the other settings in the Netservers and their routing for ports I came across some settings that I have never touched and am wondering if they are worthwhile to implement. 1. set <port> protocol ppp -- never have I issued this command to a port and am wondering if it is needed to insure any better connections/reliability/etc. 2. set <port> routing <option> (options being On, Broadcast, Listen, Off) -- again never have I implemented this and am wondering if it would increase stability of routes being assigned by RIP. 3. Radius entry: Framed-Routing = <option> (options being None, Broadcast, Listen, Broadcast-Listen) -- I currently have all users set to Framed-Routing = None. Again, wondering if enabling would allow for anything that None does not. As you can tell from my above questions, routing/routes and the like are not my forte (I have always been more on the server side aspects like sendmail, web services, etc. until recently) although I have been trying to devour information from the web and books to increase my knowledge. Many thanks in advance for any information on the above topics. Regards, Chad J. LaFrenz Senior System Administrator RoFIntUG V: 970-945-4920 F: 970-947-1923 Proudly serving the Aspen, Glenwood Springs, Rifle, and Vail Valleys. http://www.rof.net

Subject: (usr-tc) PM3
From: Randy Cosby <dcosby@infowest.com>
Date: 1998-10-09 13:15:12

First: I don't want to start a flame war here. I have USR/3Com Quads as well as Hiper. I would like to hear some opinions from those who have worked with both the PM3's as well as the 3com equipment. Is anyone considering moving back to PM3? Why or why not? Anyone dumped the PM3 in favor of 3Com? A big deciding factor for me on the 3Com's was the X2 early availability. That's no longer a factor. We are about to add a bunch of ports, and have gotten some good offers on PM3's. I don't really want to change platforms, but I'm hearing good things from the PM3 crowd. Is this just a culture thing, or is there really a lot to cheer about with the PM3's vs the 3com solutions? Thanks for the feedback. Randy

Subject: Re: (usr-tc) General Questions
From: MegaZone <megazone@megazone.org>
Date: 1998-10-09 13:24:42

Once upon a time Chad J. LaFrenz shaped the electrons to say... >1. set <port> protocol ppp -- never have I issued this command to a port >and am wondering if it is needed to insure any better >connections/reliability/etc. This is a ComOS setting that is used for a hardwired (nailed up) port, not for dialin or dialout. >2. set <port> routing <option> (options being On, Broadcast, Listen, >Off) -- again never have I implemented this and am wondering if it would >increase stability of routes being assigned by RIP. Ditto. Determines if routing info is used on a dedicated line. >3. Radius entry: Framed-Routing = <option> (options being None, Broadcast, >Listen, Broadcast-Listen) -- I currently have all users set to >Framed-Routing = None. Again, wondering if enabling would allow for >anything that None does not. Non is correct for 99.99% of users. You only use Broadcast IF the user is running something that can understand RIP. And Listen is risky because you are allowing the user to inject routes into your network. This setting conly controls routing on the user connection. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: RE: (usr-tc) PM3
From: Jose de Leon <jadiel@thevision.net>
Date: 1998-10-09 13:50:31

We have one TC and based on our experiences with the one TC we are buying only PM3s. The current version of the PM3 3.8 code with v.90 seems to be fairly stable. Although other ISPs seem to have 3Com modem customers have problems connect to the PM3s and stay on, we are seeing no problems whatsoever. In fact, our customers with 3Com modems are seeing faster connect rates and more stable connections! Jose > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy Cosby > Sent: Friday, October 09, 1998 12:15 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) PM3 > > > First: I don't want to start a flame war here. > > I have USR/3Com Quads as well as Hiper. > > I would like to hear some opinions from those who have worked > with both the > PM3's as well as the 3com equipment. Is anyone considering moving back to > PM3? Why or why not? Anyone dumped the PM3 in favor of 3Com? A big > deciding factor for me on the 3Com's was the X2 early > availability. That's > no longer a factor. > > We are about to add a bunch of ports, and have gotten some good offers on > PM3's. I don't really want to change platforms, but I'm hearing > good things > from the PM3 crowd. Is this just a culture thing, or is there > really a lot > to cheer about with the PM3's vs the 3com solutions? > > Thanks for the feedback. > > Randy > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) General Questions
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-09 13:51:18

Someone correct me if I'm wrong but I believe the "Set <port #> protocol <protocol> is used for hardwired connections only I can't see any reason for using the routing option for for non lan to lan routing connections As far as the radius entry. Same thing as above. Not beneficial for most users \ -----Original Message----- >Hello All-- > >First, thank you to Andres Kroonmaa for sending me the very helpful >information on OSPF and routing. I have implemented some of it and believe >to have the different IP subnet problem resolved (although time will tell >hehe). > >Diving into some of the other settings in the Netservers and their routing >for ports I came across some settings that I have never touched and am >wondering if they are worthwhile to implement. > >1. set <port> protocol ppp -- never have I issued this command to a port >and am wondering if it is needed to insure any better >connections/reliability/etc. > >2. set <port> routing <option> (options being On, Broadcast, Listen, >Off) -- again never have I implemented this and am wondering if it would >increase stability of routes being assigned by RIP. > >3. Radius entry: Framed-Routing = <option> (options being None, Broadcast, >Listen, Broadcast-Listen) -- I currently have all users set to >Framed-Routing = None. Again, wondering if enabling would allow for >anything that None does not. > >As you can tell from my above questions, routing/routes and the like are not >my forte (I have always been more on the server side aspects like sendmail, >web services, etc. until recently) although I have been trying to devour >information from the web and books to increase my knowledge. > >Many thanks in advance for any information on the above topics. > > >Regards, > >Chad J. LaFrenz >Senior System Administrator >RoFIntUG > >V: 970-945-4920 F: 970-947-1923 > >Proudly serving the Aspen, Glenwood Springs, Rifle, and Vail Valleys. > >http://www.rof.net > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Problem with Modem Not Connecting
From: Sebastian Bielinski <seba@veracomp.com.pl>
Date: 1998-10-09 14:06:45

Hi all, You can check Idle byte setting if it's correct, but more probably the PRI card is faulty. I have a card here that is working .. ups .. better to say - "not working" in the same way. After replacing a card with other one - everything works just fine. The configuration of both cards is the same (I hope). regards, -- Sebastian Bielinski +-------------------------------+--------------------------------+ | VERACOMP | tel (+48 12) 411 10 44 ext. 66 | | Network Systems Department | fax (+48 12) 422 23 52 | | email: seba@veracomp.com.pl | GSM (+48) 601 70 59 80 | | http://www.veracomp.com.pl | | +-------------------------------+--------------------------------+ Cassandra M. Perkins wrote: > I have a PRI card running software version 3.0.2 with both spans in use. > The code running on my modems is version 5.10.9. The PRI card is > configured for "first available" modem assignment. The second span works > fine, but the first span stopped answering. > > When I dial in, I would either get a busy signal or dead air (no sound > other than a click just before I'm disconnected.) I've seen this before > when a single modem in the pool had a red led. Resetting the modem > cleared it up. However, this time I cannot find the cause. Does anyone > have an idea of why this is happening? > > Thanks in advance. > > ---------------------------------------------------------------------------- > | 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 | > ---------------------------------------------------------------------------- > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) PM3
From: Joe Kvidera <joe.kvidera@solutionsgroup.net>
Date: 1998-10-09 14:21:18

If you are planning on doing dial out / dial back ISDN, we have seen the PM3's do a much better job, as in the can do it. Joe Kvidera, MCP Solutions Group Corporation mailto:joe.kvidera@solutionsgroup.net http://www.solutionsgroup.net Ph: (612) 929-3670 -----Original Message----- Sent: Friday, October 09, 1998 2:15 PM First: I don't want to start a flame war here. I have USR/3Com Quads as well as Hiper. I would like to hear some opinions from those who have worked with both the PM3's as well as the 3com equipment. Is anyone considering moving back to PM3? Why or why not? Anyone dumped the PM3 in favor of 3Com? A big deciding factor for me on the 3Com's was the X2 early availability. That's no longer a factor. We are about to add a bunch of ports, and have gotten some good offers on PM3's. I don't really want to change platforms, but I'm hearing good things from the PM3 crowd. Is this just a culture thing, or is there really a lot to cheer about with the PM3's vs the 3com solutions? Thanks for the feedback. Randy - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) General Questions
From: Brian <signal@shreve.net>
Date: 1998-10-09 15:07:55

> 2. set <port> routing <option> (options being On, Broadcast, Listen, > Off) -- again never have I implemented this and am wondering if it would > increase stability of routes being assigned by RIP. To announce routes it should be broadcast or on > > 3. Radius entry: Framed-Routing = <option> (options being None, Broadcast, > Listen, Broadcast-Listen) -- I currently have all users set to > Framed-Routing = None. Again, wondering if enabling would allow for > anything that None does not. It should be None, since you generally don't want routing protocol information exchanged between you and your dialup customers. However some radius implementations or netserver code versions have this backwards, and None actually turns it on! > > As you can tell from my above questions, routing/routes and the like are not > my forte (I have always been more on the server side aspects like sendmail, > web services, etc. until recently) although I have been trying to devour > information from the web and books to increase my knowledge. > > Many thanks in advance for any information on the above topics. > > > Regards, > > Chad J. LaFrenz > Senior System Administrator > RoFIntUG > > V: 970-945-4920 F: 970-947-1923 > > Proudly serving the Aspen, Glenwood Springs, Rifle, and Vail Valleys. > > http://www.rof.net > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) General Questions
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-09 15:15:27

Thus spake Chad J. LaFrenz >2. set <port> routing <option> (options being On, Broadcast, Listen, >Off) -- again never have I implemented this and am wondering if it would >increase stability of routes being assigned by RIP. This controls whether you run RIP (or RIPv2) on the port specified. This is most likely a "Bad Thing(tm)" as it would allow your users to then inject routes into your IGP and cause some potentially very ugly things to happen. >3. Radius entry: Framed-Routing = <option> (options being None, Broadcast, >Listen, Broadcast-Listen) -- I currently have all users set to >Framed-Routing = None. Again, wondering if enabling would allow for >anything that None does not. This is basically the same thing as above, but enables it on the port based on the user that is connected to it. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) PM3
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-09 15:16:09

On Fri, 9 Oct 1998, Randy Cosby wrote: > I would like to hear some opinions from those who have worked with both the > PM3's as well as the 3com equipment. Is anyone considering moving back to > PM3? Why or why not? Anyone dumped the PM3 in favor of 3Com? A big > deciding factor for me on the 3Com's was the X2 early availability. That's > no longer a factor. Well, we're not dumping PM3s. We're actually buying PM3s to supplement our 3Com stuff. We have three Total Control Racks, and I won't buy any more. > We are about to add a bunch of ports, and have gotten some good offers on > PM3's. I don't really want to change platforms, but I'm hearing good things > from the PM3 crowd. Is this just a culture thing, or is there really a lot > to cheer about with the PM3's vs the 3com solutions? If you don't need to add ports today, I'd wait to see if Lucent can fix the V.90 problems in the current 3.8 code. I've done some testing with a half dozen V.90 modems, and only the 3Com stuff can connect to every V.90 I have, and stay connected. In particular, 3Com modems won't stay connected for more than a few minutes to a PM3. I'd say that the software in the PM3 beats the Total Control hands down. Brian

Subject: Re: (usr-tc) Web TV Help Needed
From: Richard Lorbieski <richard@mail.alpha1.net>
Date: 1998-10-09 15:34:50

Call USR support and request Hiper ARC ver. 4.1.78 They send me a copy via email - but I have not install it :-(. Richard Lorbieski Russ Miescke wrote: > > Arter reading about various problems for the past couple of weeks with Web > TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load it > anyway. Bad move. Now all my Web TV customers are having problems > connecting. I think I saw there was an fix released for this, but do not > know where to find it. Any help would be appreciated. > > Russ Miescke > Power Web Connect > russm@powerweb.net > 920-885-7860 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) ISDN: netserver vs modems
From: Leon McCalla <ascend@caribbeanlink.com>
Date: 1998-10-09 15:35:02

Is there an advantage to using the netserver to terminate ISDN calls instead or the quadmodem or HDM? Leon

Subject: RE: (usr-tc) DRAM&RAM upgrade kit
From: Wayne Barber <barberw@tidewater.net>
Date: 1998-10-09 15:40:05

> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Zvonko Cvetanovski > Sent: Friday, October 09, 1998 6:49 AM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) DRAM&RAM upgrade kit > I tried to install 3.3.3, but it can not be loaded, I think because > of too small flash. Also, with 3.2.3, NAC just hangs after few hours > of work (I suspect that it is because of some memory leakage). > > But, if I correctly understand, you said that I can run 3.3.3 without > adding flash and DRAM? > > Hardware version is 48.52.0, inventory reports 0 DRAM and 0 Flash RAM. > > Regards! > > Zvonko No dram and no flash? No wonder you cannot load software. Seriously, what I said earlier about software may not be correct, but if you want to go to the latest software you must have the high-speed NIC. Even with the proper amount of memory, the netserver would just reboot repeatedly. Good luck, Wayne Barber

Subject: (usr-tc) Per-User default routes
From: Dave Martin <dpm@netcetera.com>
Date: 1998-10-09 17:11:00

We have a client who wishes to offer "filtered" connections to the Internet. The product they wish to use (Bess, from www.n2h2.com) would like to have filtered users directed toward their box when they connect. The RADIUS dictionary provided with MERIT 3.6B basic has an entry: USR-IP-Default-Route-Option I haven't been able to find a reference to this in any of the USR documentation. So, the $99 question: is there a way to set up RADIUS per-user default routes with USR (specifically HiPerARC) equipment and does it involve the use of the above RADIUS parameter? TIA... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

Subject: Re: (usr-tc) PM3
From: bryan s. blank <bryan@supernet.net>
Date: 1998-10-09 19:55:18

|o| from the PM3 crowd. Is this just a culture thing, or is there really a lot |o| to cheer about with the PM3's vs the 3com solutions? replacing the quads and hipers with pm3's as fast as i can good luck with whatever you choose! |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

Subject: Re: (usr-tc) Can Client over-ride assigned IP Address?
From: Andres Kroonmaa <andre@ml.ee>
Date: 1998-10-09 20:00:39

On 6 Oct 98, at 14:42, Jeff Mcadams <usr-tc@lists.xmission.com> wrote: > > I understand what you are talking about. This is what is called PPP > > negotiation. If remote end is allowed to negotiate for its IP address, > > then yes, remote user is allowed to override NAS hints. > > But if NAS is set to assign an IP to a remote user, how can remote > > user override it? > > There's no concept in PPP of an "assigned" address....addresses are > *always* negotiated. Now, one side may be *extremely* yielding in that > negotatiation "I don't know what IP address you have, anything you pick > will be fine with me" (to anthropomorphize a bit :) yes-yes. There is still communication problem between us. There is no concept of assigned IP in PPP, and I don't care. But there is a concept that ISP assigns IP address to its dialin customer, and NOT the customer himself. Please agree that when we manage systems, we might think in terms of security policies, not PPP rfc concepts. And "if NAS is set to assign an IP to a remote user, how can remote user override it?" By "NAS is set to assign" I mean NAS is configured to reject remote and bogus "wishes". > > could you give some examples? is win95 DUN such an insisting stack? Or > > is it more of a requesting type? > > I don't know how win95 deals with it. I'm not sure either. What I've seen is that when dialin user falls the drain, his PPP stack (dunno which one) "remembers" its last assigned IP and redials. then during PPP neg it asks, hints, or whatever to be assigned the same IP. This has very good logic behind it, as if the NAS assigns him the same IP the user has a chance to resume possibly interrupted transfer. If the NAS drops the call "for that asking", its nasty. Cisco, for eg. would grant such hints, as long as wished IP is from a legal range and is not in use. Its sort of compromise - cisco gives you control over how IP is assigned and yet it tries to be nice. > > What I meant is 2 differing cases: > > (user comes in with his hint on its remote IP address) > > 1) NAS rejects the remote hint and provides its own hint instead, wait... > > or, > > 2) NAS rejects the remote hint and drops the call right away. > > Yes, I agree, rejecting the remote req and dropping the call would be > broken IMHO. > -- Fine. now that we mostly have arrived to common ground, lets revise what we've been talking about. 1) Mike Wronski dropped a phrase that remote user can, under some circumstancies, override the IP assigned by NAS and come online with his own selected favourite IP. 2) I almost fell down from my chair and yelled WHAT?! 3) I asked to clarify, a) HOW can user override IP assignment? b) HOW can we block that? 4) We came to trivial case of PPP negotiated IP, talked straight that ISP can NOT let user elect an IP he wishes, but the IP assigned has to be from strictly limited selections. 5) I hope I clarified enough the consequencies of allowing remote user picking his favourite IP for the session, namely there is a huge DoS possibility behind that. 6) We've been talking about IP filtering, anti-spoof filtering, and I hope I've managed to make clear the lethal difference between spoofed IP traffic and bogus routing table entry. I pointed out that spoofed traffic is miserably least important compared to bogus routing table. I also noted that anti-spoofing filters are good practice anyway, for totally different reasons. 7) In initial post I asked also to clarify how rejected remote hints are handled on HARC and Netserver, namely: a) is session terminated immediately? b) is PPP negotiation allowed to restart with some login/retry timout? Questions mentioned has still remained questions to me. Can anyone clarify? regards, PS. reading PPP rfc, there are tons of PPP settings that are MUST be configurable. Are they? Is PPP implementation RFC compliant? ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------

Subject: (usr-tc) RED in ARCs or Netservers
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-09 20:11:56

Howdy, I was just listening to the Nanog 13 proceedings; Van Jacobsen's talk about Random Early Drop (RED) in was very interesting. Does anyone [from 3Com, or otherwise] know if there is support or plans for support of RED in the HARC routing code? (I haven't read the paper, but as I understand it, RED is used where a gateway is forwarding from a relatively fast source to a relatively slow link, e.g., from a T1 to a dialup line. The gateway has a queue of a finite size, and when that queue fills it has to trash some of the incoming data. RED makes it drop a packet here and a packet there, whereas typically packets are just lopped off the end of the queue. It improves link utilization and application performance significantly, and it's very easy to implement.) In the slides from that talk (under http://www.nanog.org/mtg-9806/agen0698.html) there are some graphs showing how RED improved utilization of the EBONE.

Subject: Re: (usr-tc) Per-User default routes
From: Brian <signal@shreve.net>
Date: 1998-10-09 22:48:49

On Fri, 9 Oct 1998, Dave Martin wrote: > We have a client who wishes to offer "filtered" connections to the > Internet. The product they wish to use (Bess, from www.n2h2.com) would > like to have filtered users directed toward their box when they connect. > The RADIUS dictionary provided with MERIT 3.6B basic has an entry: > > USR-IP-Default-Route-Option > > I haven't been able to find a reference to this in any of the USR > documentation. > > So, the $99 question: is there a way to set up RADIUS per-user default > routes with USR (specifically HiPerARC) equipment and does it involve the > use of the above RADIUS parameter? TIA... > I have been asking about this myself. Alot of NAS vendors support this. I had actually heard that VPN-Neighbor was the attribute on the USR hubs that allowed this functionality (both arc and netserver). But I keep hearing its not implemented yet. From some engineers I here its implemented but just not supported. If anyone knows of a way to setup a per user default route, that would be good info to know. You can build a L2TP or PPTP tunnel into the filter box, this would work great. Your filter box just needs to run an OS that supports one of those tunneling protocols. Our filter box (Xstop) runs BSDI, and I am not aware of a tunneling protocol that runs under FreeBSD/BSDI. Brian > > ------------------------------------------------------------------------ > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) ISDN: netserver vs modems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-10 09:53:02

Thus spake Leon McCalla >Is there an advantage to using the netserver to terminate ISDN calls instead >or the quadmodem or HDM? At this point, little to none. Originally the quad's couldn't handle terminating ISDN calls, so the netserver had to. That limitation is no longer there and the quad's handle it much better. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) terminal length on hiper
From: bryan s. blank <bryan@supernet.net>
Date: 1998-10-10 12:36:08

just stayed on hold with tech support for 30mins (yep, bought the contract), to find out that you can't change the line length of your terminal on the hiperarc lab-disco#conf t Enter configuration commands, one per line. End with CNTL/Z. lab-disco(config)#line vty 0 4 lab-disco(config-line)#length ? <0-512> Number of lines on screen (0 for no pausing) c'mon. this is nice stuff. cisco gets it right. it doesn't even to seem to catch telnet telling it about sigwinch from an xterm, makes writing stuff to list users with Net::Telnet not much fun. guess use snmp </whine> sorry, this box has bigger problems ... take it easy |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

Subject: Re: (usr-tc) terminal length on hiper
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-10 16:01:17

Yes you can change it login as admin and type show command that will show you setting available. Then you can do a set command gLOBAL_TERMINAL_SETTINGS_ROWS <1 - 256 > default is 23. 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 Sat, 10 Oct 1998, bryan s. blank wrote: > just stayed on hold with tech support for 30mins (yep, bought > the contract), to find out that you can't change the line length > of your terminal on the hiperarc > > lab-disco#conf t > Enter configuration commands, one per line. End with CNTL/Z. > lab-disco(config)#line vty 0 4 > lab-disco(config-line)#length ? > <0-512> Number of lines on screen (0 for no pausing) > > c'mon. this is nice stuff. cisco gets it right. it doesn't > even to seem to catch telnet telling it about sigwinch from an > xterm, makes writing stuff to list users with Net::Telnet not > much fun. guess use snmp > > </whine> sorry, this box has bigger problems ... > > take it easy > |o|----------------------------------------------------------------------|o| > |o| bryan s. blank (203)-351-1178 voice |o| > |o| senior systems analyst (203)-351-1186 fax |o| > |o| discovernet, incorporated (203)-979-5126 emerg |o| > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) terminal length on hiper
From: bryan s. blank <bryan@supernet.net>
Date: 1998-10-10 16:56:59

|o| Yes you can change it |o| |o| login as admin and type show command |o| |o| that will show you setting available. Then you can |o| do a |o| |o| set command gLOBAL_TERMINAL_SETTINGS_ROWS <1 - 256 > thank you very much, i appreciate it the people (3 of them) in tech support were convinced that is "part of the pilgrim and cannot be changed" ... thanks again! (btw, worked around it with some code from the cistron radiusd perl script for monitoring terminal servers) |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

Subject: Re: (usr-tc) ISDN: netserver vs modems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-11 01:42:33

An additional note concerning HiPer DSP's is they can not terminte ISDN calls on the NetServer. -----Original Message----- >Thus spake Leon McCalla >>Is there an advantage to using the netserver to terminate ISDN calls instead >>or the quadmodem or HDM? > >At this point, little to none. Originally the quad's couldn't handle >terminating ISDN calls, so the netserver had to. That limitation is no >longer there and the quad's handle it much better. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) ISDN: netserver vs modems
From: Leon McCalla <ascend@caribbeanlink.com>
Date: 1998-10-11 08:19:11

thanks to all that responded...

Subject: Re: (usr-tc) Per-User default routes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-11 08:36:35

Subject: Re: (usr-tc) Per-User default routes
From: Dave Martin <dpm@netcetera.com>
Date: 1998-10-11 12:37:11

> >What is the hex value or the Attribute number? > >krish >> USR.attr USR-IP-Default-Route-Option 38976 integer (1, 0) USR.value USR-IP-Default-Route-Option Enabled 1 USR.value USR-IP-Default-Route-Option Disabled 2 Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

Subject: (usr-tc) Web TV Help Needed
From: Russ Miescke <russm@powerweb.net>
Date: 1998-10-11 15:08:51

Arter reading about various problems for the past couple of weeks with Web TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load it anyway. Bad move. Now all my Web TV customers are having problems connecting. I think I saw there was an fix released for this, but do not know where to find it. Any help would be appreciated. Russ Miescke Power Web Connect russm@powerweb.net 920-885-7860

Subject: Re: (usr-tc) Web TV Help Needed
From: Russ Miescke <russm@powerweb.net>
Date: 1998-10-11 16:20:54

Someone was nice enough to send me the code. It worked great. Why is this not posted on their Total Service download site? Russ -----Original Message----- >Call USR support and request Hiper ARC ver. 4.1.78 >They send me a copy via email - but I have not install it :-(. > >Richard Lorbieski > >Russ Miescke wrote: >> >> Arter reading about various problems for the past couple of weeks with Web >> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load it >> anyway. Bad move. Now all my Web TV customers are having problems >> connecting. I think I saw there was an fix released for this, but do not >> know where to find it. Any help would be appreciated. >> >> Russ Miescke >> Power Web Connect >> russm@powerweb.net >> 920-885-7860 >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Per-User default routes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-11 19:40:58

I will get back to you on this. I need to find out if this is resevered for IEA or if its similar to Framed-route 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, 11 Oct 1998, Dave Martin wrote: > > > >What is the hex value or the Attribute number? > > > >krish > >> > > USR.attr USR-IP-Default-Route-Option 38976 integer (1, 0) > USR.value USR-IP-Default-Route-Option Enabled 1 > USR.value USR-IP-Default-Route-Option Disabled 2 > > ------------------------------------------------------------------------ > 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. >

Subject: (usr-tc) (USR-TC) HiperARC filters...
From: Ricky <rickyz@mindspring.com>
Date: 1998-10-11 20:59:48

Here is what the input filter "bess.in" on my HARC looks like: > > #filter > IP: > 001 AND src-addr = 208.198.5.0/24; > 011 REJECT dst-addr = 0.0.0.0/0; > > I think what this script should is look at request coming in from the > Class C 208.198.5.0 and reject any type of request anywhere (again I set > this up to see if filtering was indeed working). The only way I could get > this to work was right a filter called "bess.out" that look like this: > > #filter > IP: > 001 AND src-addr = 0.0.0.0/0; > 011 REJECT dst-addr = 208.198.5.0/24; > > If I apply this filter to input (bess.in) output (bess.out) it works - if > it is assigned to only in or out it does not. I have setup some other > filters that allow me have access to machines on my network that work but > again I have to use in/out filters. Ideally what I want to do is > something like this for an input filter: > > #filter > IP: > 001 AND tcp-dst-port = 80; <Web Requests> > 011 ACCEPT dst-addr = 206.137.233.0/24; <My core Class C> > 021 AND tcp-dst-port = 443; <SSL Web Requests> > 031 ACCEPT dst-addr = 206.137.233.0/24; <My core Class C> > ... > > <more tcp/udp based filtering will go here to allow access to AOL through > TCP/IP, FTP, POP3, etc> > > ... > > DENY; > > I want to be able to use the Radius directive Filter-Id = "bess.in" to > specify applying into to the input on the interface so I don't have > to create local users on the Chassis (this works fine with > Portmasters - not sure about HiperARC though). Shouldn't this work using just a .in filter specified? Thanks in advance, Ricky Access Unlimited America

Subject: Re: (usr-tc) What's meaning of ABCD?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-12 01:41:04

Actually, your ABCD bit status only applies to T1's. Additionally idle DS0's can have different ABCD bit status' than 0000. Sometimes you will = see them have 1010. The number of bits set up may vary from telco to telco. When a DS0's in use you should always see 1111. -----Original Message----- >Hi: > >Troubleshooting span for PSTN, use: > >span1>display atab > >Correct is 1011, but sometimes is other code. > >What infomation do the command will provide? > >I search for CD, it said(its mean is PRI): >Verify that ABCD Signaling on the >DS0s which sould be idle are idle >(0000) >ABCD Signaling should be "0000" for >all idle DS0s. > > > > >________________________________________________ >=BB=B6=D3=AD=C4=FA=CA=B9=D3=C3=B9=E3=D6=DD=CA=D3=B4=B0=C3=E2=B7=D1=B5=E7= =D7=D3=D3=CA=CF=E4http://www.163.net > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) HyperDSP code
From: Terry Kennedy <terry@olypen.com>
Date: 1998-10-12 09:31:47

What is 1.2.78? What does it fix? Is it availible to all or is it a eng release? Terry

Subject: RE: (usr-tc) (USR-TC) HiperARC filters...
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-12 09:57:32

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky |Sent: Sunday, October 11, 1998 8:00 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) (USR-TC) HiperARC filters... |Here is what the input filter "bess.in" on my HARC looks like: |> |> #filter |> IP: |> 001 AND src-addr = 208.198.5.0/24; |> 011 REJECT dst-addr = 0.0.0.0/0; The above rejects everything.. Since there is an implied DENY attached to all filters unless PERMIT is specified. |> I think what this script should is look at request coming in from the |> Class C 208.198.5.0 and reject any type of request anywhere (again I set |> this up to see if filtering was indeed working). The only way I could get |> this to work was right a filter called "bess.out" that look like this: |> |> #filter |> IP: |> 001 AND src-addr = 0.0.0.0/0; |> 011 REJECT dst-addr = 208.198.5.0/24; This rejects all traffic as well. What interface are you applying this to? User ,ETH ? |> If I apply this filter to input (bess.in) output (bess.out) it works - if |> it is assigned to only in or out it does not. I have setup some other |> filters that allow me have access to machines on my network that work but |> again I have to use in/out filters. Ideally what I want to do is |> something like this for an input filter: |> |> #filter |> IP: |> 001 AND tcp-dst-port = 80; <Web Requests> |> 011 ACCEPT dst-addr = 206.137.233.0/24; <My core Class C> |> 021 AND tcp-dst-port = 443; <SSL Web Requests> |> 031 ACCEPT dst-addr = 206.137.233.0/24; <My core Class C> |> ... |> |> <more tcp/udp based filtering will go here to allow access to AOL through |> TCP/IP, FTP, POP3, etc> |> |> ... |> |> DENY; |> |> I want to be able to use the Radius directive Filter-Id = "bess.in" to |> specify applying into to the input on the interface so I don't have |> to create local users on the Chassis (this works fine with |> Portmasters - not sure about HiperARC though). Shouldn't this work |using just a .in filter specified? | The above will work. Remember to set filter access on the modem interfaces to ON. Filters do nothing unless this is set. The filter should exist on the HARC as "bess.in" not as "bess". You can use the command "Show remote user <NAME>" to see if the filter has been applied to the logged in user. -M

Subject: (usr-tc) Jeff Hilliard email?
From: David Swearingin <david@carolnet.com>
Date: 1998-10-12 13:04:11

Does anyone know Jeff Hilliard's email address? He was a field technician for USR in January of this year. 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

Subject: Re: (usr-tc) xDSL, Has anyone done it?
From: Jack Singer <jsinger@usacars.com>
Date: 1998-10-12 13:31:01

We use USR TC and want to start offering DSL, has anyone used the total control units to offer DSL? If yes, what is involved from an end user. 3Com has not been able to get me any information as to what is actualy needed to do this. Jack Singer jsinger@i-c.net

Subject: (usr-tc) What's meaning of ABCD?
From: cntlxh@163.net
Date: 1998-10-12 14:03:10

Hi: Troubleshooting span for PSTN, use: span1>display atab Correct is 1011, but sometimes is other code. What infomation do the command will provide? I search for CD, it said(its mean is PRI): Verify that ABCD Signaling on the DS0s which sould be idle are idle (0000) ABCD Signaling should be "0000" for all idle DS0s. ________________________________________________ ��ӭ��ʹ�ù��Ӵ��ѵ��http://www.163.net

Subject: Re: (usr-tc) hangup problems ... still ...
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-12 14:08:36

I doubt Centrex has anything to do with it, though there is a remote possibility as they are sometimes provisioned differently (different levels). I highly suspect something to do with the location and line conditions. - What is the disconnect reason shown on the quads (or whatever modems you are using)? - Is there a disconnect reason readily available on the client end (in the modem, not in the PPP stack)? - Is x2/V.90 disabled in the quads. It should not matter, but just in case, ensure it is disabled (it simplifies things a bit). - When people do work fine, do they get good connect speeds? If you want, send me the POP phone number (and the number for one that works) in a private email, I can take a peek to see if anything is obviously amiss in line conditions. JP Jamin Cummings <jamin@computer-connection.net> on 10/12/98 01:21:35 PM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) for those of you who don't remember me from a little while ago ... here's a little recap ... back in march of 1998 ... we added eight more phone lines to one of our pops. the are just "normal" pots lines. ever since the phone company did that, our equipment (a total control enterprise hub) hangs up on our customers. the first time they dial in, "we" kick them out, and they get an error 629 - you've been disconnected by the host computer. then the second time they dial in, our equipment lets them in just fine. it doesn't matter what os the customers use ... and it doesn't seem to matter what kind of modems they use. our other sites are running the same software, with the same config (execpt for the ip addresses of course). i'm at wits end with this hangup problem ... i went to another site that works perfectly and stole the usr equipment from there. i brang it to the site with the hangup problem, and our customers still got hung-up on. i've had the phone company out here about three or four times last month checking everything. as far as thier equipment goes, they said that everything checks out just fine. they had some "specialist" come in from albany ... he couldn't find anything wrong either. we're located in ontario, new york. it's about 45 minutes east of rochester new york. it's right on the boarder of bell atlantics teritory. the only thing that i know for a fact that is different between here and our "working sites" is that this site uses some service from the phone company called centrix. supposadly it makes the phone lines cheaper per month for us. would this cause a problem? the bell atlantic techs that were here said that everything with that checked out fine. but i've learned from past experiences to take what they say with a grain of salt. any suggestions would really be apreciated. and just for the record ... the hangup problem acures about three seconds into the call. so there's not even time for any authenication stuff to be going on. so it's not as easy as something wrong with the radius box. it's defently the phone lines and/or config of the hub. thanks. c-ya! :-) - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) hangup problems ... still ...
From: Jamin Cummings <jamin@computer-connection.net>
Date: 1998-10-12 14:21:35

for those of you who don't remember me from a little while ago ... here's a little recap ... back in march of 1998 ... we added eight more phone lines to one of our pops. the are just "normal" pots lines. ever since the phone company did that, our equipment (a total control enterprise hub) hangs up on our customers. the first time they dial in, "we" kick them out, and they get an error 629 - you've been disconnected by the host computer. then the second time they dial in, our equipment lets them in just fine. it doesn't matter what os the customers use ... and it doesn't seem to matter what kind of modems they use. our other sites are running the same software, with the same config (execpt for the ip addresses of course). i'm at wits end with this hangup problem ... i went to another site that works perfectly and stole the usr equipment from there. i brang it to the site with the hangup problem, and our customers still got hung-up on. i've had the phone company out here about three or four times last month checking everything. as far as thier equipment goes, they said that everything checks out just fine. they had some "specialist" come in from albany ... he couldn't find anything wrong either. we're located in ontario, new york. it's about 45 minutes east of rochester new york. it's right on the boarder of bell atlantics teritory. the only thing that i know for a fact that is different between here and our "working sites" is that this site uses some service from the phone company called centrix. supposadly it makes the phone lines cheaper per month for us. would this cause a problem? the bell atlantic techs that were here said that everything with that checked out fine. but i've learned from past experiences to take what they say with a grain of salt. any suggestions would really be apreciated. and just for the record ... the hangup problem acures about three seconds into the call. so there's not even time for any authenication stuff to be going on. so it's not as easy as something wrong with the radius box. it's defently the phone lines and/or config of the hub. thanks. c-ya! :-)

Subject: Re: (usr-tc) (USR-TC) HiperARC filters...
From: Brian <signal@shreve.net>
Date: 1998-10-12 17:03:12

On Sun, 11 Oct 1998, Ricky wrote: > Here is what the input filter "bess.in" on my HARC looks like: Now you all are still relying on client side configuration for your customers to use bess right? And below you're just blocking any attempts to use otherwise. I would be real curious as to a way to use tunnelling or other options to just make the cache proxy their next hop. Brian > > > > #filter > > IP: > > 001 AND src-addr = 208.198.5.0/24; > > 011 REJECT dst-addr = 0.0.0.0/0; > > > > I think what this script should is look at request coming in from the > > Class C 208.198.5.0 and reject any type of request anywhere (again I set > > this up to see if filtering was indeed working). The only way I could get > > this to work was right a filter called "bess.out" that look like this: > > > > #filter > > IP: > > 001 AND src-addr = 0.0.0.0/0; > > 011 REJECT dst-addr = 208.198.5.0/24; > > > > If I apply this filter to input (bess.in) output (bess.out) it works - if > > it is assigned to only in or out it does not. I have setup some other > > filters that allow me have access to machines on my network that work but > > again I have to use in/out filters. Ideally what I want to do is > > something like this for an input filter: > > > > #filter > > IP: > > 001 AND tcp-dst-port = 80; <Web Requests> > > 011 ACCEPT dst-addr = 206.137.233.0/24; <My core Class C> > > 021 AND tcp-dst-port = 443; <SSL Web Requests> > > 031 ACCEPT dst-addr = 206.137.233.0/24; <My core Class C> > > ... > > > > <more tcp/udp based filtering will go here to allow access to AOL through > > TCP/IP, FTP, POP3, etc> > > > > ... > > > > DENY; > > > > I want to be able to use the Radius directive Filter-Id = "bess.in" to > > specify applying into to the input on the interface so I don't have > > to create local users on the Chassis (this works fine with > > Portmasters - not sure about HiperARC though). Shouldn't this work using just a .in filter specified? > > Thanks in advance, > > Ricky > Access Unlimited America > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Long authentication delay
From: MegaZone <megazone@megazone.org>
Date: 1998-10-12 17:11:41

Once upon a time Mark R. Lindsey shaped the electrons to say... >I occasionally hear from customers that it takes a long time to be >authenticated when they dial in to us. We're using Netservers, >primarily, and the RADIUS server itself shows no noticable latency >(as tested with the _auth command on an ARC). Most of these, of course, >are Windows 95 users. It isn't your end, it is their end. They probably have things like "log on to network" and.or "IPX" checked - so PPP is taking a long time to NAK it all. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: (usr-tc) Strangly!!BNC Connector question
From: cntlxh@163.net
Date: 1998-10-12 19:07:54

Hi: I use BNC Connector provided by 3COM. Very strangly, when I plugged BNC Connector without E1 Line in Hiper DSP NIC, Hiper DSP Cand status lamp diplay "green", which mean there are a correct E1 Line. But in fact I only plugged BNC Connector in Hiper DSP NIC. Do you experience such a situation? Best Regards. ________________________________________________ ��ӭ��ʹ�ù��Ӵ��ѵ��http://www.163.net

Subject: (usr-tc) Long authentication delay
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-12 19:17:06

Howdy, all. I occasionally hear from customers that it takes a long time to be authenticated when they dial in to us. We're using Netservers, primarily, and the RADIUS server itself shows no noticable latency (as tested with the _auth command on an ARC). Most of these, of course, are Windows 95 users. Has anyone else seen anything similar? Thanks.

Subject: Re: (usr-tc) Long authentication delay
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-12 21:44:41

I agree with the answer supplied by the previous message but I would add the following: I've seen this many times before. There are two common possibilities. 1. Your network is too busy or 2. The user reporting the problem is configuring his Dial up Networking differently from other users. a. The bottom line is the more a customer checks under his Dial up Networking the longer the negotiation is going to take. Especially if he checks Log on to Network. A less common possibility would concern the modem or the phone line the customer is using to dial in. If either have issues or if the modem does not handle error correction well data may need to be sent more than once for a sucessful authentication. -----Original Message----- >Once upon a time Mark R. Lindsey shaped the electrons to say... >>I occasionally hear from customers that it takes a long time to be >>authenticated when they dial in to us. We're using Netservers, >>primarily, and the RADIUS server itself shows no noticable latency >>(as tested with the _auth command on an ARC). Most of these, of course, >>are Windows 95 users. > >It isn't your end, it is their end. They probably have things like >"log on to network" and.or "IPX" checked - so PPP is taking a long time to >NAK it all. > >-MZ >-- ><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! > ==================================================================== > ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. > Three days of clues, news, and views from the industry's best and > brightest. http://www.ispf.com/ for information and registration. > ==================================================================== > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Long authentication delay
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-12 21:48:17

Thanks all for your replies. : I agree with the answer supplied by the previous message but I would add the : following: : : I've seen this many times before. There are two common possibilities. : 1. Your network is too busy or I'm not sure what I mean by that. Are you referring to the ethernet to which the Netserver is connected, or to the link between that network and the outside world, or to the link to the RADIUS server? : 2. The user reporting the problem is configuring his Dial up Networking : differently from other users. To be precise, I've heard it from many of our users, and I've personally observed it.

Subject: Re: (usr-tc) Long authentication delay
From: pferraro <pferraro@wna-linknet.com>
Date: 1998-10-12 22:46:32

Have them go into their tcpip and UNCHECK Logon to Network. This is used for Microsoft Network and causes an uneeded delays! Give it a try! It works! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ============================================================================== On Mon, 12 Oct 1998, Mark R. Lindsey wrote: > Howdy, all. > > I occasionally hear from customers that it takes a long time to be > authenticated when they dial in to us. We're using Netservers, > primarily, and the RADIUS server itself shows no noticable latency > (as tested with the _auth command on an ARC). Most of these, of course, > are Windows 95 users. > > Has anyone else seen anything similar? > > Thanks. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) xDSL, Has anyone done it?
From: Steve McConnell <stevem@magneto.emji.net>
Date: 1998-10-12 22:56:08

we are not serving ADSL at this point, but my rep told me the following: at this point 3Com is offering a 2 port ADSL card (~$900 for the cardset). This card enables you to BRIDGE not ROUTE over the ADSL line. There is another card that is supposed to be coming out in January time frame ( summer maybe ?) that will conform to a few more of the emerging standards and he expected these new cards to offer routable ADSL. He highly recommended that we wait till that new card comes out, as he felt we would be most disappointed with the limitations of the current offering. Because of this, and the fact that GTE only offers an ADSL-Frame solution, we are not yet offering ADSL, but plan to in the near future. That help any? steve Steve McConnell EMJ Internet mailto:stevem@emji.net http://www.emji.net 919-363-4441x126 919-363-4425 FAX > -----Original Message----- > From: Jack Singer [mailto:jsinger@usacars.com] > Sent: Monday, October 12, 1998 1:31 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) xDSL, Has anyone done it? > > > We use USR TC and want to start offering DSL, has anyone used > the total control > units to offer DSL? If yes, what is involved from an end > user. 3Com has not been > able to get me any information as to what is actualy needed > to do this. > > Jack Singer > jsinger@i-c.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Long authentication delay
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-12 23:05:47

I'm referring to the link to the RADIUS server. I've worked with customer's who have had routing issues to their RADIUS. Since there is no guaranteed delivery on authentication packets you sometimes see multiple requests for authentication in attempt to get a valid request for authentication to reach the RADIUS server. Most of the people I have found this to be an issue with had their RADIUS server several hops away and their backbone to it was almost 100% utilized. -----Original Message----- >Thanks all for your replies. > >: I agree with the answer supplied by the previous message but I would add the >: following: >: >: I've seen this many times before. There are two common possibilities. >: 1. Your network is too busy or > >I'm not sure what I mean by that. Are you referring to the ethernet >to which the Netserver is connected, or to the link between that network >and the outside world, or to the link to the RADIUS server? > >: 2. The user reporting the problem is configuring his Dial up Networking >: differently from other users. > >To be precise, I've heard it from many of our users, and I've personally >observed it. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Billing system
From: Richard Bosire <bosire@nairobi.africaonline.co.ke>
Date: 1998-10-13 08:17:15

Hi guys .. I am shopping around for a new billing system, I use radius accounting and authentication server.. Any one knows , a good billing systems that works, less headaches and it should deliver easily and ability to be customized .. TIA bosire

Subject: (usr-tc) RE: From 3Com Corporate ADSL
From: Steve McConnell <stevem@magneto.emji.net>
Date: 1998-10-13 09:25:39

> capabilities. The information presented to you by an > organization outside > 3Com was inaccurate. > My apologies. When I called my 3com rep (about two weeks ago), this is what I was told. I then questioned him 4 times about the bridge-Vs-route thing (as I had a hard time believing it) he was VERY adamant that he was correct and at this point it was a bridging only solution. I should have checked closer on the web page behind him. I am sorry for muddying the waters. steve Steve McConnell EMJ Internet mailto:stevem@emji.net http://www.emji.net 919-363-4441x126 919-363-4425 FAX > -----Original Message----- > From: Howard_Rubin@ne.3com.com [mailto:Howard_Rubin@ne.3com.com] > Sent: Tuesday, October 13, 1998 9:08 AM > To: jsinger@usacars.com > Cc: stevem@emji.net; jsinger@i-c.net; stevem@magneto.emji.net; > Ken_Capasso@ne.3com.com > Subject: From 3Com Corporate ADSL > > > > > > Dear Jack, > > On behalf of 3Com Corporation, I want to apologize for any > mis-information > you may have received on 3Com ADSL products and capabilities. > I recently > was copied on the follwing email regarding 3Com's ADSL products and > capabilities. The information presented to you by an > organization outside > 3Com was innacurate. > > 3Com maintains a complete ADSL website with complete details about our > existing products and their capabilities. Please feel free > to visit this > site at the URL http://www.3com.com/xdsl/. > > 3Com does have PCI and external router ADSL products today. > The information > you received about performance of both these products is completely > innacurate. > > I would be happy to provide you with accurate information > directly from the > 3Com ADSL development group. Please feel free to contact me > should you > wish to discuss these products in detail. > > Regards, > Howard A. Rubin > 3Com ADSL Technical Marketing > > > > > ----------------------- > > > Steve McConnell <stevem@magneto.emji.net> on 10/13/98 11:56:08 AM > > Please respond to usr-tc@lists.xmission.com > > To: "'usr-tc @lists.xmission.com'" <usr-tc@lists.xmission.com> > cc: (Dale Eliason/JP/3Com) > Subject: RE: (usr-tc) xDSL, Has anyone done it? > > > > > Note: Some recipients have been dropped due to syntax errors. > Please refer to the "$AdditionalHeaders" item for the > complete headers. > > > > we are not serving ADSL at this point, but my rep told me the > following: > > at this point 3Com is offering a 2 port ADSL card (~$900 for > the cardset). > This card enables you to BRIDGE not ROUTE over the ADSL line. There is > another card that is supposed to be coming out in January time frame ( > summer maybe ?) that will conform to a few more of the > emerging standards > and he expected these new cards to offer routable ADSL. He highly > recommended that we wait till that new card comes out, as he > felt we would > be most disappointed with the limitations of the current offering. > > Because of this, and the fact that GTE only offers an > ADSL-Frame solution, > we are not yet offering ADSL, but plan to in the near future. > > That help any? > > steve > > Steve McConnell EMJ Internet > mailto:stevem@emji.net http://www.emji.net > 919-363-4441x126 919-363-4425 FAX > > > > > -----Original Message----- > > From: Jack Singer [mailto:jsinger@usacars.com] > > Sent: Monday, October 12, 1998 1:31 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) xDSL, Has anyone done it? > > > > > > We use USR TC and want to start offering DSL, has anyone used > > the total control > > units to offer DSL? If yes, what is involved from an end > > user. 3Com has not been > > able to get me any information as to what is actualy needed > > to do this. > > > > Jack Singer > > jsinger@i-c.net > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old > messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > >

Subject: (usr-tc) any suggestions on new technology????
From: Jamin Cummings <jamin@computer-connection.net>
Date: 1998-10-13 09:46:50

we are a small but surly growing isp in upstate new york. all of our advertising has been word of month just to make sure we keep a good modem ratio. we are looking to expand out and take into acount newer technologies (such as cable modems, xDSL, etc.). i'd just like some suggestions on what to go with. here's some generic questions to get people thinking. 1.) if we went with xDSL, what would we need. equipment and "phone company" wise. (keep in mind were in a bad section of bell atlantic teritory) 2.) is there anyway to go with cable modems? or does the cable company pretty much have control of what goes over their cable? or isn't it worth the agrivation? 3.) there's talk of wireless service using radio waves just west of here. what would we need to do that kind of service? we are in the county with the cows and apples. so i think that xDSL distance limitations would kill us. also, we can't even offer 56k because bell atlantic won't run ISDN anywere near us (even though one of Xeroxs main locations is just west of us). they won't outragius amounts of money for ISDN. and it wouldn't even be a local call for our customers because it would be run from another section of the county. any suggestions would be appricated. thanks. c-ya! :-)

Subject: (usr-tc) Fast/slow busy - telco or equipment problem?
From: Brian Tackett <cym@acrux.net>
Date: 1998-10-13 09:48:46

All, We have a recurring problem which, to me, looks a lot like a problem with a DS0 in our hunt group. Currently, we have a pair of ISDN PRI's pulled in, terminated in a TC w/ 6 quad cards. Recently we've had problems where people will call, and get a busy (sometimes slow, sometimes fast) but them, after trying 5-10 times, get through. My initial gut feeling is that this is what happens: 1) One or more of the DS0's which are part of the hunt group (or whatever the terminology is for digital trunks) is bad in some way 2) Once the first (N) DS0s get calls, the (N+1)'th DS0, the bad one, becomes the first available and people get busies. 3) If someone gets the luck of the draw and dials in at the same time someone else is getting busied, they scoot past the bad DS0 and get an active connection The only other alternative is code problems, but we recently upgraded to the following versions: 5.10.9 modem code 3.0.2 PRI card code 3.7.24 Netserver (8mb) code 5.4.95 NMC code Any known issues with these version, or anyt houghts on whether I am way off track or not?

Subject: Re: (usr-tc) Fast/slow busy - telco or equipment problem?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-13 11:12:13

There's always known issues with each code. No one writes perfect code. However, there are no known issues that specifically pertain to the problem you are reporting. You could have a variety of different issues going on. Make sure the corresponding interfaces on the NetServer are A R P. Make sure the Line Interface Source under line Interface Options on the modems is set to PRITDM, save to nvram, reboot. If the problem continues call tech support 800-231-8770. The problem may be a simple one that requires personal attention by someone who knows their way around the chassis. Should be fairly easy to determine where the problem is coming from. By the way, you said you have a pair of PRI's terminating into 6 quads. I recommend purchasing another 6 quads or a HiPer DSP. If you are terminating all your ISDN calls on your NetServer I would reconsider and terminate them on modems. -----Original Message----- > >All, > > We have a recurring problem which, to me, looks a lot like a problem >with a DS0 in our hunt group. Currently, we have a pair of ISDN PRI's >pulled in, terminated in a TC w/ 6 quad cards. Recently we've had problems >where people will call, and get a busy (sometimes slow, sometimes fast) >but them, after trying 5-10 times, get through. > >My initial gut feeling is that this is what happens: > >1) One or more of the DS0's which are part of the hunt group (or whatever >the terminology is for digital trunks) is bad in some way > >2) Once the first (N) DS0s get calls, the (N+1)'th DS0, the bad one, >becomes the first available and people get busies. > >3) If someone gets the luck of the draw and dials in at the same time >someone else is getting busied, they scoot past the bad DS0 and get an >active connection > >The only other alternative is code problems, but we recently upgraded to >the following versions: > > 5.10.9 modem code > 3.0.2 PRI card code > 3.7.24 Netserver (8mb) code > 5.4.95 NMC code > >Any known issues with these version, or anyt houghts on whether I am way >off track or not? > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Billing system
From: Kingsley S. Grant <ksg@recorder.ca>
Date: 1998-10-13 12:31:27

Try ispone's billing system. After a lot of review of what is available we decided to go with them. The system is quite configurable and database driven using sql or Access. Also supports auto signup programs such as total internet. link http://www.ispone.com/Main.html King. Richard Bosire wrote: > Hi guys .. > > I am shopping around for a new billing system, I use radius accounting > and authentication server.. > > Any one knows , a good billing systems that works, less headaches and it > should deliver easily and ability to be customized .. > > TIA > > bosire > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- Kingsley S. Grant RipNET Manager RipNET Internet Services 31 Broad Street Brockville ON, Canada K6V 4T9 (613) 342-3946 work (613) 342-8672 fax (613) 340-1144 Cel (613) 923-2596 Res (613) 341-0882 Pager 1-888-509-6677 E-Mail mailto:ksg@recorder.ca

Subject: (usr-tc) Radiator vs. Cistron
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-13 12:59:20

Hi, We've ditched our plans of putting together a radius implementation of our own, and we're down to the two players above. The Radiator site is a bit slim and doesn't seem to have a full feature list, but it looks as though both products have the main features we need, namely stopping multiple logins and giving our tech support people finger/snmp access to the daemon to see who's on. The Radiator db logging seems like a nice feature, and I am a bit worried about the Cistron method of telnet-ing to the box to check logins. How does Radiator confirm multiple logins? Is perl a good solution to the problem? When running with db logging, how does it handle a shutdown that is not graceful? Thanks, Charles =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) any suggestions on new technology????
From: Raymond DeRoo <rainman@alphacon.org>
Date: 1998-10-13 13:14:56

>we are a small but surly growing isp in upstate new york. =20 Ah... home sweet home. >1.) if we went with xDSL, what would we need. equipment and "phone >company" wise. (keep in mind were in a bad section of bell atlantic >teritory) What? Your not in Ontairo Telephone 'ville... I guess that is just as well. But as you state later on, I doubt the xDSL is an option due to distance and the fact the barbed wire doesn't conduct data signals that well. :+) >2.) is there anyway to go with cable modems? or does the cable company >pretty much have control of what goes over their cable? or isn't it >worth the agrivation? Cable modes work well, if you can get the cable company to let you ont= o their network. Unless there is an indy near you, I think that you are in = a TCI serviced area. Good luck with that, they have their own service that they are rolling out so probably are not all that interested in outsiders= . =20 >3.) there's talk of wireless service using radio waves just west of >here. what would we need to do that kind of service? Ah... that would be E-Znet (www.eznet.net). Actually it is kind of a joint thing between E-Znet and CAI Wireless. As I currently work for a wireless cable modem provider in Chicago I know this area *very* well. E-Znet basically buys bandwidth (RF Specturm) from CAI Wireless who actually owns the rights to those freqs. E-Znet then uses a product made = by Hybrid System (www.hybrid.com) to convert IP -> RF then RF -> IP at the customer location. For return they use modem dialing into TC shelves (muc= h the same setup we use in our facilities). What would it take to do that? Quite a bit, the yearly spectrum lease = is not cheap. But a good transmitter will give about a 35mile radius to serv= e (note: that if that signal start to encroach into Canadian 'air space' yo= u have a whole new mess to deal with!) You also would need to greatly increase you staff to add RF engineers, etc. You would be much better off finding someone that had the bandwidth to space and to work a joint offering with them (as it is cost prohibited to buy spectrum and talent t= o manage it) >any suggestions would be appricated. thanks. c-ya! :-) If I can provide any more help drop me a line. =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -=3D> raymond <=3D- /-------------------------------------------------------------------- / Raymond DeRoo (RD89)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 voice: 1-708-482-2965 / rderoo@speedchoice.com=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 fax: 1-708-482-0376 / /=A0 "Doesn't matter how much we may know about some things, there /=A0=A0 will always be an expert around the corner who can teach us a /=A0=A0 thing or two about some other things."=20

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-10-13 14:46:38

Charles Sprickman writes... >We've ditched our plans of putting together a radius implementation of our >own, and we're down to the two players above. The Radiator site is a bit >slim and doesn't seem to have a full feature list, but it looks as though >both products have the main features we need, namely stopping multiple >logins and giving our tech support people finger/snmp access to the daemon >to see who's on. The stopping multiple logins is certainly a listed Radiator feature, however I don't feel confident enough in it to turn it on. It's something I'll be looking at this week. If Radiator has finger/snmp access, no one mentioned it to me. >The Radiator db logging seems like a nice feature, and I am a bit worried >about the Cistron method of telnet-ing to the box to check logins. The db logging code is very new. I'm running it, seems to work. >How does Radiator confirm multiple logins? It depends on the NAS platform. >Is perl a good solution to the problem? Radiator is great if you are going to modify the server. If you don't need to, or plan to infrequently, get something that is multi-threaded and written in C. >When running with db logging, how does it handle a shutdown that >is not graceful? Of the NAS or the radius server? -- Aaron Nabil

Subject: Re: (usr-tc) Per-User default routes
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-13 16:34:18

This option is similar to the option available for the local user set net user default ip deFAULT_ROUTE_OPTION This option under radius has the following vsa IP-Default-Route-Option 0x9840 integer This option is typically used for lan-to-lan routing wherein a HiPer arc dials into another arc or if you use frame-relay etc. If this option is enabled what happens is the dialin user now becomes the default route, for all connections. The default gateway is replaced by the user's dialin IP address. 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, 11 Oct 1998, Dave Martin wrote: > > > >What is the hex value or the Attribute number? > > > >krish > >> > > USR.attr USR-IP-Default-Route-Option 38976 integer (1, 0) > USR.value USR-IP-Default-Route-Option Enabled 1 > USR.value USR-IP-Default-Route-Option Disabled 2 > > ------------------------------------------------------------------------ > 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. >

Subject: Re: (usr-tc) Fast/slow busy - telco or equipment problem?
From: Brian Tackett <cym@acrux.net>
Date: 1998-10-13 17:48:43

On Tue, 13 Oct 1998, Brian K McIntire wrote: > There's always known issues with each code. No one writes perfect code. > However, there are no known issues that specifically pertain to the problem > you are reporting. You could have a variety of different issues going on. Obviously, known issues relating to this problem was my implicit meaning. > Make sure the corresponding interfaces on the NetServer are A R P. Make > sure the Line Interface Source under line Interface Options on the modems is > set to PRITDM, save to nvram, reboot. If the problem continues call tech I have the following...what's the significance of "I I P"? S14 A R P on 0.0.0.0 Login/Ne IDLE 15287 128115 S15 I I P on 0.0.0.0 Login/Ne IDLE 193 244 S16 I I P on 0.0.0.0 Login/Ne IDLE 2289 1240 S17 A R P on 0.0.0.0 Login/Ne IDLE 0 0 S18 A R P on 0.0.0.0 Login/Ne IDLE 4190 8806 > By the way, you said you have a pair of PRI's terminating into 6 quads. I > recommend purchasing another 6 quads or a HiPer DSP. If you are terminating > all your ISDN calls on your NetServer I would reconsider and terminate them > on modems. I misspoke. It's 12 cards, e.g 48 modems. Our dialup business is not a major one, so we've little interest in buying yet another NAS. As I understand it, both "voice" and ISDN calls are being handled by the dual-PRI card, which then passes them off appropriately to the quad cards.

Subject: Re: (usr-tc) Fast/slow busy - telco or equipment problem?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-13 18:59:56

>I have the following...what's the significance of "I I P"? >S14 A R P on 0.0.0.0 Login/Ne IDLE 15287 128115 >S15 I I P on 0.0.0.0 Login/Ne IDLE 193 244 >S16 I I P on 0.0.0.0 Login/Ne IDLE 2289 1240 >S17 A R P on 0.0.0.0 Login/Ne IDLE 0 0 >S18 A R P on 0.0.0.0 Login/Ne IDLE 4190 8806 The first "I" in I I P indicates the modem port on the NetServer is not active. The second I indicates the port is not synchronized with the corresponding modem Set modem s15-s16 active save all reset s15-s16 sh all If that doesn't get them to go ARP then do the following Reset the corresponding modem and repeat the above steps If that doesn't work then set modem s1-s100 inactive save all reset all set modem s5-s52 (S5-S52 assumes you modem startslot is set to 1) Type sh modem to find out what yours is set to save all reset all > >> By the way, you said you have a pair of PRI's terminating into 6 quads. I >> recommend purchasing another 6 quads or a HiPer DSP. If you are terminating >> all your ISDN calls on your NetServer I would reconsider and terminate them >> on modems. > >I misspoke. It's 12 cards, e.g 48 modems. > >Our dialup business is not a major one, so we've little interest in buying >yet another NAS. As I understand it, both "voice" and ISDN calls are being >handled by the dual-PRI card, which then passes them off appropriately to >the quad cards. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) xDSL, Has anyone done it?
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-13 19:30:01

: we are not serving ADSL at this point, but my rep told me the following: : : at this point 3Com is offering a 2 port ADSL card (~$900 for the cardset). : This card enables you to BRIDGE not ROUTE over the ADSL line. Ours [seems to] route. Or, at least, it doesn't work very well without a routing table. :) : There is another card that is supposed to be coming out in January : time frame ( summer maybe ?) that will conform to a few more of the : emerging standards and he expected these new cards to offer routable : ADSL. Correct me if I'm wrong, but I believe that ADSL is a layer-one standard; you can run anything you want to on top of it -- be that X.25, PPP, ethernet, Frame Relay, ATM, &c. BellSouth, for example, is rolling out ADSL using ATM. They get another ISP in the towns where they are rolling it out to connect into an ATM network, and then they sell the pipe with ATM PVCs to the ISP of the customer's choice. (So you're not stuck with BellSouth.net.) : . . . my rep told me the following: On a tangentially-related topic, does anyone have recommendations for a clueful salesperson of TC parts? I don't do the buying in my company, but I would like to know who you all can suggest.

Subject: Re: (usr-tc) Billing system
From: Richard Bosire <bosire@nairobi.africaonline.co.ke>
Date: 1998-10-13 19:49:20

Hi king Just checked out their site, (http://www.ispone.com/ispone_specs.html) , and I didnt find my equipment listed 3com usr netserver/16 .. I have an oracle (8.? ) , s/w , can it be used with it .. and I also need maintan/upgrade to /or run in parallel with my current billing system cheers bosire "Kingsley S. Grant" wrote: > Try ispone's billing system. After a lot of review of what is available we > decided to go with them. The system is quite configurable and database > driven using sql or Access. Also supports auto signup programs such as total > internet. > link http://www.ispone.com/Main.html > King. > > Richard Bosire wrote: > > > Hi guys .. > > > > I am shopping around for a new billing system, I use radius accounting > > and authentication server.. > > > > Any one knows , a good billing systems that works, less headaches and it > > should deliver easily and ability to be customized .. > > > > TIA > > > > bosire > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > -- > Kingsley S. Grant > RipNET Manager > RipNET Internet Services > 31 Broad Street > Brockville ON, Canada > K6V 4T9 > (613) 342-3946 work > (613) 342-8672 fax > (613) 340-1144 Cel > (613) 923-2596 Res > (613) 341-0882 Pager > 1-888-509-6677 > E-Mail mailto:ksg@recorder.ca > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-13 22:15:52

I'm trimming for brevity... On Wed, 14 Oct 1998, Mike McCauley wrote: > > The Radiator db logging seems like a nice feature, and I am a bit worried > > about the Cistron method of telnet-ing to the box to check logins. How > > does Radiator confirm multiple logins? Is perl a good solution to the > Radiator uses telnet, finger or snmp (depending on the type of NAS) to double > check apparent excessive multiple logins. Since most of our boxes are NetServer based, telnet would be the method used. Is everyone comfortable with this? Are there plans to make the connection persistent? > > problem? When running with db logging, how does it handle a shutdown that > > is not graceful? > You can specify multiple SQL servers. Radiator will fall back to a standby if > the current one becomes uncontactable. I'm sorry, I wasn't clear enough on this one. I was speaking of a shutdown/crash/reboot of the NAS. Does radiator pay attention to the "I've rebooted" signal from the NAS and clear it's list of who is online? Thanks again, Charles > -- > Mike McCauley mikem@open.com.au > Open System Consultants Pty. Ltd Unix, Motif, C++, WWW > 24 Bateman St Hampton, VIC 3188 Australia Consulting and development > Phone, Fax: +61 3 9598-0985 > http://www.open.com.au > > Radiator: the most portable, flexible and configurable RADIUS server anywhere > (SQL, proxy, DBM, files, LDAP, NIS+, password, Emerald, Platypus, > external, etc etc etc on Unix, Win95, NT) > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: (usr-tc) Using Warp 4 IAK w/TC
From: pferraro <pferraro@wna-linknet.com>
Date: 1998-10-13 22:52:47

Has anyone got a good script or setup for using Warp4.0 PPP Dial Other Provider to log into the TC hubs? I have worked for over a month and continue to get disconnected. Most of the time I get a unknown protocol error (80f)... I would guess that it has something to do with additional info passed to the IAK dialer after login. I do get both the default route and the assigned IP, but then just drops connection with the protocol error! Any help appreciated! ============================================================================== Phillip Ferraro WorldNet Access, Inc pferraro@wna-linknet.com Onslow County's PREMIER InterNet Service Voice (910) 346-0835 824 Gumbranch Square, Suite R3 FAX (910) 455-1933 Jacksonville, Nc 28540-6269 ==============================================================================

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Brian <signal@shreve.net>
Date: 1998-10-14 08:39:07

On Tue, 13 Oct 1998, Charles Sprickman wrote: > Hi, > > We've ditched our plans of putting together a radius implementation of our > own, and we're down to the two players above. The Radiator site is a bit > slim and doesn't seem to have a full feature list, but it looks as though > both products have the main features we need, namely stopping multiple > logins and giving our tech support people finger/snmp access to the daemon > to see who's on. I love Radiator and use it. But for the above tasks we use tsmon (www.tsmon.com). > > The Radiator db logging seems like a nice feature, and I am a bit worried > about the Cistron method of telnet-ing to the box to check logins. How > does Radiator confirm multiple logins? Is perl a good solution to the > problem? When running with db logging, how does it handle a shutdown that > is not graceful? > > 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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-14 09:02:14

> >When running with db logging, how does it handle a shutdown that > >is not graceful? > > Of the NAS or the radius server? I'd imagine he meant an ungraceful shutdown of the DB server - that's certainly where my concern would be - what does Radiator do when the logging server is down? Although unclean NAS shutdown would be interesting too - does Radiator handle the 'Accounting On' packets and use them to reset all sessions in the DB for users on the NAS that reset? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Mike McCauley <mikem@open.com.au>
Date: 1998-10-14 11:43:04

On Oct 13, 12:59pm, Charles Sprickman wrote: > Subject: (usr-tc) Radiator vs. Cistron > Hi, > > We've ditched our plans of putting together a radius implementation of our > own, and we're down to the two players above. The Radiator site is a bit > slim and doesn't seem to have a full feature list, but it looks as though > both products have the main features we need, namely stopping multiple > logins and giving our tech support people finger/snmp access to the daemon > to see who's on. Radiator supports a "who is online" database in DBM (SQL too in the next version), plus CGIs to view. > > The Radiator db logging seems like a nice feature, and I am a bit worried > about the Cistron method of telnet-ing to the box to check logins. How > does Radiator confirm multiple logins? Is perl a good solution to the Radiator uses telnet, finger or snmp (depending on the type of NAS) to double check apparent excessive multiple logins. > problem? When running with db logging, how does it handle a shutdown that > is not graceful? You can specify multiple SQL servers. Radiator will fall back to a standby if the current one becomes uncontactable. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia Consulting and development Phone, Fax: +61 3 9598-0985 http://www.open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere (SQL, proxy, DBM, files, LDAP, NIS+, password, Emerald, Platypus, external, etc etc etc on Unix, Win95, NT)

Subject: (usr-tc) Dial-back with x2 or V.90 using USRTC
From: Francis Fong <francisf@synergy-hk.com.hk>
Date: 1998-10-14 11:54:56

Did anyone has successfully connect with client modem at x2 or V.90 (connect at anything more than 33.6Kbps) during dial-back, i.e. the call is initiated from the Total Control (either T1 Card or Hiper DSP) and dial-back to Sportster or Coruier, etc? If yes, is there any difference in setting? Rgds, Francis

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Mike McCauley <mikem@open.com.au>
Date: 1998-10-14 11:54:59

On Oct 14, 9:02am, Bob Purdon wrote: > Subject: Re: (usr-tc) Radiator vs. Cistron > > > >When running with db logging, how does it handle a shutdown that > > >is not graceful? > > > > Of the NAS or the radius server? > > I'd imagine he meant an ungraceful shutdown of the DB server - that's > certainly where my concern would be - what does Radiator do when the > logging server is down? It falls back to (multiple) backup SQL servers. Flat file logging is independent and can continue irrespective of SQL. > > Although unclean NAS shutdown would be interesting too - does Radiator > handle the 'Accounting On' packets and use them to reset all sessions in > the DB for users on the NAS that reset? Yes it does. It handles all the known "im alive again" notifications. -- Mike McCauley mikem@open.com.au Open System Consultants Pty. Ltd Unix, Motif, C++, WWW 24 Bateman St Hampton, VIC 3188 Australia Consulting and development Phone, Fax: +61 3 9598-0985 http://www.open.com.au Radiator: the most portable, flexible and configurable RADIUS server anywhere (SQL, proxy, DBM, files, LDAP, NIS+, password, Emerald, Platypus, external, etc etc etc on Unix, Win95, NT)

Subject: (usr-tc) USR TotalSwitch SNMP (MRTG Graph)
From: TS Tsang <tstsang2@ipoline.com>
Date: 1998-10-14 12:15:11

Hi, I have problem in graphing the traffic from USR TotalSwitch. Have enabled snmp in the switch with correct community. Using cfgmaker, it can produces the mrtg.cfg file without problem. However, for all running of mrtg, it will only get 0 bytes, in fact , there should be traffic in most port. As I also monitor it's downlink which is a 3com switch and got the total traffic coming in/out from this switch. Any one have an idea of what's wrong and how to fix it? Thanks, Bosco.

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-14 13:20:29

I can't imagine why you were flipping dip switch 5 on (User Interface Require Carrier). Try flipping dip switch 3 on. Dip 3 will boot a non-defective HiPer ARC as fast as possible, bypassing all wait states: Good luck -----Original Message----- >OK, couple of things here... > >1) I have a demo HiPer Arc that I'm playing with...had 4.0.29 when I >got it, flashed it up to 4.1.11 (after much frustration)...still have >not found a solution to this...the thing takes something like 20 minutes >to boot! From the console the "Loading kernel ... OK" message displays >one letter at a time, approximately 45 seconds between each letter >showing up. > >Have tried: >2 different versions of code (4.0.29, 4.1.11), upgrading NMC to 5.5.5, >having HARC in different slots, having HARC in different *chassis*, boot >with dip switch 5 on, boot with dip switch 5 off, booted with netserver >in chassis with it and without netserver in chassis with it...nothing >else I can think to do. 3Com tech support is saying its likely a bad >card and that I should get a replacement for it...not exactly >encouraging to have the first card you ever get be bad. > >Any ideas here? > >2) With both versions 5.5.5 of the NMC code, and 4.1.11 of the HARC >code, neither card now will show anything on the console after booting >up, no menus, no login prompts, no password prompts, nothing. Is this a >new "feature" of the newer code revs that they no longer give you >console access? This could be problematic! Am I missing a config items >on the newer code to enable console access? What's the deal with this? > >Console terminal is 9600 8,n,1 in both cases, works fine with any and >all other usr equipment that I have with no changes in terminal config >(just unplug from the HARC of this specific NMC and plug it in to >another and hit return on the terminal brings up output from the card). > >Any ideas here? >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-14 13:32:38

Dip switch 5 on the NetServer does bypass the config and erase flash but dip 3 on the HiPer ARC is the one you use if you want to utilize the Engineering fastboot. If your curious later and have access to a working HiPer ARC try typing sh boa s from the command line of the HiPer ARC. You'll see some interesting information about your hardware. --Original Message----- >Thus spake Brian K McIntire >>I can't imagine why you were flipping dip switch 5 on (User Interface >>Require Carrier). Try flipping dip switch 3 on. Dip 3 will boot a >>non-defective HiPer ARC as fast as possible, bypassing all wait states: > >I was told that dip 5 bypassed the config (though it never seemed to >actually do so). FWIW. dip 5 on the netserver did bypass the config if >I remember correctly. > >>-----Original Message----- >>From: Jeff Mcadams <jeffm@iglou.com> >>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>Date: Wednesday, October 14, 1998 1:03 PM >>Subject: (usr-tc) couple of questions...playing with HARC > >>>OK, couple of things here... >>> >>>1) I have a demo HiPer Arc that I'm playing with...had 4.0.29 when I >>>got it, flashed it up to 4.1.11 (after much frustration)...still have >>>not found a solution to this...the thing takes something like 20 minutes >>>to boot! From the console the "Loading kernel ... OK" message displays >>>one letter at a time, approximately 45 seconds between each letter >>>showing up. >>> >>>Have tried: >>>2 different versions of code (4.0.29, 4.1.11), upgrading NMC to 5.5.5, >>>having HARC in different slots, having HARC in different *chassis*, boot >>>with dip switch 5 on, boot with dip switch 5 off, booted with netserver >>>in chassis with it and without netserver in chassis with it...nothing >>>else I can think to do. 3Com tech support is saying its likely a bad >>>card and that I should get a replacement for it...not exactly >>>encouraging to have the first card you ever get be bad. >>> >>>Any ideas here? >>> >>>2) With both versions 5.5.5 of the NMC code, and 4.1.11 of the HARC >>>code, neither card now will show anything on the console after booting >>>up, no menus, no login prompts, no password prompts, nothing. Is this a >>>new "feature" of the newer code revs that they no longer give you >>>console access? This could be problematic! Am I missing a config items >>>on the newer code to enable console access? What's the deal with this? >>> >>>Console terminal is 9600 8,n,1 in both cases, works fine with any and >>>all other usr equipment that I have with no changes in terminal config >>>(just unplug from the HARC of this specific NMC and plug it in to >>>another and hit return on the terminal brings up output from the card). >>> >>>Any ideas here? >>>-- >>>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 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) couple of questions...playing with HARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-14 13:58:27

OK, couple of things here... 1) I have a demo HiPer Arc that I'm playing with...had 4.0.29 when I got it, flashed it up to 4.1.11 (after much frustration)...still have not found a solution to this...the thing takes something like 20 minutes to boot! From the console the "Loading kernel ... OK" message displays one letter at a time, approximately 45 seconds between each letter showing up. Have tried: 2 different versions of code (4.0.29, 4.1.11), upgrading NMC to 5.5.5, having HARC in different slots, having HARC in different *chassis*, boot with dip switch 5 on, boot with dip switch 5 off, booted with netserver in chassis with it and without netserver in chassis with it...nothing else I can think to do. 3Com tech support is saying its likely a bad card and that I should get a replacement for it...not exactly encouraging to have the first card you ever get be bad. Any ideas here? 2) With both versions 5.5.5 of the NMC code, and 4.1.11 of the HARC code, neither card now will show anything on the console after booting up, no menus, no login prompts, no password prompts, nothing. Is this a new "feature" of the newer code revs that they no longer give you console access? This could be problematic! Am I missing a config items on the newer code to enable console access? What's the deal with this? Console terminal is 9600 8,n,1 in both cases, works fine with any and all other usr equipment that I have with no changes in terminal config (just unplug from the HARC of this specific NMC and plug it in to another and hit return on the terminal brings up output from the card). Any ideas here? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-14 14:07:07

-----Original Message----- >Jeff Mcadams was heard to say: >>1) I have a demo HiPer Arc that I'm playing with...had 4.0.29 when I >>got it, flashed it up to 4.1.11 (after much frustration)...still have >>not found a solution to this...the thing takes something like 20 minutes >>to boot! From the console the "Loading kernel ... OK" message displays >>one letter at a time, approximately 45 seconds between each letter >>showing up. > >replug the NIC and NAC. Make sure the NIC is secured to the chassis. If >it continues to act this way, reflash it via the NMC and when it reboots, >tell it to erase the configuration (from the boot PROM menu) > >>2) With both versions 5.5.5 of the NMC code, and 4.1.11 of the HARC >>code, neither card now will show anything on the console after booting >>up, no menus, no login prompts, no password prompts, nothing. Is this a >>new "feature" of the newer code revs that they no longer give you >>console access? This could be problematic! Am I missing a config items >>on the newer code to enable console access? What's the deal with this? > >See above. I've seen this happen before. > >3Com seems to be a little trigger happy on telling people to return the board. > >--Ricky > If all else fails verify your console cable is working by plugging it into other cards. ie HiPer DSP. Verify dips 1 & 2 on the NMC & HiPer ARC to make sure you are connecting at the right speed and try connecting at different speeds. You should have full console access for all your cards. By the way, if the NMC continues to not prompt you for a log in then pull out that nac and flip dip 5 on (restore nmc from default) and dip 6 (restore nmc snmp community strings from default) and reseat the card. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-14 14:17:14

Actually dip 5 on the netserver does not erase all netserver configurations. It most closely resembles the erase flash command from the netserver command line. -----Original Message----- >Jeff Mcadams was heard to say: >>I was told that dip 5 bypassed the config (though it never seemed to >>actually do so). FWIW. dip 5 on the netserver did bypass the config if >>I remember correctly. > >DIP5 on the HARC has a different meaning... "show board settings". > >DIP5 on the NetServer *erases* the configuration. > >--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. >

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-14 14:22:27

It's not the NMC code. At least it's not a bug that I have ever heard of. I have seen these problems with all versions of NMC code. The information I sent in the previus e-mail should remedy the problem -----Original Message----- >Thus spake Brian K McIntire >>If all else fails verify your console cable is working by plugging it into >>other cards. > >Already did that...can plug cable into any of a number of other cards >and it works fine. Have another NMC running 5.5.5, and it does the >same, just upgraded this NMC to 5.5.5, had console access before, >doesn't now. methinks its something with the 5.5.5 NMC code, don't know >about the HARC code since I don't have multiple of those to check with. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-14 14:24:31

Thus spake Brian K McIntire >I can't imagine why you were flipping dip switch 5 on (User Interface >Require Carrier). Try flipping dip switch 3 on. Dip 3 will boot a >non-defective HiPer ARC as fast as possible, bypassing all wait states: I was told that dip 5 bypassed the config (though it never seemed to actually do so). FWIW. dip 5 on the netserver did bypass the config if I remember correctly. >-----Original Message----- >From: Jeff Mcadams <jeffm@iglou.com> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Wednesday, October 14, 1998 1:03 PM >Subject: (usr-tc) couple of questions...playing with HARC >>OK, couple of things here... >> >>1) I have a demo HiPer Arc that I'm playing with...had 4.0.29 when I >>got it, flashed it up to 4.1.11 (after much frustration)...still have >>not found a solution to this...the thing takes something like 20 minutes >>to boot! From the console the "Loading kernel ... OK" message displays >>one letter at a time, approximately 45 seconds between each letter >>showing up. >> >>Have tried: >>2 different versions of code (4.0.29, 4.1.11), upgrading NMC to 5.5.5, >>having HARC in different slots, having HARC in different *chassis*, boot >>with dip switch 5 on, boot with dip switch 5 off, booted with netserver >>in chassis with it and without netserver in chassis with it...nothing >>else I can think to do. 3Com tech support is saying its likely a bad >>card and that I should get a replacement for it...not exactly >>encouraging to have the first card you ever get be bad. >> >>Any ideas here? >> >>2) With both versions 5.5.5 of the NMC code, and 4.1.11 of the HARC >>code, neither card now will show anything on the console after booting >>up, no menus, no login prompts, no password prompts, nothing. Is this a >>new "feature" of the newer code revs that they no longer give you >>console access? This could be problematic! Am I missing a config items >>on the newer code to enable console access? What's the deal with this? >> >>Console terminal is 9600 8,n,1 in both cases, works fine with any and >>all other usr equipment that I have with no changes in terminal config >>(just unplug from the HARC of this specific NMC and plug it in to >>another and hit return on the terminal brings up output from the card). >> >>Any ideas here? >>-- >>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

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Mike Wronski <mwronski@coredump.ae.usr.com>
Date: 1998-10-14 14:46:05

> Thus spake Brian K McIntire > >I can't imagine why you were flipping dip switch 5 on (User Interface > >Require Carrier). Try flipping dip switch 3 on. Dip 3 will boot a > >non-defective HiPer ARC as fast as possible, bypassing all wait states: > > I was told that dip 5 bypassed the config (though it never seemed to > actually do so). FWIW. dip 5 on the netserver did bypass the config if > I remember correctly. Dip 5 is for serial setup.. If you dont see anything after the Loading... Then you have dip 5 in the wrong position.. The slow part is a new one to me..

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-14 14:46:43

Thus spake Brian K McIntire >Dip switch 5 on the NetServer does bypass the config and erase flash but >dip 3 on the HiPer ARC is the one you use if you want to utilize the >Engineering fastboot. OK, tried it, and indeed, the sucker boots quickly now...question though...how long should the "Loading kernel ... OK" thing take? Like I said...it takes about 45 seconds between each letter with dip 3 off (with dip 3 on, the Boot Prom banner doesn't show up and the "Loading kernel ... OK" shows up almost immediately). Perhaps I just got a bum boot rom? Still not exactly encouraging, but I can live with that. >If your curious later and have access to a working HiPer ARC try typing sh >boa s from the command line of the HiPer ARC. You'll see some interesting >information about your hardware. Already found that. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-14 14:53:19

Jeff Mcadams was heard to say: >I was told that dip 5 bypassed the config (though it never seemed to >actually do so). FWIW. dip 5 on the netserver did bypass the config if >I remember correctly. DIP5 on the HARC has a different meaning... "show board settings". DIP5 on the NetServer *erases* the configuration. --Ricky

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-14 14:57:11

Jeff Mcadams was heard to say: >1) I have a demo HiPer Arc that I'm playing with...had 4.0.29 when I >got it, flashed it up to 4.1.11 (after much frustration)...still have >not found a solution to this...the thing takes something like 20 minutes >to boot! From the console the "Loading kernel ... OK" message displays >one letter at a time, approximately 45 seconds between each letter >showing up. replug the NIC and NAC. Make sure the NIC is secured to the chassis. If it continues to act this way, reflash it via the NMC and when it reboots, tell it to erase the configuration (from the boot PROM menu) >2) With both versions 5.5.5 of the NMC code, and 4.1.11 of the HARC >code, neither card now will show anything on the console after booting >up, no menus, no login prompts, no password prompts, nothing. Is this a >new "feature" of the newer code revs that they no longer give you >console access? This could be problematic! Am I missing a config items >on the newer code to enable console access? What's the deal with this? See above. I've seen this happen before. 3Com seems to be a little trigger happy on telling people to return the board. --Ricky

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-14 15:15:14

Thus spake Brian K McIntire >If all else fails verify your console cable is working by plugging it into >other cards. Already did that...can plug cable into any of a number of other cards and it works fine. Have another NMC running 5.5.5, and it does the same, just upgraded this NMC to 5.5.5, had console access before, doesn't now. methinks its something with the 5.5.5 NMC code, don't know about the HARC code since I don't have multiple of those to check with. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-14 15:23:31

On Wed, 14 Oct 1998, Jeff Mcadams wrote: > Thus spake Ricky Beam > >replug the NIC and NAC. > > Done. > > >Make sure the NIC is secured to the chassis. > > Done. > > >If it continues to act this way, reflash it via the NMC and when it reboots, > >tell it to erase the configuration (from the boot PROM menu) > > Part of the problem, I don't *get* the boot PROM menu. Remember the > loading sequence is "Loading kernel ... OK" some init stuff, then boot > menu. Last thing I get on the console is the "Loading kernel ... OK". > This indicates to me that, 1) the console cable is fine, 2) the card is > printing stuff to the console, and 3) that after "Loading kernel ... OK" > the card isn't printing anything else to the console. Again, this only > started when I flashed to 4.1.11, previous version was 4.0.29 and I had > console access with that version with no problem. Pull out the HiPer arc card. Put Dip switch 5 on the on position. Plug it back in. and when it boots up type go. krish > > >3Com seems to be a little trigger happy on telling people to return the board. > > I've always thought that...guess they think its easier just to replace > the board than to troubleshoot the actual problem and learn what issues > their customers are *really* running into. Meanwhile, we're stuck with > the problem still occuring, *and* we're down a board while they replace > it (which can sometimes be a long process). Then when we get the > replacement board we have to *continue* the troubleshooting process with > some number of days (or weeks?) blown already and the problem still > occuring. :/ > > Incidentally, Tatai or others that are interested, ticket number is > 109236, but there's nothing there more than what I've said here > (actually less since the tech's that I've talked to didn't get all the > info down that I told them apparently) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-14 15:25:43

Thus spake Ricky Beam >replug the NIC and NAC. Done. >Make sure the NIC is secured to the chassis. Done. >If it continues to act this way, reflash it via the NMC and when it reboots, >tell it to erase the configuration (from the boot PROM menu) Part of the problem, I don't *get* the boot PROM menu. Remember the loading sequence is "Loading kernel ... OK" some init stuff, then boot menu. Last thing I get on the console is the "Loading kernel ... OK". This indicates to me that, 1) the console cable is fine, 2) the card is printing stuff to the console, and 3) that after "Loading kernel ... OK" the card isn't printing anything else to the console. Again, this only started when I flashed to 4.1.11, previous version was 4.0.29 and I had console access with that version with no problem. >3Com seems to be a little trigger happy on telling people to return the board. I've always thought that...guess they think its easier just to replace the board than to troubleshoot the actual problem and learn what issues their customers are *really* running into. Meanwhile, we're stuck with the problem still occuring, *and* we're down a board while they replace it (which can sometimes be a long process). Then when we get the replacement board we have to *continue* the troubleshooting process with some number of days (or weeks?) blown already and the problem still occuring. :/ Incidentally, Tatai or others that are interested, ticket number is 109236, but there's nothing there more than what I've said here (actually less since the tech's that I've talked to didn't get all the info down that I told them apparently) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Multilink PPP on arc 4.1.11
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-14 15:55:54

what do you have your ppp receive_authentication set to? -----Original Message----- > >When a second channel tries to come up I get this when doing a monitor ppp >call events. Does anyone have any ideas on how I could fix this? I have it >working on one other harc but I can't find the problem. > >PPP Auth Failed, PAP Mismatch. PPP link down to . >PPP connection down to . > >Thanks > >-Dale > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) couple of questions...playing with HARC
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-14 16:05:07

Thus spake Mike Wronski >Dip 5 is for serial setup.. If you dont see anything after the Loading... >Then you have dip 5 in the wrong position.. The slow part is a new one to >me.. OK...flipping dip 5 to "off" did fix the no console after "Loading kernel ... OK". Apparently, with dip 5 "on" it looks for CD on the console port for data input and output...there for use with hooking a modem up to the console port I assume. I'm using a dumb terminal (wyse 60) so it wasn't giving CD...that's one thing fixed...still have the slow boot issue. I've tried pretty much everything everyone has suggested, but no solution as of yet...whatever is causing the slow boot is bypassed by flipping dip 3 to the "on" position and using the engineering fastboot. So, for 3Com engineers that are checking this out, that might give you something to go on. Again, the long delay occurs during the printing of "Loading kernel ... OK"...approximately 45 seconds between each character...so whatever the bootrom or image is doing during that time period is where I'd be looking first if I were checking this out. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Two Issues.
From: Frank Basso <frank@okwhatever.com>
Date: 1998-10-14 16:16:43

1. Dramatis should not be charged for Web Hosting, they host their ouwn site and they should only be charged for their ethernet connection. 2. Michael Maynard has an acount: CoolCS.com; this account was cancelled in January and is still being billed ? Thank you, -- Frank Basso Senior Network Engineer Got.Net? - The Internet Connection, Inc. Santa Cruz, California Voice: 831-460-2000 x117 FAX: 831-460-2004 When they took the fourth amendment, I was quiet because I didn't deal drugs. When they took the sixth amendment, I was quiet because I was innocent. When they took the second amendment, I was quiet because I didn't own a gun. Now they've taken the first amendment, and I can say nothing about it.

Subject: (usr-tc) Multilink PPP on arc 4.1.11
From: Dale Hege <fhege@sover.net>
Date: 1998-10-14 16:49:43

When a second channel tries to come up I get this when doing a monitor ppp call events. Does anyone have any ideas on how I could fix this? I have it working on one other harc but I can't find the problem. PPP Auth Failed, PAP Mismatch. PPP link down to . PPP connection down to . Thanks -Dale

Subject: (usr-tc) problems with LT1 win modems dialing up
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-14 17:19:36

This is a multi-part message in MIME format. ------=_NextPart_000_012F_01BDF796.D17B0F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've worked with many customer's who were having trouble with these = modems when I worked at 3COM in the ISP group. Through basic = troubleshooting I have always narrowed down the source of the issues to = the client modem. That's where our troubleshooting steps would normally = stop since we don't do tech support for LT1 win modems in the chasiss = group. I would appreciate input from anyone on this list who has = experienced connection and/or issues passing data with these modems when = dialing up to a Total Control Eneterprise Hub. I think I remeber someone saying turning off software compression = resolved one of the issues. Any feedback? Thank You=20 ------=_NextPart_000_012F_01BDF796.D17B0F60 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.3509.100"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>I've worked with many customer's who = were having=20 trouble with these modems when I worked at 3COM in the ISP group.  = Through=20 basic troubleshooting I have always narrowed down the source of the = issues to=20 the client modem.  That's where our troubleshooting steps would = normally=20 stop since we don't do tech support for LT1 win modems in the chasiss=20 group.  I would appreciate input from anyone on this list who has=20 experienced connection and/or issues passing data with these modems when = dialing=20 up to a Total Control Eneterprise Hub.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>I think I remeber someone saying = turning off=20 software compression resolved one of the issues.  Any=20 feedback?</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Thank = You </FONT></DIV></BODY></HTML> ------=_NextPart_000_012F_01BDF796.D17B0F60--

Subject: RE: (usr-tc) Web TV Help Needed
From: Eric Billeter <ebilleter@cableone.net>
Date: 1998-10-14 17:30:11

I figger it's because if they actually admitted there was a problem with their code ( and provided a simple way of resolving the problems ) that people would lose faith in the product. So their current solution is to hide any known problems from the end users (ISPs), and pawn off the problem somewhere else. I would bet that half the staff at 3com aren't aware of the software updates, and that the other half would probably have you either reset to factory defaults or return the card for replacement. I am currently on hold with them, and the wait time is approximately one hour. Somehow I don't see how they expect me to renew my service contracts with them at the prices I was just quoted. Roughly 25% of the replacement cost seems a little out of line. Either they have so little faith in the product or it costs them that much to support it and/or it fails so much that the replacement costs are that high. Either way it speaks loads for the product in question. They might consider moving on to a seperate segment of the industry. If anyone has the code in question.. it would be greatly appreciated. BTW I am CC ing this to both my reseller and salesperson at 3com. Eric T. Billeter Cable One Internet Engineer 1314 North 3rd Street ebilleter@cableone.net Phoenix, AZ 85004 (602) 364-6462 -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke Sent: Sunday, October 11, 1998 2:21 PM Someone was nice enough to send me the code. It worked great. Why is this not posted on their Total Service download site? Russ -----Original Message----- >Call USR support and request Hiper ARC ver. 4.1.78 >They send me a copy via email - but I have not install it :-(. > >Richard Lorbieski > >Russ Miescke wrote: >> >> Arter reading about various problems for the past couple of weeks with Web >> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load it >> anyway. Bad move. Now all my Web TV customers are having problems >> connecting. I think I saw there was an fix released for this, but do not >> know where to find it. Any help would be appreciated. >> >> Russ Miescke >> Power Web Connect >> russm@powerweb.net >> 920-885-7860 >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) SNMP Variable 4 monitoring logged in users?
From: Jack Singer <jsinger@usacars.com>
Date: 1998-10-14 17:41:08

Does anyone know of an SNMP variable that can be monitored on a netserver card that is equivalent to a "show sessions" from telnet? Thanks for the help. Jack Singer

Subject: Re: (usr-tc) SNMP Variable 4 monitoring logged in users?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-14 17:41:52

Thus spake Jack Singer >Does anyone know of an SNMP variable that can be monitored on a >netserver card that is equivalent to a "show sessions" from telnet? >Thanks for the help. Doesn't exist....Netserver cards only support MIB-II, and MIB-II doesn't have that information...sorry. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Web TV Help Needed
From: Eric Billeter <ebilleter@cableone.net>
Date: 1998-10-14 20:01:48

I feel for you .. I got 16 of the netserver 16i and 16i+ collecting dust. 3com won't give me any sort of credit for them but they did give me new boxes and manuals for them. Let me know if you know any one who wants em. I've heard cisco gives 250 per port..so 16 units at 16 ports each is $64000. Hey.. they even have cable modem products too! 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 Brian Gordon Sent: Wednesday, October 14, 1998 7:47 PM Cc: Lou Paris; Internet Technicians I don't know why its not posted on the Web Site. I was like the first one that found that WEB TV problem. I remember that Monday morning getting a notice that the code was out and I upgraded like at 8:00 am. Next thing I knew, I had like 50 Web TV people calling in..three days later a fix came out for it, and they emailed it to me. This should have been posted to their web site ASAP! I am having similar unresolved issues with my Netserver 16 V.34+ in one of my small pops ,(Modems not resetting properly..hanging... etc. of course there is always some emergency release code that is suppose to fix it all.) I guess they are going to stop supporting that unit also. I just want to trade it in or something, its a piece of garbage. -----Original Message----- (E-mail) <Usman_Malik@mw.3com.com>; Kevin_musseau@3com.com <Kevin_musseau@3com.com>; paul_mudlaff@mw.3com.com <paul_mudlaff@mw.3com.com> >I figger it's because if they actually admitted there was a >problem with their code ( and provided a simple way of resolving >the problems ) that people would lose faith in the product. So >their current solution is to hide any known problems from the end >users (ISPs), and pawn off the problem somewhere else. I would >bet that half the staff at 3com aren't aware of the software >updates, and that the other half would probably have you either >reset to factory defaults or return the card for replacement. > >I am currently on hold with them, and the wait time is approximately >one hour. Somehow I don't see how they expect me to renew my service >contracts with them at the prices I was just quoted. Roughly 25% of >the replacement cost seems a little out of line. Either they have so >little faith in the product or it costs them that much to support it >and/or it fails so much that the replacement costs are that high. Either >way it speaks loads for the product in question. They might consider >moving on to a seperate segment of the industry. > >If anyone has the code in question.. it would be greatly appreciated. > >BTW I am CC ing this to both my reseller and salesperson at 3com. > > >Eric T. Billeter Cable One >Internet Engineer 1314 North 3rd Street >ebilleter@cableone.net Phoenix, AZ 85004 >(602) 364-6462 > > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke >Sent: Sunday, October 11, 1998 2:21 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Web TV Help Needed > > >Someone was nice enough to send me the code. It worked great. Why is this >not posted on their Total Service download site? > >Russ > >-----Original Message----- >From: Richard Lorbieski <richard@mail.alpha1.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Friday, October 09, 1998 3:38 PM >Subject: Re: (usr-tc) Web TV Help Needed > > >>Call USR support and request Hiper ARC ver. 4.1.78 >>They send me a copy via email - but I have not install it :-(. >> >>Richard Lorbieski >> >>Russ Miescke wrote: >>> >>> Arter reading about various problems for the past couple of weeks with >Web >>> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load >it >>> anyway. Bad move. Now all my Web TV customers are having problems >>> connecting. I think I saw there was an fix released for this, but do not >>> know where to find it. Any help would be appreciated. >>> >>> Russ Miescke >>> Power Web Connect >>> russm@powerweb.net >>> 920-885-7860 >>> >>> - >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) found a bug in Quick Setup on harc
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-14 20:16:53

Found a bug in the HARC code...was present in both versions that I played with (4.0.29 and 4.1.11). Seems to be an off by one bug. In Quick Setup, I was setting up the network for the HARC, its IP number was to be 204.255.238.10, it didn't accept the 255 portion of the address. Only way I could get it to take it was to use 204.254.238.10 (which of course is not one of our addresses, so I had to go back and fix it later). Not of *huge* concern as the set network command takes it with no problem, but causes some problems for folks using Quick Setup. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Long authentication delay
From: Barry Henderson <net_microsurgeon@hotmail.com>
Date: 1998-10-14 20:30:53

The _auth command is a ineffective way to test latency during authentication as it does not negotiate any protocols whatsoever. It only does a name/password lookup >From owner-usr-tc@lists.xmission.com Wed Oct 14 20:11:07 1998 >Received: from domo by lists.xmission.com with local (Exim 2.04 #1) > id 0zSrCw-0000aV-00 > for usr-tc-goout@lists.xmission.com; Mon, 12 Oct 1998 17:16:54 -0600 >Received: from [204.252.164.2] (helo=vielle.datasys.net ident=mark) > by lists.xmission.com with esmtp (Exim 2.04 #1) > id 0zSrCt-0000aQ-00 > for usr-tc@lists.xmission.com; Mon, 12 Oct 1998 17:16:51 -0600 >Received: (from mark@localhost) > by vielle.datasys.net (8.9.1/8.9.1) id TAA25338 > for usr-tc@lists.xmission.com; Mon, 12 Oct 1998 19:17:07 -0400 >Message-Id: <199810122317.TAA25338@vielle.datasys.net> >From: mark@vielle.datasys.net (Mark R. Lindsey) >Date: Mon, 12 Oct 1998 19:17:06 -0400 >X-Pgp-Fingerprint: DB 6B 9E 9F B5 F2 9B 6D A0 BE D8 10 6B 22 8F 06 >X-Tom-Swiftie: Pretend we were in the days before railways, Tom coached. >X-Mailer: Mail User's Shell (7.2.6 1995-03-03) >To: usr-tc@lists.xmission.com >Subject: (usr-tc) Long authentication delay >Sender: owner-usr-tc@lists.xmission.com >Precedence: bulk >Reply-To: usr-tc@lists.xmission.com > >Howdy, all. > >I occasionally hear from customers that it takes a long time to be >authenticated when they dial in to us. We're using Netservers, >primarily, and the RADIUS server itself shows no noticable latency >(as tested with the _auth command on an ARC). Most of these, of course, >are Windows 95 users. > >Has anyone else seen anything similar? > >Thanks. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

Subject: RE: (usr-tc) Web TV Help Needed
From: Barry Henderson <net_microsurgeon@hotmail.com>
Date: 1998-10-14 20:55:38

I disagree with some of what you said. I have to admit the average skill level of the technicians at 3COM have been steadily declining since mid last year. In fact, now that Brian McIntire has left I'm hanging up if anyone other than Ron Childs picks up. I'm tired of training technicians as I work with them. I once called in for tech support on a known bug. Before I was done I had talked to 7 technicians and spent more than half a day on the phone. Then I called in and spoke to Ron Childs. He knew the answer right away. When I called in about something else I spoke to Brian about my old problem. Before I could finsish he told me he had heard of it before and had told Ron the fix. Are these two techs the only ones that have any idea how to get answers? Whats going on? Why don't they send their people through an intensive training/certification program before letting them embarass themselves in front of customers. If key technicians are jumping ship like rats on a sinking barge you have to wonder what's going on. >I figger it's because if they actually admitted there was a >problem with their code ( and provided a simple way of resolving >the problems ) that people would lose faith in the product. So >their current solution is to hide any known problems from the end >users (ISPs), and pawn off the problem somewhere else. I would >bet that half the staff at 3com aren't aware of the software >updates, and that the other half would probably have you either >reset to factory defaults or return the card for replacement. > >I am currently on hold with them, and the wait time is approximately >one hour. Somehow I don't see how they expect me to renew my service >contracts with them at the prices I was just quoted. Roughly 25% of >the replacement cost seems a little out of line. Either they have so >little faith in the product or it costs them that much to support it >and/or it fails so much that the replacement costs are that high. Either >way it speaks loads for the product in question. They might consider >moving on to a seperate segment of the industry. > >If anyone has the code in question.. it would be greatly appreciated. > >BTW I am CC ing this to both my reseller and salesperson at 3com. > > >Eric T. Billeter Cable One >Internet Engineer 1314 North 3rd Street >ebilleter@cableone.net Phoenix, AZ 85004 >(602) 364-6462 > > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke >Sent: Sunday, October 11, 1998 2:21 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Web TV Help Needed > > >Someone was nice enough to send me the code. It worked great. Why is this >not posted on their Total Service download site? > >Russ > >-----Original Message----- >From: Richard Lorbieski <richard@mail.alpha1.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Friday, October 09, 1998 3:38 PM >Subject: Re: (usr-tc) Web TV Help Needed > > >>Call USR support and request Hiper ARC ver. 4.1.78 >>They send me a copy via email - but I have not install it :-(. >> >>Richard Lorbieski >> >>Russ Miescke wrote: >>> >>> Arter reading about various problems for the past couple of weeks with >Web >>> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load >it >>> anyway. Bad move. Now all my Web TV customers are having problems >>> connecting. I think I saw there was an fix released for this, but do not >>> know where to find it. Any help would be appreciated. >>> >>> Russ Miescke >>> Power Web Connect >>> russm@powerweb.net >>> 920-885-7860 ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com

Subject: Re: (usr-tc) Multilink PPP on arc 4.1.11
From: Dale Hege <fhege@sover.net>
Date: 1998-10-14 21:23:00

I've tried pap and defualt. -Dale On Wed, 14 Oct 1998, Brian K McIntire wrote: > Date: Wed, 14 Oct 1998 15:55:54 -0500 > From: Brian K McIntire <bmcintire@commnet.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Multilink PPP on arc 4.1.11 > > what do you have your ppp receive_authentication set to? > -----Original Message----- > From: Dale Hege <fhege@sover.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, October 14, 1998 3:49 PM > Subject: (usr-tc) Multilink PPP on arc 4.1.11 > > > > > >When a second channel tries to come up I get this when doing a monitor ppp > >call events. Does anyone have any ideas on how I could fix this? I have it > >working on one other harc but I can't find the problem. > > > >PPP Auth Failed, PAP Mismatch. PPP link down to . > >PPP connection down to . > > > >Thanks > > > >-Dale > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Web TV Help Needed
From: Brian Gordon <administrator@westelcom.com>
Date: 1998-10-14 22:47:28

I don't know why its not posted on the Web Site. I was like the first one that found that WEB TV problem. I remember that Monday morning getting a notice that the code was out and I upgraded like at 8:00 am. Next thing I knew, I had like 50 Web TV people calling in..three days later a fix came out for it, and they emailed it to me. This should have been posted to their web site ASAP! I am having similar unresolved issues with my Netserver 16 V.34+ in one of my small pops ,(Modems not resetting properly..hanging... etc. of course there is always some emergency release code that is suppose to fix it all.) I guess they are going to stop supporting that unit also. I just want to trade it in or something, its a piece of garbage. -----Original Message----- (E-mail) <Usman_Malik@mw.3com.com>; Kevin_musseau@3com.com <Kevin_musseau@3com.com>; paul_mudlaff@mw.3com.com <paul_mudlaff@mw.3com.com> >I figger it's because if they actually admitted there was a >problem with their code ( and provided a simple way of resolving >the problems ) that people would lose faith in the product. So >their current solution is to hide any known problems from the end >users (ISPs), and pawn off the problem somewhere else. I would >bet that half the staff at 3com aren't aware of the software >updates, and that the other half would probably have you either >reset to factory defaults or return the card for replacement. > >I am currently on hold with them, and the wait time is approximately >one hour. Somehow I don't see how they expect me to renew my service >contracts with them at the prices I was just quoted. Roughly 25% of >the replacement cost seems a little out of line. Either they have so >little faith in the product or it costs them that much to support it >and/or it fails so much that the replacement costs are that high. Either >way it speaks loads for the product in question. They might consider >moving on to a seperate segment of the industry. > >If anyone has the code in question.. it would be greatly appreciated. > >BTW I am CC ing this to both my reseller and salesperson at 3com. > > >Eric T. Billeter Cable One >Internet Engineer 1314 North 3rd Street >ebilleter@cableone.net Phoenix, AZ 85004 >(602) 364-6462 > > >-----Original Message----- >From: owner-usr-tc@lists.xmission.com >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke >Sent: Sunday, October 11, 1998 2:21 PM >To: usr-tc@lists.xmission.com >Subject: Re: (usr-tc) Web TV Help Needed > > >Someone was nice enough to send me the code. It worked great. Why is this >not posted on their Total Service download site? > >Russ > >-----Original Message----- >From: Richard Lorbieski <richard@mail.alpha1.net> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Friday, October 09, 1998 3:38 PM >Subject: Re: (usr-tc) Web TV Help Needed > > >>Call USR support and request Hiper ARC ver. 4.1.78 >>They send me a copy via email - but I have not install it :-(. >> >>Richard Lorbieski >> >>Russ Miescke wrote: >>> >>> Arter reading about various problems for the past couple of weeks with >Web >>> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load >it >>> anyway. Bad move. Now all my Web TV customers are having problems >>> connecting. I think I saw there was an fix released for this, but do not >>> know where to find it. Any help would be appreciated. >>> >>> Russ Miescke >>> Power Web Connect >>> russm@powerweb.net >>> 920-885-7860 >>> >>> - >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Long authentication delay
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-14 23:58:48

: The _auth command is a ineffective way to test latency during : authentication as it does not negotiate any protocols whatsoever. It : only does a name/password lookup To be precise, I don't believe that authentication -- that job performed using the RADIUS protocol proper -- involves any sort of negotiation of protocols, except for the layers required for that protocol. It may be a poor test of overall latency of an initial connection for a user of a given software package, but it is a test of the communication between the NASsen and the RADIUS server. And my goal, in using it, was to determine whether that part was introducing a large delay. (Incidentally, I have noticed that when the RADIUS daemon is running at a high nicelevel (that's a low priority, for those of you of a non-Unix ilk) there is a noticable increase in the delay.)

Subject: Re: (usr-tc) any suggestions on new technology????
From: MegaZone <megazone@megazone.org>
Date: 1998-10-15 00:41:58

Once upon a time Jamin Cummings shaped the electrons to say... >1.) if we went with xDSL, what would we need. equipment and "phone >company" wise. (keep in mind were in a bad section of bell atlantic To start with you need direct access to the copper. Are you a CLEC? If not, you won't get it. To do xDSL you either need to be a LEC or OEM from one. >2.) is there anyway to go with cable modems? or does the cable company >pretty much have control of what goes over their cable? or isn't it The cable company has control. Some MAY let you OEM over their network, but I have yet to hear of it. >3.) there's talk of wireless service using radio waves just west of >here. what would we need to do that kind of service? That's probably one of the new digital packet radio systems the FCC licensed bandwith for a while back. If you didn't get a licences (we're talking millions) you can'd do it. >distance limitations would kill us. also, we can't even offer 56k >because bell atlantic won't run ISDN anywere near us (even though one of >Xeroxs main locations is just west of us). they won't outragius amounts You don't need ISDN for PCM modems - CT1 will do. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) Radiator vs. Cistron
From: MegaZone <megazone@megazone.org>
Date: 1998-10-15 00:45:47

Once upon a time Charles Sprickman shaped the electrons to say... >Since most of our boxes are NetServer based, telnet would be the method >used. Is everyone comfortable with this? Are there plans to make the >connection persistent? well, you could peek at the Lucent RABU Enterprise MIB for the OID used to check on users and RFE 3Com to do something similar on their gear so that SNMP can be used. It really is the nicest way to handle it. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-15 06:54:25

Thus spake MegaZone >Once upon a time Charles Sprickman shaped the electrons to say... >>Since most of our boxes are NetServer based, telnet would be the method >>used. Is everyone comfortable with this? Are there plans to make the >>connection persistent? >well, you could peek at the Lucent RABU Enterprise MIB for the OID used >to check on users and RFE 3Com to do something similar on their gear so >that SNMP can be used. It really is the nicest way to handle it. Since 3Com is loosing access to the source code to the netserver 3.x.x code (ComOS based) on Dec. 31st, significant improvements will not be made. Only changes at this point will be bug fixes. I *am* hearing rumours (nothing solid, purely rumours) that Lucent's big mondo data networking acquisition that they've been talking about might be 3Com. In which case, the source code issue goes away and development could continue...will it continue? dunno, but it could. Heck, there's no solid evidence of who Lucent is going to acquire at all (or even that its *really* going to happen...they've said a few months ago they were planning it, but haven't heard anything yet about it)... Anyway...enough stock analysis.... -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-15 08:16:19

I seriously doubt work would continue on the NETServer in any case. It's the 386 of computers. It's outdated. Obsolete. The HiPer ARC is a much better product. Rumor has it there's is going to be an even better deal offerred to people to trade their NETServer's for one. Time to move on. -----Original Message----- >Thus spake MegaZone >>Once upon a time Charles Sprickman shaped the electrons to say... >>>Since most of our boxes are NetServer based, telnet would be the method >>>used. Is everyone comfortable with this? Are there plans to make the >>>connection persistent? > >>well, you could peek at the Lucent RABU Enterprise MIB for the OID used >>to check on users and RFE 3Com to do something similar on their gear so >>that SNMP can be used. It really is the nicest way to handle it. > >Since 3Com is loosing access to the source code to the netserver 3.x.x >code (ComOS based) on Dec. 31st, significant improvements will not be >made. Only changes at this point will be bug fixes. I *am* hearing >rumours (nothing solid, purely rumours) that Lucent's big mondo data >networking acquisition that they've been talking about might be 3Com. >In which case, the source code issue goes away and development could >continue...will it continue? dunno, but it could. Heck, there's no >solid evidence of who Lucent is going to acquire at all (or even that >its *really* going to happen...they've said a few months ago they were >planning it, but haven't heard anything yet about it)... > >Anyway...enough stock analysis.... >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) found a bug in Quick Setup on harc
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-15 08:24:15

On Wed, 14 Oct 1998, Jeff Mcadams wrote: > Found a bug in the HARC code...was present in both versions that I > played with (4.0.29 and 4.1.11). > > Seems to be an off by one bug. > > In Quick Setup, I was setting up the network for the HARC, its IP number > was to be 204.255.238.10, it didn't accept the 255 portion of the > address. Only way I could get it to take it was to use 204.254.238.10 > (which of course is not one of our addresses, so I had to go back and > fix it later). Not of *huge* concern as the set network command takes > it with no problem, but causes some problems for folks using Quick > Setup. Quick setup does have this problem. We know about this and we are in the process of fixing it. Earlier in 4.0.29 and below code this problem was real - in the sense both Quicksetup and CLI would not take an address with 255 in the IP address. 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. >

Subject: Re: (usr-tc) Web TV Help Needed
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-15 08:52:58

On Wed, 14 Oct 1998, Brian Gordon wrote: > I don't know why its not posted on the Web Site. I was like the first one > that found that WEB TV problem. I remember that Monday morning getting a > notice that the code was out and I upgraded like at 8:00 am. Next thing I > knew, I had like 50 Web TV people calling in..three days later a fix came > out for it, and they emailed it to me. This should have been posted to > their web site ASAP! > The WebTV fix code 4.1.78-4 for the HiPer arc is currently available only if you call support. There is a reason for this. This code as some of you in this list have stated does have some problem with accounting packets, and some have even reported problems with ISDN. Most of others who are using this code did not have any problems to report. We would have posted this code on the site if this code had all the fixes. Currently you can get this code - just open a ticket with support. We are in the process of getting these fixes rolled into a service release which should be on the web site soon. krish > I am having similar unresolved issues with my Netserver 16 V.34+ in one of > my small pops ,(Modems not resetting properly..hanging... etc. of course > there is always some emergency release code that is suppose to fix it all.) > I guess they are going to stop supporting that unit also. I just want to > trade it in or something, its a piece of garbage. > > -----Original Message----- > From: Eric Billeter <ebilleter@cableone.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>; Todd Starkey > (E-mail) <Usman_Malik@mw.3com.com>; Kevin_musseau@3com.com > <Kevin_musseau@3com.com>; paul_mudlaff@mw.3com.com > <paul_mudlaff@mw.3com.com> > Date: Wednesday, October 14, 1998 8:38 PM > Subject: RE: (usr-tc) Web TV Help Needed > > > >I figger it's because if they actually admitted there was a > >problem with their code ( and provided a simple way of resolving > >the problems ) that people would lose faith in the product. So > >their current solution is to hide any known problems from the end > >users (ISPs), and pawn off the problem somewhere else. I would > >bet that half the staff at 3com aren't aware of the software > >updates, and that the other half would probably have you either > >reset to factory defaults or return the card for replacement. > > > >I am currently on hold with them, and the wait time is approximately > >one hour. Somehow I don't see how they expect me to renew my service > >contracts with them at the prices I was just quoted. Roughly 25% of > >the replacement cost seems a little out of line. Either they have so > >little faith in the product or it costs them that much to support it > >and/or it fails so much that the replacement costs are that high. Either > >way it speaks loads for the product in question. They might consider > >moving on to a seperate segment of the industry. > > > >If anyone has the code in question.. it would be greatly appreciated. > > > >BTW I am CC ing this to both my reseller and salesperson at 3com. > > > > > >Eric T. Billeter Cable One > >Internet Engineer 1314 North 3rd Street > >ebilleter@cableone.net Phoenix, AZ 85004 > >(602) 364-6462 > > > > > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > >Sent: Sunday, October 11, 1998 2:21 PM > >To: usr-tc@lists.xmission.com > >Subject: Re: (usr-tc) Web TV Help Needed > > > > > >Someone was nice enough to send me the code. It worked great. Why is this > >not posted on their Total Service download site? > > > >Russ > > > >-----Original Message----- > >From: Richard Lorbieski <richard@mail.alpha1.net> > >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > >Date: Friday, October 09, 1998 3:38 PM > >Subject: Re: (usr-tc) Web TV Help Needed > > > > > >>Call USR support and request Hiper ARC ver. 4.1.78 > >>They send me a copy via email - but I have not install it :-(. > >> > >>Richard Lorbieski > >> > >>Russ Miescke wrote: > >>> > >>> Arter reading about various problems for the past couple of weeks with > >Web > >>> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load > >it > >>> anyway. Bad move. Now all my Web TV customers are having problems > >>> connecting. I think I saw there was an fix released for this, but do > not > >>> know where to find it. Any help would be appreciated. > >>> > >>> Russ Miescke > >>> Power Web Connect > >>> russm@powerweb.net > >>> 920-885-7860 > >>> > >>> - > >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >>> with "unsubscribe usr-tc" in the body of the message. > >>> For information on digests or retrieving files and old messages send > >>> "help" to the same address. Do not use quotes in your message. > >> > >>- > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Web TV Help Needed
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-15 08:55:55

On Wed, 14 Oct 1998, Eric Billeter wrote: > I figger it's because if they actually admitted there was a > problem with their code ( and provided a simple way of resolving > the problems ) that people would lose faith in the product. So > their current solution is to hide any known problems from the end > users (ISPs), and pawn off the problem somewhere else. I would > bet that half the staff at 3com aren't aware of the software > updates, and that the other half would probably have you either > reset to factory defaults or return the card for replacement. > Eric, Either you have not seen our posting here in regards to the webTV code or you are new to this list. I have in the past posted that there is a code that fixes this problem. This code is not posted on the web - There are reason for it. It is not that we just hide problems. If we had know before releasing this code that webTV ( new classis ) boxes would request LCP restart after starting LCP we would have fixed those. We do have the code and if you have a open ticket support would be more than happy to give you the code. If you have problems do let me know and I will make sure that you get this code. Replacing the card is not a solution and I would like to know who suggested that to you. regards krish > I am currently on hold with them, and the wait time is approximately > one hour. Somehow I don't see how they expect me to renew my service > contracts with them at the prices I was just quoted. Roughly 25% of > the replacement cost seems a little out of line. Either they have so > little faith in the product or it costs them that much to support it > and/or it fails so much that the replacement costs are that high. Either > way it speaks loads for the product in question. They might consider > moving on to a seperate segment of the industry. > > If anyone has the code in question.. it would be greatly appreciated. > > BTW I am CC ing this to both my reseller and salesperson at 3com. > > > Eric T. Billeter Cable One > Internet Engineer 1314 North 3rd Street > ebilleter@cableone.net Phoenix, AZ 85004 > (602) 364-6462 > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > Sent: Sunday, October 11, 1998 2:21 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Web TV Help Needed > > > Someone was nice enough to send me the code. It worked great. Why is this > not posted on their Total Service download site? > > Russ > > -----Original Message----- > From: Richard Lorbieski <richard@mail.alpha1.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Friday, October 09, 1998 3:38 PM > Subject: Re: (usr-tc) Web TV Help Needed > > > >Call USR support and request Hiper ARC ver. 4.1.78 > >They send me a copy via email - but I have not install it :-(. > > > >Richard Lorbieski > > > >Russ Miescke wrote: > >> > >> Arter reading about various problems for the past couple of weeks with > Web > >> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load > it > >> anyway. Bad move. Now all my Web TV customers are having problems > >> connecting. I think I saw there was an fix released for this, but do not > >> know where to find it. Any help would be appreciated. > >> > >> Russ Miescke > >> Power Web Connect > >> russm@powerweb.net > >> 920-885-7860 > >> > >> - > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Web TV Help Needed
From: bryan s. blank <bryan@supernet.net>
Date: 1998-10-15 09:11:57

|o| since mid last year. In fact, now that Brian McIntire has left I'm |o| hanging up if anyone other than Ron Childs picks up. I'm tired of amen. i'm happy for brian that he's moved on to bigger and better things, but poor ron is gonna get stuck with the phone calls ... heck of a guy ... if ron leaves, i don't know what we're going to do ... |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

Subject: Re: (usr-tc) Web TV Help Needed
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-15 09:36:06

Thanks for the vote of confidence, but you give me more credit than I deserve. If you are who I think you are and if I remeber it right I didn't have any idea what you were reporting was a known problem when you were talking to Ron. I simply went to Network Engineering and asked. They told me it was a known issue, gave me the fix, and I gave it to everyone else. That's how it works. If you don't know you ask. As far as a certification program, I believe they are working on one for the future. As far as your comment about good Engineers leaving: Most that have left did so for other kinds of opportunities not because of anticipated business problems. 3COM is leveraged to continue doing well. I admit there was some turmoil when they bought out USR Mid last year but it's over. Give them a few months to get their green technicians up to speed and you will see some changes. PS. Lets keep opinions and comments of a personal nature to a minimum. It degrades from the overall usefullness of this list. Thank you -----Original Message----- >I disagree with some of what you said. I have to admit the average >skill level of the technicians at 3COM have been steadily declining >since mid last year. In fact, now that Brian McIntire has left I'm >hanging up if anyone other than Ron Childs picks up. I'm tired of >training technicians as I work with them. I once called in for tech >support on a known bug. Before I was done I had talked to 7 technicians >and spent more than half a day on the phone. Then I called in and spoke >to Ron Childs. He knew the answer right away. When I called in about >something else I spoke to Brian about my old problem. Before I could >finsish he told me he had heard of it before and had told Ron the fix. >Are these two techs the only ones that have any idea how to get answers? >Whats going on? Why don't they send their people through an intensive >training/certification program before letting them embarass themselves >in front of customers. If key technicians are jumping ship like rats on >a sinking barge you have to wonder what's going on. > >>I figger it's because if they actually admitted there was a >>problem with their code ( and provided a simple way of resolving >>the problems ) that people would lose faith in the product. So >>their current solution is to hide any known problems from the end >>users (ISPs), and pawn off the problem somewhere else. I would >>bet that half the staff at 3com aren't aware of the software >>updates, and that the other half would probably have you either >>reset to factory defaults or return the card for replacement. >> >>I am currently on hold with them, and the wait time is approximately >>one hour. Somehow I don't see how they expect me to renew my service >>contracts with them at the prices I was just quoted. Roughly 25% of >>the replacement cost seems a little out of line. Either they have so >>little faith in the product or it costs them that much to support it >>and/or it fails so much that the replacement costs are that high. >Either >>way it speaks loads for the product in question. They might consider >>moving on to a seperate segment of the industry. >> >>If anyone has the code in question.. it would be greatly appreciated. >> >>BTW I am CC ing this to both my reseller and salesperson at 3com. >> >> >>Eric T. Billeter Cable One >>Internet Engineer 1314 North 3rd Street >>ebilleter@cableone.net Phoenix, AZ 85004 >>(602) 364-6462 >> >> >>-----Original Message----- >>From: owner-usr-tc@lists.xmission.com >>[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke >>Sent: Sunday, October 11, 1998 2:21 PM >>To: usr-tc@lists.xmission.com >>Subject: Re: (usr-tc) Web TV Help Needed >> >> >>Someone was nice enough to send me the code. It worked great. Why is >this >>not posted on their Total Service download site? >> >>Russ >> >>-----Original Message----- >>From: Richard Lorbieski <richard@mail.alpha1.net> >>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>Date: Friday, October 09, 1998 3:38 PM >>Subject: Re: (usr-tc) Web TV Help Needed >> >> >>>Call USR support and request Hiper ARC ver. 4.1.78 >>>They send me a copy via email - but I have not install it :-(. >>> >>>Richard Lorbieski >>> >>>Russ Miescke wrote: >>>> >>>> Arter reading about various problems for the past couple of weeks >with >>Web >>>> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and >load >>it >>>> anyway. Bad move. Now all my Web TV customers are having problems >>>> connecting. I think I saw there was an fix released for this, but >do not >>>> know where to find it. Any help would be appreciated. >>>> >>>> Russ Miescke >>>> Power Web Connect >>>> russm@powerweb.net >>>> 920-885-7860 > > >______________________________________________________ >Get Your Private, Free Email at http://www.hotmail.com > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-15 09:42:18

Thus spake Brian K McIntire >I seriously doubt work would continue on the NETServer in any case. It's >the 386 of computers. It's outdated. Obsolete. The HiPer ARC is a much >better product. Rumor has it there's is going to be an even better deal >offerred to people to trade their NETServer's for one. Time to move on. NO, NO, NO, NO! The Netserver is *not* obsolete, the thing has a 486/100 in it for goodness sakes! It should be powerful enough to handle quite a bit of stuff. 3Com *NEEDS* a lower cost alternative to a HiPer Chassis, I *CANNOT* justify a HiPer chassis if I'm opening up a POP in a new location, particularly if its a smaller city that isn't going to have the eventual growth of one of the larger cities in the country. I've said it before, and I'll continue to say it as long as 3Com folks and 3Com related folks spout this party line, eliminating the netservers and quads is a *COLLOSAL* mistake. You're loosing access to ComOS based code, ok, I understand that...don't like it, but its a fact of life...but backport Pilgrim to the netserver product, its reasonable, it should be easy to do, it should have decent performance if the code is halfway decent, you'll be able to pick up the mid and small sized ISP customer base that you seem to have been alienating recently with the move to higher cost, higher density HiPer equipment that small and mid sized ISP (and non-isp users) really don't need. Sorry Brian...don't mean to rant on you...I know you're not a part of 3Com anymore, but perhaps being part of the channel for them they'll listen to you even more now? They don't seem to be listening to customers in this respect much as just about every usr tc owner that I've talked to has agreed with me about not wanting the netserver to be discontinued. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Web TV Help Needed
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-15 09:48:30

On Thu, 15 Oct 1998, Charles Sprickman wrote: > What's the situation then if say I just bought a HiPer chassis that > shipped with the "non WebTV friendly" code? Say I made the decision that > a support contract is not worth 1/4 of the purchase price but I did pay > for software upgrades. Am I then just stuck with telling my webtv users > to go away? Perhaps the web site code area should incorporate an > "experimental" or "hotfix" section?? Its upto you to make any decision. But if we ship a code with a chasiss that has a problem - irrespective of whether you have a contract or not, we will fix and give you the code. Its not that you should live with a problem once you have a chassis - just because it was shipped to you that way. Typically there is a 90 day time-frame wherein if you run into a problem we do solve it. > > I don't think anyone on this list can justify paying about $2000/chassis > for the "privilege" of talking to the support folks, and no one should be > penalized by that decision by not having access to emergency releases such > as the webtv fix. No you are wrong here. We do have a ER release, it is not posted in the web since it is not a service release. If it was service release then yes it will be posted. > krish > And since I see some new 3com addresses on the cc: list, could someone > from 3com perhaps explain where the value is in these new high-priced > support contracts? I'd think about paying that much for on site visits, > but not to educate some newbie on the phone... > > Thanks, > > Charles > > On Thu, 15 Oct 1998, Tatai SV Krishnan wrote: > > > Date: Thu, 15 Oct 1998 08:55:55 -0500 (CDT) > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > Reply-To: usr-tc@lists.xmission.com > > To: Eric Billeter <ebilleter@cableone.net> > > Cc: usr-tc@lists.xmission.com, > > "Todd Starkey (E-mail)" <Usman_Malik@mw.3com.com>, > > Kevin_musseau@3com.com, paul_mudlaff@mw.3com.com > > Subject: RE: (usr-tc) Web TV Help Needed > > > > > > On Wed, 14 Oct 1998, Eric Billeter wrote: > > > > > I figger it's because if they actually admitted there was a > > > problem with their code ( and provided a simple way of resolving > > > the problems ) that people would lose faith in the product. So > > > their current solution is to hide any known problems from the end > > > users (ISPs), and pawn off the problem somewhere else. I would > > > bet that half the staff at 3com aren't aware of the software > > > updates, and that the other half would probably have you either > > > reset to factory defaults or return the card for replacement. > > > > > > > Eric, > > > > Either you have not seen our posting here in regards to the webTV code or > > you are new to this list. I have in the past posted that there is a code > > that fixes this problem. This code is not posted on the web - There are > > reason for it. It is not that we just hide problems. If we had know > > before releasing this code that webTV ( new classis ) boxes would request > > LCP restart after starting LCP we would have fixed those. We do have the > > code and if you have a open ticket support would be more than happy to > > give you the code. If you have problems do let me know and I will make > > sure that you get this code. Replacing the card is not a solution and I > > would like to know who suggested that to you. > > > > regards > > > > krish > > > > > I am currently on hold with them, and the wait time is approximately > > > one hour. Somehow I don't see how they expect me to renew my service > > > contracts with them at the prices I was just quoted. Roughly 25% of > > > the replacement cost seems a little out of line. Either they have so > > > little faith in the product or it costs them that much to support it > > > and/or it fails so much that the replacement costs are that high. Either > > > way it speaks loads for the product in question. They might consider > > > moving on to a seperate segment of the industry. > > > > > > If anyone has the code in question.. it would be greatly appreciated. > > > > > > BTW I am CC ing this to both my reseller and salesperson at 3com. > > > > > > > > > Eric T. Billeter Cable One > > > Internet Engineer 1314 North 3rd Street > > > ebilleter@cableone.net Phoenix, AZ 85004 > > > (602) 364-6462 > > > > > > > > > -----Original Message----- > > > From: owner-usr-tc@lists.xmission.com > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > > > Sent: Sunday, October 11, 1998 2:21 PM > > > To: usr-tc@lists.xmission.com > > > Subject: Re: (usr-tc) Web TV Help Needed > > > > > > > > > Someone was nice enough to send me the code. It worked great. Why is this > > > not posted on their Total Service download site? > > > > > > Russ > > > > > > -----Original Message----- > > > From: Richard Lorbieski <richard@mail.alpha1.net> > > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > > Date: Friday, October 09, 1998 3:38 PM > > > Subject: Re: (usr-tc) Web TV Help Needed > > > > > > > > > >Call USR support and request Hiper ARC ver. 4.1.78 > > > >They send me a copy via email - but I have not install it :-(. > > > > > > > >Richard Lorbieski > > > > > > > >Russ Miescke wrote: > > > >> > > > >> Arter reading about various problems for the past couple of weeks with > > > Web > > > >> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load > > > it > > > >> anyway. Bad move. Now all my Web TV customers are having problems > > > >> connecting. I think I saw there was an fix released for this, but do not > > > >> know where to find it. Any help would be appreciated. > > > >> > > > >> Russ Miescke > > > >> Power Web Connect > > > >> russm@powerweb.net > > > >> 920-885-7860 > > > >> > > > >> - > > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > >> with "unsubscribe usr-tc" in the body of the message. > > > >> For information on digests or retrieving files and old messages send > > > >> "help" to the same address. Do not use quotes in your message. > > > > > > > >- > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-15 09:55:01

I know it's got a 486 chip in. What I meant to say is it's design is as old as 386 technology. It was designed when all people were doing was dialing up and checking e-mail. Now everyone doing quake, playing games on line, web tv, webcam's, and soon voice over ip. Even if we could re-write the code and add features you don't really think the NetServer would be able to comfortably support all your customer's needs much longer anyway do you. -----Original Message----- >Thus spake Brian K McIntire >>I seriously doubt work would continue on the NETServer in any case. It's >>the 386 of computers. It's outdated. Obsolete. The HiPer ARC is a much >>better product. Rumor has it there's is going to be an even better deal >>offerred to people to trade their NETServer's for one. Time to move on. > >NO, NO, NO, NO! The Netserver is *not* obsolete, the thing has a >486/100 in it for goodness sakes! It should be powerful enough to >handle quite a bit of stuff. 3Com *NEEDS* a lower cost alternative to a >HiPer Chassis, I *CANNOT* justify a HiPer chassis if I'm opening up a >POP in a new location, particularly if its a smaller city that isn't >going to have the eventual growth of one of the larger cities in the >country. I've said it before, and I'll continue to say it as long as >3Com folks and 3Com related folks spout this party line, eliminating the >netservers and quads is a *COLLOSAL* mistake. > >You're loosing access to ComOS based code, ok, I understand that...don't >like it, but its a fact of life...but backport Pilgrim to the netserver >product, its reasonable, it should be easy to do, it should have decent >performance if the code is halfway decent, you'll be able to pick up the >mid and small sized ISP customer base that you seem to have been >alienating recently with the move to higher cost, higher density HiPer >equipment that small and mid sized ISP (and non-isp users) really don't >need. > >Sorry Brian...don't mean to rant on you...I know you're not a part of >3Com anymore, but perhaps being part of the channel for them they'll >listen to you even more now? They don't seem to be listening to >customers in this respect much as just about every usr tc owner that >I've talked to has agreed with me about not wanting the netserver to be >discontinued. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Web TV Help Needed
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-15 10:03:02

What's the situation then if say I just bought a HiPer chassis that shipped with the "non WebTV friendly" code? Say I made the decision that a support contract is not worth 1/4 of the purchase price but I did pay for software upgrades. Am I then just stuck with telling my webtv users to go away? Perhaps the web site code area should incorporate an "experimental" or "hotfix" section?? I don't think anyone on this list can justify paying about $2000/chassis for the "privilege" of talking to the support folks, and no one should be penalized by that decision by not having access to emergency releases such as the webtv fix. And since I see some new 3com addresses on the cc: list, could someone from 3com perhaps explain where the value is in these new high-priced support contracts? I'd think about paying that much for on site visits, but not to educate some newbie on the phone... Thanks, Charles On Thu, 15 Oct 1998, Tatai SV Krishnan wrote: > Date: Thu, 15 Oct 1998 08:55:55 -0500 (CDT) > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > Reply-To: usr-tc@lists.xmission.com > To: Eric Billeter <ebilleter@cableone.net> > Cc: usr-tc@lists.xmission.com, > "Todd Starkey (E-mail)" <Usman_Malik@mw.3com.com>, > Kevin_musseau@3com.com, paul_mudlaff@mw.3com.com > Subject: RE: (usr-tc) Web TV Help Needed > > > On Wed, 14 Oct 1998, Eric Billeter wrote: > > > I figger it's because if they actually admitted there was a > > problem with their code ( and provided a simple way of resolving > > the problems ) that people would lose faith in the product. So > > their current solution is to hide any known problems from the end > > users (ISPs), and pawn off the problem somewhere else. I would > > bet that half the staff at 3com aren't aware of the software > > updates, and that the other half would probably have you either > > reset to factory defaults or return the card for replacement. > > > > Eric, > > Either you have not seen our posting here in regards to the webTV code or > you are new to this list. I have in the past posted that there is a code > that fixes this problem. This code is not posted on the web - There are > reason for it. It is not that we just hide problems. If we had know > before releasing this code that webTV ( new classis ) boxes would request > LCP restart after starting LCP we would have fixed those. We do have the > code and if you have a open ticket support would be more than happy to > give you the code. If you have problems do let me know and I will make > sure that you get this code. Replacing the card is not a solution and I > would like to know who suggested that to you. > > regards > > krish > > > I am currently on hold with them, and the wait time is approximately > > one hour. Somehow I don't see how they expect me to renew my service > > contracts with them at the prices I was just quoted. Roughly 25% of > > the replacement cost seems a little out of line. Either they have so > > little faith in the product or it costs them that much to support it > > and/or it fails so much that the replacement costs are that high. Either > > way it speaks loads for the product in question. They might consider > > moving on to a seperate segment of the industry. > > > > If anyone has the code in question.. it would be greatly appreciated. > > > > BTW I am CC ing this to both my reseller and salesperson at 3com. > > > > > > Eric T. Billeter Cable One > > Internet Engineer 1314 North 3rd Street > > ebilleter@cableone.net Phoenix, AZ 85004 > > (602) 364-6462 > > > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > > Sent: Sunday, October 11, 1998 2:21 PM > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) Web TV Help Needed > > > > > > Someone was nice enough to send me the code. It worked great. Why is this > > not posted on their Total Service download site? > > > > Russ > > > > -----Original Message----- > > From: Richard Lorbieski <richard@mail.alpha1.net> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > Date: Friday, October 09, 1998 3:38 PM > > Subject: Re: (usr-tc) Web TV Help Needed > > > > > > >Call USR support and request Hiper ARC ver. 4.1.78 > > >They send me a copy via email - but I have not install it :-(. > > > > > >Richard Lorbieski > > > > > >Russ Miescke wrote: > > >> > > >> Arter reading about various problems for the past couple of weeks with > > Web > > >> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load > > it > > >> anyway. Bad move. Now all my Web TV customers are having problems > > >> connecting. I think I saw there was an fix released for this, but do not > > >> know where to find it. Any help would be appreciated. > > >> > > >> Russ Miescke > > >> Power Web Connect > > >> russm@powerweb.net > > >> 920-885-7860 > > >> > > >> - > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > >> with "unsubscribe usr-tc" in the body of the message. > > >> For information on digests or retrieving files and old messages send > > >> "help" to the same address. Do not use quotes in your message. > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) Web TV Help Needed
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-15 10:12:23

Thus spake Charles Sprickman >And since I see some new 3com addresses on the cc: list, could someone >from 3com perhaps explain where the value is in these new high-priced >support contracts? I'd think about paying that much for on site visits, >but not to educate some newbie on the phone... Gee...this sounds eerily familiar to a conference call I had with several 3Com folks. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) Web TV Help Needed
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-10-15 10:25:00

-> What's the situation then if say I just bought a HiPer chassis that shipped -> with the "non WebTV friendly" code? Say I made the decision that a support -> contract is not worth 1/4 of the purchase price but I did pay for software -> upgrades. Am I then just stuck with telling my webtv users to go away? -> Perhaps the web site code area should incorporate an "experimental" or -> "hotfix" section?? -> -> I don't think anyone on this list can justify paying about $2000/chassis for -> the "privilege" of talking to the support folks, and no one should be -> penalized by that decision by not having access to emergency releases such -> as the webtv fix. -> -> And since I see some new 3com addresses on the cc: list, could someone from -> 3com perhaps explain where the value is in these new high-priced support -> contracts? I'd think about paying that much for on site visits, but not to -> educate some newbie on the phone... Charles, I share some of your sentiments. I personally am holding off renewing our support contract as a way of protesting the huge price increases. I agree hot fixes should be provided for free but they can charge for feature increases. Now how they handle this logistically is another issue. Jeff Binkley ASA Network Computing

Subject: (usr-tc) Radius Dial-Back & Telco PRI metering
From: Randy Doran <randydoran@usa.net>
Date: 1998-10-15 10:25:46

Currently we use Ascend MAXs for ISDN dialback, i.e. an ISDN customers dials in, gets authenticated, then is disconnected and we call them back and set up their IP network. This ofcourse is to beat the BRI metered tarrifs that the telcos charge. I would like to do this on the HiPerARC but can't seem to make it work. Can anybody tell me what the equivalent USRobotics attributes are to the Ascend attributes for dialback? Here is a example of the attributes in our radius profile that we use to tell the MAX what to do: user Password = "UNIX" User-Name = "user", User-Service = Framed-User, Framed-Protocol = PPP, Ascend-Callback = Callback-Yes, Ascend-Dial-Number = "5551212", Ascend-Send-Auth = Send-Auth-PAP, Ascend-Send-Secret = "secret", Framed-Address = 111.222.111.222, Framed-Netmask = 255.255.255.255, Framed-Route = "222.111.222.0/29 111.222.111.222 1", Framed-Routing = None, Framed-MTU = 1500, Ascend-Data-Svc = Switched-64K, Ascend-Idle-Limit = 0, Ascend-Maximum-Channels = 2 On a related topic, we discovered yesterday that GTE is now going to charge 2 cents per minute for outgoing calls on PRIs. If Bell decides to do this it will eat us alive with all of the dialback customers we have in South Florida. Has there been any talk of other telecos metering for PRI circuits? Thanks, Randy Doran e.spire Communications \ CyberGate Network Operations Circuit Engineer \ Modem Network Administrator

Subject: (usr-tc) HiPer w/ Lucent LT WinModem fix
From: Richard Gamberg <bbhi@prodigy.net>
Date: 1998-10-15 10:57:31

For those ISPs using the HiPer DSP and having customers with LT Winmodems who can't connect, Lucent has released 5.23 firmware that corrects the problem; however, there's a problem with Lucent's site - and a solution. See http://808hi.com/56k/x2-lucent.htm#firmware But, hurry; Lucent has indicated that they may have to pull the driver from the site until they figure out why some people have trouble downloading it without corruption. Aloha, Richard http://808hi.com/56k/ 56k=v.Unreliable

Subject: Re: (usr-tc) any suggestions on new technology????
From: Randy Doran <randydoran@usa.net>
Date: 1998-10-15 11:02:58

At 09:46 AM 10/13/98 -0400, you wrote: >we are a small but surly growing isp in upstate new york. all of our >advertising has been word of month just to make sure we keep a good >modem ratio. we are looking to expand out and take into acount newer >technologies (such as cable modems, xDSL, etc.). i'd just like some >suggestions on what to go with. here's some generic questions to get >people thinking. > >1.) if we went with xDSL, what would we need. equipment and "phone >company" wise. (keep in mind were in a bad section of bell atlantic >teritory) You will need to colocate at the teleco central office and get dry copper from them to plug ADSL equipment into. As an ISP you may not be able to get dry copper, I think the the LECs require you to have CLEC status before they will give up their copper. Randy Doran e.spire Communications \ CyberGate Network Operations Circuit Engineer \ Modem Network Administrator

Subject: (usr-tc) Re: Netserver vs Hiper
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-15 11:03:49

On Thu, 15 Oct 1998, Jeff Mcadams wrote: > Thus spake Brian K McIntire > >I seriously doubt work would continue on the NETServer in any case. It's > >the 386 of computers. It's outdated. Obsolete. The HiPer ARC is a much > >better product. Rumor has it there's is going to be an even better deal > >offerred to people to trade their NETServer's for one. Time to move on. > > NO, NO, NO, NO! The Netserver is *not* obsolete, the thing has a > 486/100 in it for goodness sakes! It should be powerful enough to No, it's not obsolete. This is a better processor than a PM3, and the PM3 has some better features. > handle quite a bit of stuff. 3Com *NEEDS* a lower cost alternative to a > HiPer Chassis, I *CANNOT* justify a HiPer chassis if I'm opening up a > POP in a new location, particularly if its a smaller city that isn't The 3314 bundle is only around $10,100. Isn't that 48 ports? Could you really expect to get a bundle with quad modems and the Netserver for less? Brian

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-15 11:07:16

Thus spake Brian K McIntire >I know it's got a 486 chip in. What I meant to say is it's design is as old >as 386 technology. It was designed when all people were doing was dialing >up and checking e-mail. Now everyone doing quake, playing games on line, >web tv, webcam's, and soon voice over ip. Even if we could re-write the >code and add features you don't really think the NetServer would be able to >comfortably support all your customer's needs much longer anyway do you. I doubt it would handle VOIP, but all the rest of that is just streams of IP packets, the hardware is *plenty* capable of handling that for at least 48 ports, and it should be able to handle it for 96 with very little degradation. The software may need some work, but I've *always* told people, USR/3Com modem code and hardware is good, and their access server hardware is good, but they can't seem to write access server code to save their lives. This is where the work needs to be done. With good code, the 486/100 has *plenty* of power to handle people playing quake, using web tv, webcam's and other stuff. VOIP it probably won't handle because that's not just an issue of passing IP packets, but none of the rest of that requires anything out of the ordinary from an access server. To answer your last question, yes, I think the NetServer would be more than adequate for my customer's needs for quite some time to come. The only thing I've seen that is possibly coming for the ISP market that would not be able to be handled on the NetServer hardware is VOIP. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) I have a fast-booting HARC now
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-15 11:16:08

Glad to hear It helped -----Original Message----- >OK, Brian, Mike, anyone else that might have suggested this...thanks, >the AT{ZF} formatted the flash and my HARC is booting normally now. >That did the trick. > >Someone check out ticket number 109236 and let the folks know what fixed >it (would add it myself, but it was already closed so don't have access >to do it now). > >Thanks! >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) I have a fast-booting HARC now
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-15 11:53:54

OK, Brian, Mike, anyone else that might have suggested this...thanks, the AT{ZF} formatted the flash and my HARC is booting normally now. That did the trick. Someone check out ticket number 109236 and let the folks know what fixed it (would add it myself, but it was already closed so don't have access to do it now). Thanks! -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) using round robin & fixed assignment
From: Taino d Johnston <usr-list@accesscom.com>
Date: 1998-10-15 13:17:07

We recently switched telcos, which then switched us from channelized T1 lines to PRI lines. The telco switch was from PacBell to ICG. Upon switching we found ourselves facing a lot of problems, however, it was this last problem that we felt was quite strange and worth noting. In order to do some tests with the new service, we changed the configuration of our equipment from 'round robin' to 'fixed assignment'. After we thought the experienced problems were corrected we started getting reports of busy signals -- during time periods when there were modems available. The problem turned out to be that the PRI lines were resetting faster than our modems were. Essentially, this meant calls would be routed back down to a newly opened line on the PRI but would hit a modem that had not been reset. Our testing found that we were giving busy signals out about 20% of the time. Switching back to 'round robin' seems to have since corrected the problem and we have not given out any more busy signals. What I am trying to find out is why when configured for 'fixed assignment' we were giving out busy signals? The problems went away once we switched to 'round robin'. We are running a few TC chassis containing Quad Digital & Digital/Analog modem cards with PRI lines. All our Quad modem cards, NETserver PRI cards, Dual PRI cards and NMC cards are running the current versions of the software. Taino Johnston Manager, Technical Support Access Internet Communications +----------------------------------------------------------------+ | Taino d Johnston | Phone: (408) 777-8190 | | Manager, Technical Support | Tech Support: (408) 342-0551 | | | Fax: (408) 777-8191 | | Access Internet Communications | http://www.accesscom.com/ | | tdj@accesscom.com | support@accesscom.com | +----------------------------------------------------------------+

Subject: Re: (usr-tc) using round robin & fixed assignment
From: Taino d Johnston <usr-list@accesscom.com>
Date: 1998-10-15 13:41:11

That is what I figured but when speaking to the 3Com technical support they said that isn't possible. But who knows what they really know. So is there anyway around this if we want to use 'fixed assignment'? Taino Johnston Manager, Technical Support Access Internet Communications >Thus spake Taino d Johnston >>The problem turned out to be that the PRI lines were resetting >>faster than our modems were. Essentially, this meant calls would be routed >>back down to a newly opened line on the PRI but would hit a modem that had >>not been reset. > >[snip] > >>What I am trying to find out is why when configured for 'fixed assignment' >>we were giving out busy signals? The problems went away once we switched >>to 'round robin'. > >Uhm, dude...you answered you own question...the PRI timeslot is >reset'ing faster than the modem and a new call is arriving before the >modem is ready, since you're on fixed assignment, the pri card can't >reroute the call anywhere else, so what choice does it have? can only >give a busy. Either use round-robin or first-available is your >solution. >-- >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. Taino Johnston Manager, Technical Support Access Internet Communications +----------------------------------------------------------------+ | Taino d Johnston | Phone: (408) 777-8190 | | Manager, Technical Support | Tech Support: (408) 342-0551 | | | Fax: (408) 777-8191 | | Access Internet Communications | http://www.accesscom.com/ | | tdj@accesscom.com | support@accesscom.com | +----------------------------------------------------------------+

Subject: Re: (usr-tc) any suggestions on new technology????
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-15 14:02:39

Randy Doran was heard to say: >>1.) if we went with xDSL, what would we need. equipment and "phone >>company" wise. (keep in mind were in a bad section of bell atlantic >>teritory) > >You will need to colocate at the teleco central office and get dry copper >from them to plug ADSL equipment into. As an ISP you may not be able to >get dry copper, I think the the LECs require you to have CLEC status before >they will give up their copper. Actually, some telco's install and run their own DSLAM (multiplexor) that acts sorta like an ethernet switch... all the DSL traffic terminates on the telco gear and they spit traffic to the ISP via frame relay or ATM. I've not touched an DSL hardware, personally. --Ricky

Subject: Re: (usr-tc) Radiator vs. Cistron
From: MegaZone <megazone@megazone.org>
Date: 1998-10-15 14:29:13

Once upon a time Brian K McIntire shaped the electrons to say... >I know it's got a 486 chip in. What I meant to say is it's design is as old >as 386 technology. It was designed when all people were doing was dialing >up and checking e-mail. Now everyone doing quake, playing games on line, >web tv, webcam's, and soon voice over ip. Even if we could re-write the >code and add features you don't really think the NetServer would be able to >comfortably support all your customer's needs much longer anyway do you. Yes I do. Why is it that other vendors - Ascend, Cisco, Lucent, etc - can continue to support their older hardware and continue to introduct new features? I don't expect most ISPs to *need* crap like VOIP, ATM, etc. Some yes - and for them there are higher level units. I DO expect ISPs to be need to be able to handle modem and ISDN calls for quite some time as the core of their business. Online gaming IS JUST DATA - any good unit should be able to handle it. Data has not changed. How can products *older* than the TC Netserver, like the MAX4000 family or PortMaster-2 family, still have new software with brand new features, with no end in sight for the near future - while 3Com is claiming the TC NS is just exhausted? If Lucent can get OSPFv2 into the PM-2 with 4MB of RAM, 512K FLASH, and a 386-33 (386-25 on older units) and have it work *VERY WELL* - then why can't 3Com do something for the TC NS, which has a higher level of HW all around? With my HW experience at both Xylogics and Livingston/Lucent, and a numebr of years doing competive analysis for Livingston/Lucent - I just plain don't buy it. Unless they are covering up some fundamental design flaw, the TC NS should have years of life left in it. It seems to me it was a business decision - possibly they don't see a good ROI on the effort needed to back-port HiperOS. Or perhaps the code is poor and it would be too much for the TC NS to handle - and the time and effort to clean it up doesn't have a good ROI. But I don't buy any argument that the HW itself is the issue - again, unless there is some unspoken fundamental design flaw within the unit. The components should have more thna enough life left in them. Hell, the PM-3 is current and still runs a 486-66, 4MB RAM, and 1MB of FLASH. Cisco is still supporting the AS5200, Ascend is still supporting the MAX4000 - despite the AS5300 and MAX6000 being available. In fact, it seems like 3Com is the only one dropping their last-generation product in such a hurry. Why is that? -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) Radiator vs. Cistron
From: David Bolen <db3l@ans.net>
Date: 1998-10-15 16:00:57

"Brian K McIntire" <bmcintire@commnet.com> writes: > I know it's got a 486 chip in. What I meant to say is it's design is as old > as 386 technology. It was designed when all people were doing was dialing > up and checking e-mail. I can't help it - this is a little silly. The current NETServer hardware design is circa '96 - hardly the dark ages. The NETServer software design is much earlier (if you start counting from the start of Livingston). So what. That hardly makes it an issue. After all, I'll posit that the majority (I'd say large majority, but I think Linux started afresh :-)) of non-Windows machines on the Internet are running their networking with BSD-derived TCP/IP code. And that's closing in on a decade old. The software has been maintained over time as functionality was needed, and clearly at least Lucent is able to continue to use the same kernel even at this stage of the game. All those other games and functionality being performed online nowadays are still based at a fundamental level on IP, which is what makes them possible. There's nothing in any of most basic protocols of the Internet (the exact same ones used when HTTP didn't exist) that has changed significantly in that time. There's plenty of change in the various customizability and manageability functions, and in adding support for better integration with other equipment in the backbone. But at the lowest layers, the support needed to run the newest and fanciest applications remains the same as that needed to run e-mail checking. Sure, there are other speciality protocols and support (VPN, LT2P, etc..) being layered on top that can take horsepower, but the NETServer is hardly a failing platform. And to be honest, to deliver all the other services you mentioned doesn't require any of those speciality platforms. The NETServer just needs to terminate PPP and route IP. Clearly the threshold of performance between the NETServer hardware and the ARC would be different, but that's not a problem - that's just a design point for anyone trying to use the NETServer. The exact same hardware design is used in the original EdgeServer and we've got almost two thousand of them running BSD Unix and performing all sorts of serious processing. Of course, none of this changes the fact that software development for the NETServer platform is dead, and thus it will grow riskier to continue using them as further enhancements become available on other platforms. I just think it's a disservice to try to portray it in any way as a technically-oriented decision. It's not. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) using round robin & fixed assignment
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-15 16:24:34

Thus spake Taino d Johnston >The problem turned out to be that the PRI lines were resetting >faster than our modems were. Essentially, this meant calls would be routed >back down to a newly opened line on the PRI but would hit a modem that had >not been reset. [snip] >What I am trying to find out is why when configured for 'fixed assignment' >we were giving out busy signals? The problems went away once we switched >to 'round robin'. Uhm, dude...you answered you own question...the PRI timeslot is reset'ing faster than the modem and a new call is arriving before the modem is ready, since you're on fixed assignment, the pri card can't reroute the call anywhere else, so what choice does it have? can only give a busy. Either use round-robin or first-available is your solution. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) using round robin & fixed assignment
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-15 16:48:27

Thus spake Taino d Johnston >That is what I figured but when speaking to the 3Com technical support they >said that isn't possible. But who knows what they really know. So is >there anyway around this if we want to use 'fixed assignment'? Tell the telco to use round-robin on their hunt group. ICG is usually pretty flexible and will work with you on that. Why do you want to use fixed assignment so much? -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-15 16:48:34

On Thu, 15 Oct 1998, David Bolen wrote: > > I know it's got a 486 chip in. What I meant to say is it's design is as old > > as 386 technology. It was designed when all people were doing was dialing > > up and checking e-mail. > > I can't help it - this is a little silly. The current NETServer > hardware design is circa '96 - hardly the dark ages. Bravo! Maybe someone should port Linux to the NetServer and show how much horsepower it still has. Sheesh! :) Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Andres Kroonmaa <andre@ml.ee>
Date: 1998-10-15 17:19:07

On 15 Oct 98, at 9:42, Jeff Mcadams <usr-tc@lists.xmission.com> wrote: > Thus spake Brian K McIntire > >I seriously doubt work would continue on the NETServer in any case. It's > >the 386 of computers. It's outdated. Obsolete. The HiPer ARC is a much > >better product. Rumor has it there's is going to be an even better deal > >offerred to people to trade their NETServer's for one. Time to move on. > > NO, NO, NO, NO! The Netserver is *not* obsolete, the thing has a > country. I've said it before, and I'll continue to say it as long as > 3Com folks and 3Com related folks spout this party line, eliminating the > netservers and quads is a *COLLOSAL* mistake. I'm tired of this theme. Guess most are. Both parties are right. Now ask, given that 1) 3Com does not want to continue development of Netservers 2) quite alot of people demand for low-cost entry-level chassis Why not implement some licensing into Harc, sell it low cost and limit it to some fraction of its capabilities? Same hardware, same codebase, same support, easy upgrade path. All parties happy. Why not? ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------

Subject: RE: (usr-tc) Web TV Help Needed
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-15 19:50:21

On Thu, 15 Oct 1998, Tatai SV Krishnan wrote: > Its upto you to make any decision. But if we ship a code with a chasiss > that has a problem - irrespective of whether you have a contract or not, > we will fix and give you the code. Its not that you should live with a > problem once you have a chassis - just because it was shipped to you that > way. Typically there is a 90 day time-frame wherein if you run into a > problem we do solve it. OK, that's fair enough... I still believe the value in the TCH is not so much the software but the hardware. I really see no reason for the (extremeley pricey) software contract. Most upgrades I've done are to get features working that existed when I bought the rack, such as MPIP or RIPv2... > > I don't think anyone on this list can justify paying about $2000/chassis > > for the "privilege" of talking to the support folks, and no one should be > > penalized by that decision by not having access to emergency releases such > > as the webtv fix. > > No you are wrong here. We do have a ER release, it is not posted in the > web since it is not a service release. > If it was service release then yes it will be posted. Regardless, if you have a large WebTV user base, having unrestricted access to the fix through channels other than support is a good thing. Disclaimers for those that may think it's a "perfect" release and not just a hotfix. I still feel the contracts are way out of line, especially when compared to offerings from Cisco, Lucent, and Ascend... Hopefully we aren't relegated to voting only with our Purchase Orders. Charles > krish > > > > And since I see some new 3com addresses on the cc: list, could someone > > from 3com perhaps explain where the value is in these new high-priced > > support contracts? I'd think about paying that much for on site visits, > > but not to educate some newbie on the phone... > > > > Thanks, > > > > Charles > > > > On Thu, 15 Oct 1998, Tatai SV Krishnan wrote: > > > > > Date: Thu, 15 Oct 1998 08:55:55 -0500 (CDT) > > > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > > > Reply-To: usr-tc@lists.xmission.com > > > To: Eric Billeter <ebilleter@cableone.net> > > > Cc: usr-tc@lists.xmission.com, > > > "Todd Starkey (E-mail)" <Usman_Malik@mw.3com.com>, > > > Kevin_musseau@3com.com, paul_mudlaff@mw.3com.com > > > Subject: RE: (usr-tc) Web TV Help Needed > > > > > > > > > On Wed, 14 Oct 1998, Eric Billeter wrote: > > > > > > > I figger it's because if they actually admitted there was a > > > > problem with their code ( and provided a simple way of resolving > > > > the problems ) that people would lose faith in the product. So > > > > their current solution is to hide any known problems from the end > > > > users (ISPs), and pawn off the problem somewhere else. I would > > > > bet that half the staff at 3com aren't aware of the software > > > > updates, and that the other half would probably have you either > > > > reset to factory defaults or return the card for replacement. > > > > > > > > > > Eric, > > > > > > Either you have not seen our posting here in regards to the webTV code or > > > you are new to this list. I have in the past posted that there is a code > > > that fixes this problem. This code is not posted on the web - There are > > > reason for it. It is not that we just hide problems. If we had know > > > before releasing this code that webTV ( new classis ) boxes would request > > > LCP restart after starting LCP we would have fixed those. We do have the > > > code and if you have a open ticket support would be more than happy to > > > give you the code. If you have problems do let me know and I will make > > > sure that you get this code. Replacing the card is not a solution and I > > > would like to know who suggested that to you. > > > > > > regards > > > > > > krish > > > > > > > I am currently on hold with them, and the wait time is approximately > > > > one hour. Somehow I don't see how they expect me to renew my service > > > > contracts with them at the prices I was just quoted. Roughly 25% of > > > > the replacement cost seems a little out of line. Either they have so > > > > little faith in the product or it costs them that much to support it > > > > and/or it fails so much that the replacement costs are that high. Either > > > > way it speaks loads for the product in question. They might consider > > > > moving on to a seperate segment of the industry. > > > > > > > > If anyone has the code in question.. it would be greatly appreciated. > > > > > > > > BTW I am CC ing this to both my reseller and salesperson at 3com. > > > > > > > > > > > > Eric T. Billeter Cable One > > > > Internet Engineer 1314 North 3rd Street > > > > ebilleter@cableone.net Phoenix, AZ 85004 > > > > (602) 364-6462 > > > > > > > > > > > > -----Original Message----- > > > > From: owner-usr-tc@lists.xmission.com > > > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > > > > Sent: Sunday, October 11, 1998 2:21 PM > > > > To: usr-tc@lists.xmission.com > > > > Subject: Re: (usr-tc) Web TV Help Needed > > > > > > > > > > > > Someone was nice enough to send me the code. It worked great. Why is this > > > > not posted on their Total Service download site? > > > > > > > > Russ > > > > > > > > -----Original Message----- > > > > From: Richard Lorbieski <richard@mail.alpha1.net> > > > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > > > Date: Friday, October 09, 1998 3:38 PM > > > > Subject: Re: (usr-tc) Web TV Help Needed > > > > > > > > > > > > >Call USR support and request Hiper ARC ver. 4.1.78 > > > > >They send me a copy via email - but I have not install it :-(. > > > > > > > > > >Richard Lorbieski > > > > > > > > > >Russ Miescke wrote: > > > > >> > > > > >> Arter reading about various problems for the past couple of weeks with > > > > Web > > > > >> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load > > > > it > > > > >> anyway. Bad move. Now all my Web TV customers are having problems > > > > >> connecting. I think I saw there was an fix released for this, but do not > > > > >> know where to find it. Any help would be appreciated. > > > > >> > > > > >> Russ Miescke > > > > >> Power Web Connect > > > > >> russm@powerweb.net > > > > >> 920-885-7860 > > > > >> > > > > >> - > > > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > >> with "unsubscribe usr-tc" in the body of the message. > > > > >> For information on digests or retrieving files and old messages send > > > > >> "help" to the same address. Do not use quotes in your message. > > > > > > > > > >- > > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > > with "unsubscribe usr-tc" in the body of the message. > > > > > For information on digests or retrieving files and old messages send > > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > > > > > > - > > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > > with "unsubscribe usr-tc" in the body of the message. > > > > For information on digests or retrieving files and old messages send > > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the 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 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. > > > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) Web TV Help Needed
From: Russ Miescke <russm@powerweb.net>
Date: 1998-10-16 01:16:47

The 4.1.78-4 code did work for the web tv problem, but you are right it does create new ones with our radius and accounting (RadiusNT). It seems the customers having the problem are, you guessed it .....Web TV along with NT and MACs. Any ideas when the final fix will be out? Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>; Lou Paris <webmaster@westelcom.com>; Internet Technicians <internet@westelcom.com> On Wed, 14 Oct 1998, Brian Gordon wrote: > I don't know why its not posted on the Web Site. I was like the first one > that found that WEB TV problem. I remember that Monday morning getting a > notice that the code was out and I upgraded like at 8:00 am. Next thing I > knew, I had like 50 Web TV people calling in..three days later a fix came > out for it, and they emailed it to me. This should have been posted to > their web site ASAP! > The WebTV fix code 4.1.78-4 for the HiPer arc is currently available only if you call support. There is a reason for this. This code as some of you in this list have stated does have some problem with accounting packets, and some have even reported problems with ISDN. Most of others who are using this code did not have any problems to report. We would have posted this code on the site if this code had all the fixes. Currently you can get this code - just open a ticket with support. We are in the process of getting these fixes rolled into a service release which should be on the web site soon. krish > I am having similar unresolved issues with my Netserver 16 V.34+ in one of > my small pops ,(Modems not resetting properly..hanging... etc. of course > there is always some emergency release code that is suppose to fix it all.) > I guess they are going to stop supporting that unit also. I just want to > trade it in or something, its a piece of garbage. > > -----Original Message----- > From: Eric Billeter <ebilleter@cableone.net> > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>; Todd Starkey > (E-mail) <Usman_Malik@mw.3com.com>; Kevin_musseau@3com.com > <Kevin_musseau@3com.com>; paul_mudlaff@mw.3com.com > <paul_mudlaff@mw.3com.com> > Date: Wednesday, October 14, 1998 8:38 PM > Subject: RE: (usr-tc) Web TV Help Needed > > > >I figger it's because if they actually admitted there was a > >problem with their code ( and provided a simple way of resolving > >the problems ) that people would lose faith in the product. So > >their current solution is to hide any known problems from the end > >users (ISPs), and pawn off the problem somewhere else. I would > >bet that half the staff at 3com aren't aware of the software > >updates, and that the other half would probably have you either > >reset to factory defaults or return the card for replacement. > > > >I am currently on hold with them, and the wait time is approximately > >one hour. Somehow I don't see how they expect me to renew my service > >contracts with them at the prices I was just quoted. Roughly 25% of > >the replacement cost seems a little out of line. Either they have so > >little faith in the product or it costs them that much to support it > >and/or it fails so much that the replacement costs are that high. Either > >way it speaks loads for the product in question. They might consider > >moving on to a seperate segment of the industry. > > > >If anyone has the code in question.. it would be greatly appreciated. > > > >BTW I am CC ing this to both my reseller and salesperson at 3com. > > > > > >Eric T. Billeter Cable One > >Internet Engineer 1314 North 3rd Street > >ebilleter@cableone.net Phoenix, AZ 85004 > >(602) 364-6462 > > > > > >-----Original Message----- > >From: owner-usr-tc@lists.xmission.com > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > >Sent: Sunday, October 11, 1998 2:21 PM > >To: usr-tc@lists.xmission.com > >Subject: Re: (usr-tc) Web TV Help Needed > > > > > >Someone was nice enough to send me the code. It worked great. Why is this > >not posted on their Total Service download site? > > > >Russ > > > >-----Original Message----- > >From: Richard Lorbieski <richard@mail.alpha1.net> > >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > >Date: Friday, October 09, 1998 3:38 PM > >Subject: Re: (usr-tc) Web TV Help Needed > > > > > >>Call USR support and request Hiper ARC ver. 4.1.78 > >>They send me a copy via email - but I have not install it :-(. > >> > >>Richard Lorbieski > >> > >>Russ Miescke wrote: > >>> > >>> Arter reading about various problems for the past couple of weeks with > >Web > >>> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and load > >it > >>> anyway. Bad move. Now all my Web TV customers are having problems > >>> connecting. I think I saw there was an fix released for this, but do > not > >>> know where to find it. Any help would be appreciated. > >>> > >>> Russ Miescke > >>> Power Web Connect > >>> russm@powerweb.net > >>> 920-885-7860 > >>> > >>> - > >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >>> with "unsubscribe usr-tc" in the body of the message. > >>> For information on digests or retrieving files and old messages send > >>> "help" to the same address. Do not use quotes in your message. > >> > >>- > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > >> with "unsubscribe usr-tc" in the body of the message. > >> For information on digests or retrieving files and old messages send > >> "help" to the same address. Do not use quotes in your message. > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Web TV Help Needed
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-16 09:26:02

Soon, Its a matter of few more days. The code is currently being tested. 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, 16 Oct 1998, Russ Miescke wrote: > The 4.1.78-4 code did work for the web tv problem, but you are right it does > create new ones with our radius and accounting (RadiusNT). It seems the > customers having the problem are, you guessed it .....Web TV along with NT > and MACs. Any ideas when the final fix will be out? > > > Russ Miescke > Power Web Connect > russm@powerweb.net > http://www.powerweb.net > > -----Original Message----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Brian Gordon <administrator@westelcom.com> > Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>; Lou Paris > <webmaster@westelcom.com>; Internet Technicians <internet@westelcom.com> > Date: Thursday, October 15, 1998 8:49 AM > Subject: Re: (usr-tc) Web TV Help Needed > > > On Wed, 14 Oct 1998, Brian Gordon wrote: > > > I don't know why its not posted on the Web Site. I was like the first one > > that found that WEB TV problem. I remember that Monday morning getting a > > notice that the code was out and I upgraded like at 8:00 am. Next thing I > > knew, I had like 50 Web TV people calling in..three days later a fix came > > out for it, and they emailed it to me. This should have been posted to > > their web site ASAP! > > > > The WebTV fix code 4.1.78-4 for the HiPer arc is currently available only > if you call support. There is a reason for this. This code as some of > you in this list have stated does have some problem with accounting > packets, and some have even reported problems with ISDN. Most of others > who are using this code did not have any problems to report. We would > have posted this code on the site if this code had all the fixes. > Currently you can get this code - just open a ticket with support. > We are in the process of getting these fixes rolled into a service > release which should be on the web site soon. > > krish > > > I am having similar unresolved issues with my Netserver 16 V.34+ in one of > > my small pops ,(Modems not resetting properly..hanging... etc. of course > > there is always some emergency release code that is suppose to fix it > all.) > > I guess they are going to stop supporting that unit also. I just want to > > trade it in or something, its a piece of garbage. > > > > -----Original Message----- > > From: Eric Billeter <ebilleter@cableone.net> > > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>; Todd Starkey > > (E-mail) <Usman_Malik@mw.3com.com>; Kevin_musseau@3com.com > > <Kevin_musseau@3com.com>; paul_mudlaff@mw.3com.com > > <paul_mudlaff@mw.3com.com> > > Date: Wednesday, October 14, 1998 8:38 PM > > Subject: RE: (usr-tc) Web TV Help Needed > > > > > > >I figger it's because if they actually admitted there was a > > >problem with their code ( and provided a simple way of resolving > > >the problems ) that people would lose faith in the product. So > > >their current solution is to hide any known problems from the end > > >users (ISPs), and pawn off the problem somewhere else. I would > > >bet that half the staff at 3com aren't aware of the software > > >updates, and that the other half would probably have you either > > >reset to factory defaults or return the card for replacement. > > > > > >I am currently on hold with them, and the wait time is approximately > > >one hour. Somehow I don't see how they expect me to renew my service > > >contracts with them at the prices I was just quoted. Roughly 25% of > > >the replacement cost seems a little out of line. Either they have so > > >little faith in the product or it costs them that much to support it > > >and/or it fails so much that the replacement costs are that high. Either > > >way it speaks loads for the product in question. They might consider > > >moving on to a seperate segment of the industry. > > > > > >If anyone has the code in question.. it would be greatly appreciated. > > > > > >BTW I am CC ing this to both my reseller and salesperson at 3com. > > > > > > > > >Eric T. Billeter Cable One > > >Internet Engineer 1314 North 3rd Street > > >ebilleter@cableone.net Phoenix, AZ 85004 > > >(602) 364-6462 > > > > > > > > >-----Original Message----- > > >From: owner-usr-tc@lists.xmission.com > > >[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Russ Miescke > > >Sent: Sunday, October 11, 1998 2:21 PM > > >To: usr-tc@lists.xmission.com > > >Subject: Re: (usr-tc) Web TV Help Needed > > > > > > > > >Someone was nice enough to send me the code. It worked great. Why is > this > > >not posted on their Total Service download site? > > > > > >Russ > > > > > >-----Original Message----- > > >From: Richard Lorbieski <richard@mail.alpha1.net> > > >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > > >Date: Friday, October 09, 1998 3:38 PM > > >Subject: Re: (usr-tc) Web TV Help Needed > > > > > > > > >>Call USR support and request Hiper ARC ver. 4.1.78 > > >>They send me a copy via email - but I have not install it :-(. > > >> > > >>Richard Lorbieski > > >> > > >>Russ Miescke wrote: > > >>> > > >>> Arter reading about various problems for the past couple of weeks with > > >Web > > >>> TV and the 4.1.11 code for the Hyper Arc, I chose to ignore it and > load > > >it > > >>> anyway. Bad move. Now all my Web TV customers are having problems > > >>> connecting. I think I saw there was an fix released for this, but do > > not > > >>> know where to find it. Any help would be appreciated. > > >>> > > >>> Russ Miescke > > >>> Power Web Connect > > >>> russm@powerweb.net > > >>> 920-885-7860 > > >>> > > >>> - > > >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > >>> with "unsubscribe usr-tc" in the body of the message. > > >>> For information on digests or retrieving files and old messages send > > >>> "help" to the same address. Do not use quotes in your message. > > >> > > >>- > > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > >> with "unsubscribe usr-tc" in the body of the message. > > >> For information on digests or retrieving files and old messages send > > >> "help" to the same address. Do not use quotes in your message. > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > > > >- > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Kingsley S. Grant <ksg@recorder.ca>
Date: 1998-10-16 09:44:17

I'm not sure if anyone has mentioned this before but 3Com is dropping support on the Netserver not because it is old hardware and it cannot be written to, but because the OS is livingston(lucent now) and when 3Com purchased USR livingston dropped support for the OS license (would not renew) to 3Com so it is against the law for 3Com to update the code any further on the OS level. 3Com according to my contacts is in court trying to get access to the new OS code but things do not look good at this time and have not for a while hence the reason for the creation of their Hiper card wich is 100% 3Com software OS. If! 3Com wins the court battle then you will get the updates for the Netserver if they lose you will not and will never. So it is the folks at Lucent who shold be getting the flame, Not 3Com. Just thought I would fill some people in on what is going on in the background. King. MegaZone wrote: > If Lucent can get OSPFv2 into the PM-2 with 4MB of RAM, 512K FLASH, and a > 386-33 (386-25 on older units) and have it work *VERY WELL* - then why can't > 3Com do something for the TC NS, which has a higher level of HW all around? > > -- Kingsley S. Grant RipNET Manager RipNET Internet Services 31 Broad Street Brockville ON, Canada K6V 4T9 (613) 342-3946 work (613) 342-8672 fax (613) 340-1144 Cel (613) 923-2596 Res (613) 341-0882 Pager 1-888-509-6677 E-Mail mailto:ksg@recorder.ca

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-16 09:47:30

Thus spake Kingsley S. Grant >I'm not sure if anyone has mentioned this before but 3Com is dropping >support on >the Netserver not because it is old hardware and it cannot be written to, but >because the OS is livingston(lucent now) and when 3Com purchased USR livingston >dropped support for the OS license (would not renew) to 3Com so it is >against the >law for 3Com to update the code any further on the OS level. Been mentioned several times...mostly be me. 3Com looses access to the ComOS source code on Dec. 31st. However, that's not *really* significant here. >3Com according to my contacts is in court trying to get access to the new >OS code >but things do not look good at this time and have not for a while hence >the reason >for the creation of their Hiper card wich is 100% 3Com software OS. If! >3Com wins >the court battle then you will get the updates for the Netserver if >they lose you >will not and will never. So it is the folks at Lucent who shold be getting the >flame, Not 3Com. > Just thought I would fill some people in on what is going on in the >background. Most of us are quite aware of that...thus the call by several of us to backport the Pilgrim, HiPerOS (whatever you want to call it) to the netserver hardware. Unless the code is just really hideous, the hardware should have the horsepower to run it, maybe even give it the ability to handle more ports if the code is really well written. Just because the software is going away doesn't mean the hardware has to. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-16 09:49:48

Thus spake Kingsley S. Grant >So it is the folks at Lucent who shold be getting the >flame, Not 3Com. Oh, and I'll save Megazone from having to flame you on this statement. Lucent and 3Com made a business decision and had a contract...the contract expired *LONG* ago. 3Com was the company that didn't have a backup plan in place, "Lucington" is just following what the contract said...they deserve no flames for this. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) framing issues on a t1
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-16 12:18:19

This is a multi-part message in MIME format. ------=_NextPart_000_00AB_01BDF8FF.0FEBC320 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To all the T1, switch, & CSU/DSU experts out there: I'm working with GTE to try to fix a T1 problem. Here's the background. = It's a fractional T1 terminating in one city. We have in place a = crossover cable to connect it to a point to point to take it to another = city. We have in place a HiPer DSP at the far end. We have verified = the DSP is fully functional by plugging a known good T1 into it. Here's = the problem: GTE went out to the other end of the point to point and tried to loop = us. We saw the carrier light on the HiPer DSP go green, but did not see = a loop. The GTE technician says he does not see framing coming back. = We havn't been able to get any further than this s far. Has anyone out there had a similar experience? Any ideas?=20 ------=_NextPart_000_00AB_01BDF8FF.0FEBC320 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.3509.100"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>To all the T1, switch, & CSU/DSU = experts out=20 there:</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>I'm working with GTE to try to fix a = T1=20 problem.  Here's the background.  It's a fractional T1 = terminating in=20 one city.  We have in place a crossover cable to connect it to a = point to=20 point to take it to another city.  We have in place a HiPer DSP at = the far=20 end.  We have verified the DSP is fully functional by plugging a = known good=20 T1 into it.  Here's the problem:</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2>GTE went out to the other end of the = point to=20 point and tried to loop us.  We saw the carrier light on the HiPer = DSP go=20 green, but did not see a loop.  The GTE technician says he does not = see=20 framing coming back.  We havn't been able to get any further than = this s=20 far.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>Has anyone out there had a similar=20 experience?  Any ideas? </FONT></DIV></BODY></HTML> ------=_NextPart_000_00AB_01BDF8FF.0FEBC320--

Subject: (usr-tc) Log Error Message
From: Greg Coffey <greg@coffey.com>
Date: 1998-10-16 12:48:37

We keep getting this error message in the log for one of our TC units. Oct 16 13:45:53 usr Received a request while not in server mode How do we fix it? ______________________________________________________ Thanks, Greg Coffey 307-234-5443 Fax 307-234-5446 CoffeyNet v.90 56k Access for Casper & Douglas 142 S. Center St. Casper, WY 82601 http://www.coffey.com

Subject: Re: (usr-tc) Radiator vs. Cistron
From: MegaZone <megazone@megazone.org>
Date: 1998-10-16 13:19:15

Once upon a time Jeff Mcadams shaped the electrons to say... >Thus spake Kingsley S. Grant >>So it is the folks at Lucent who shold be getting the >>flame, Not 3Com. >Oh, and I'll save Megazone from having to flame you on this statement. Thank you kind sir. :-) >Lucent and 3Com made a business decision and had a contract...the >contract expired *LONG* ago. 3Com was the company that didn't have a >backup plan in place, "Lucington" is just following what the contract >said...they deserve no flames for this. And anyone who knows the kind of games that were played to try to keep the code would laugh at the idea that Livingston/Lucent did anything wrong. Much of it I can't talk about, but enough has entered public record from other sources that I can myself comment on it. The contract expired long before USR and 3Com merged - there was a court case when USR refused to stop using it. Livingston sued them, they counter- sued, and it was settled with a *single* extension to the license. The merger happened during that extension. This is a matter of public record, as the court cases were publically announced. USR knew the code was going away for over a year before the first expiration and did nothing to replace it. The HiPer didn't appear for another 2 years. Then they got lucky and got another year on the source license - and again did nothing as USR, or then as 3Com. Rights to ship the binary expire a year from the source rights - I don't know if Dec 31st is it, as has been stated, but I do believe it is coming up shortly. They'll have had *3* years of forewarning by the time that happens - and apparently will have done nothing. Aside from releasing the HiPer and making that the only way to move forward. Oh - and to keep trying to tie the matter up in the courts so that they can keep using the code. Which is a slimeball tactic as far as I'm concerned. But it is a nice compliment to ComOS that they do so much to try to keep the rights to use it. ;-) -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: (usr-tc) TC NS, ComOS, HiPer, 3Com, USR, Livingston, Lucent, et al
From: MegaZone <megazone@megazone.org>
Date: 1998-10-16 13:37:42

Once upon a time Kingsley S. Grant shaped the electrons to say.., >I'm not sure if anyone has mentioned this before but 3Com is dropping support >the Netserver not because it is old hardware and it cannot be written to, but >because the OS is livingston(lucent now) and when 3Com purchased USR livingst >dropped support for the OS license (would not renew) to 3Com so it is against >law for 3Com to update the code any further on the OS level. Not only has this been mentioned again and again - but it is meaningless. 1. 3Com keeps claiming the reason IS the HW is old. We all know better, but that appears to be their official stance. "Oh, you don't really want us to keep working on that old stuff - buy a HiPer." 2. Who made the current OS is meaningless. It is a *3Com* product - it is there product to support and supply an OS for. There is nothing magic about the HW that would make it reject a non-ComOS based OS. Look at the NetServer 16 - the 4.x OS is NOT ComOS, it is new. A lot of people don't like it, but it works on the HW. They could do the same thing for the TC NS - but have decided not to. 3. This isn't a sudden move - and you have some facts wrong. Livingston decided not to renew the contract years ago, when they were preparing to ship the PM-3. Why supply an OS to a vendor who compete with you? And even before the PM-3, USR sales folks were taking away PM-2 sales - instead of buying say a PM-2 and a TC modem rack, they'd use the "Hey, it runs the same OS - just buy a TC NetServer" pitch. It was a business decision not to renew. That gave USR a year with the source, and an additiona year for the binary. That year ran out and USR was still using the source. So, Livingston took them to court - the press release may still be in the archive on their site. Let me see: Ah - here is hte PR on the settlement: <URL:http://www.livingston.com/marketing/press/usr_licensing_press.html> They extended the license in December of 1996. I believe that means the source license then ran out in December of 1997, and binary will run out in December of 1998. They've had nearly 2 years since *this* to do something - and keep in mind this happened because the first expiration was in *1995* - a year earlier. Hmm - all mentions of the suits seem to be purged - not surprising since it was settled though. But they were talked about at the time, so list archive may having something. Anyway, you can see that this wasn't some sudden move on Livingston's, or Lucent's, part because of the merger. This has been a long time coming. > 3Com according to my contacts is in court trying to get access to the new OS >but things do not look good at this time and have not for a while hence the re Sure - which they did last time too. But it was USR vs Livingston. When this suit started I believe it was 3Com vs Livingston - but now it is 3Com vs Lucent. 3Com might be able to bully a company the size of Livingston and soak them in court fees. But Lucent is a completely different ballgame. Anyway, the point is that no one cares that they lost the ComOS license. That is not the end of the game. They could have - still could - ported Pilgrim/HiPerOS to the TC NS. They have not, and are hand waving and claiming it is because of old HW. But knowledgable people know that is bunk - it is a business decision to EOL the TC NS, and try to sell more HiPers. Just like USR/3Com's "The FCC limits us to 53.3K" crap on consumer modems - when the limit is not on speed, but on power. And K56flex was getting 54K and even a rare 56K from time to time. X2 itself was later improved and hit at least 54.6K for many users. It was a deflection tactic - not "we rushed it and this is the best our code can do within the limits, at least for now" but "blame the FCC". Here it is not "we decided, as a business decision, to stop development on the TC NS" but rather "it is old hardware, and we've lost the source license, so we can't do anything more." -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: (usr-tc) Licensing code
From: MegaZone <megazone@megazone.org>
Date: 1998-10-16 13:51:27

Once upon a time David Bolen shaped the electrons to say... >cfb <cfb@ocn21.kdd-ok.ne.jp> writes: >> Then again, my general opinion of companies who license technology, so >> they too can cash in on a rapidly expanding market segment, is pretty >> low. Typically companies that license aren't offering their customers >> anything better and the licensing deal is usually structured so they >> can't offer it to the customer at a lower price. So, why bother? >A very good reason - it gets you in the door sooner (and presumably >more robustly) than locally developing something. David is right on here. It gets you in sooner - AND for critical components like a TCP/IP stack, or a T1 line driver, PRI state machines, etc, it may make a great deal more sense to acquire that code from a proven code house than to try to build it yourself. Do you think Lucent, Cisco, 3Com, Bay, et al, ALL right ALL of their own code? I know for a fact this is not the case. Aside from outright OEM deals (like the Cisco 1020 being a Livingston OR-M in different packaging, or the Cisco AS5100 being a TC with Cisco term server cards) there is a lot of code module user. Telenetworks is a well known name in this field for several low level issues. There are a number of modem code vendors for V.34 code that companies like Livingston would use to get modems off the ground. I expect we'll be seeing V.90 from the likes of them soon. This allows vendors to use HW they want and to possibly get code for less than licensing from one of the big 3. As well as avoiding having to build a modem code unit themselves. AND it should result in better code, as the 3rd party vendor should have more experience and a wider user base. I have no problem at all with USR licensing ComOS. I think it was a good move on their part. ComOS is a good, well respected OS. It let them get the NetServer products out long before they could have done so on their own. This was a good decision for them. My issues are more on matters of principle with how they are handling the other end of the products life. I strongly feel that they are treating their loyal customers very unfairly. And that they are blowing smoke and waving their hands around with unbelieviable answers about the HW being too old or weak. This has all the earmarks of a simple business decision on the part of 3Com to not invest in writing or porting an OS for the old HW. Period. I'd have more respect for them if they'd just admit it. It would still be a bad way to treat users, but at least it wouldn't be compounded. >Except that's not the case here. 3Com/USR didn't sell the TC >NETServer as "ComOS", so it's not like they were trying to sell units Well - some of their sales people did. I ran into that. When someone was about to buy a PM-2 or -25 and a TC for modems they'd use the fact that the NetServer ran ComOS to take away the PM sale and sell a NetServer module. I saw it a number of times, and it was a constant bitch from the sales folks. But as a corporation, no, they seemed to do their best to hide the fact ComOS was being used in their info. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) TC NS, ComOS, HiPer, 3Com, USR, Livingston, Lucent, et al
From: MegaZone <megazone@megazone.org>
Date: 1998-10-16 14:20:50

Once upon a time David Bolen shaped the electrons to say... >There wasn't any change - it was doing this from day 1. But it (nor You definitely have more experience here than I. I'd been told by some friends at Bay, who were working with their X2 license, that there were improvements in later X2 revisions which helped raise the speeds. >Sorry, this just doesn't match the NETServer item - with x2 USR was >simply first to come up with a working protocol/implementation, and I'm sorry, I didn't mean to imply the two scenarios had some kind of common history or evolution. I just picked two of the more obvious cased of deflection marketing - the modems and the dwindling TC NS support - as examples of the type of marketing moves, and not to draw any connections between the two events aside from that. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) New error messages for MPIP
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-16 14:22:42

Search on interproc http://interproc.ae.usr.com/tkb.html 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, 16 Oct 1998, Peter D. Mayer wrote: > Well, just after I installed 3.8.1 on all my NETServers MPIP was working > very well, but today I got the error messages below (first time I've seen > these errors). This is one of our customers attempting to connect to us > with a NetGear ISDN T/A Router combo. It happens every time they connect. > They said it worked fine until today, and I haven't changed anything with > our TC's. We are running MPIP on 1 NETServer for 7 boxes, all running > 3.8.1. Anyone have any ideas? > > I'm just about sick of MPIP in general. We just bought our first ARC, and > I'm interested to see if it's any better in controlling the MPIP bundles. > > Here are the logs: > Oct 16 14:12:38 tcs6 acct 0x00002164 dialnet: port I1 PPP succeeded dest > Negotiated > Oct 16 14:12:38 tcs6 dialnet: port I1 ppp_sync failed dest > Oct 16 14:12:39 tcs7 vtp_process_layer2_reg_request: Invalid MP Bundle gtxco > from Tunnel Agent 205.156.197.211 > Oct 16 14:12:39 tcs6 destroy_gre_tunnel: Unable to find Tunnel Agent > 205.156.197.213 for Tunnel Id 2 > Oct 16 14:12:39 tcs6 vtp_process_layer2_reg_response: Message received from > Tunnel Agent 205.156.197.213 for Port I1 Err=36 > > Thanks for any ideas, > 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. >

Subject: (usr-tc) New error messages for MPIP
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-16 15:05:07

Well, just after I installed 3.8.1 on all my NETServers MPIP was working very well, but today I got the error messages below (first time I've seen these errors). This is one of our customers attempting to connect to us with a NetGear ISDN T/A Router combo. It happens every time they connect. They said it worked fine until today, and I haven't changed anything with our TC's. We are running MPIP on 1 NETServer for 7 boxes, all running 3.8.1. Anyone have any ideas? I'm just about sick of MPIP in general. We just bought our first ARC, and I'm interested to see if it's any better in controlling the MPIP bundles. Here are the logs: Oct 16 14:12:38 tcs6 acct 0x00002164 dialnet: port I1 PPP succeeded dest Negotiated Oct 16 14:12:38 tcs6 dialnet: port I1 ppp_sync failed dest Oct 16 14:12:39 tcs7 vtp_process_layer2_reg_request: Invalid MP Bundle gtxco from Tunnel Agent 205.156.197.211 Oct 16 14:12:39 tcs6 destroy_gre_tunnel: Unable to find Tunnel Agent 205.156.197.213 for Tunnel Id 2 Oct 16 14:12:39 tcs6 vtp_process_layer2_reg_response: Message received from Tunnel Agent 205.156.197.213 for Port I1 Err=36 Thanks for any ideas, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Subject: Re: (usr-tc) New error messages for MPIP
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-16 15:12:46

Thus spake Peter D. Mayer >Well, just after I installed 3.8.1 on all my NETServers MPIP was working >very well, but today I got the error messages below (first time I've seen >these errors). This is one of our customers attempting to connect to us >with a NetGear ISDN T/A Router combo. It happens every time they connect. >They said it worked fine until today, and I haven't changed anything with >our TC's. We are running MPIP on 1 NETServer for 7 boxes, all running >3.8.1. Anyone have any ideas? Yeah, check out www.shreve.net/tcs and look at my issue that I entered. >I'm just about sick of MPIP in general. We just bought our first ARC, and >I'm interested to see if it's any better in controlling the MPIP bundles. No, its not...played with it yesterday...it has the same problem...seems to be inherent in the protocol. The error messages I got were different since I was using 3.7.76 and 3.7.24....they updated the messages in 3.8.1 to be more descriptive, same thing happening though. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-16 15:49:46

>>Lucent and 3Com made a business decision and had a contract...the >>contract expired *LONG* ago. 3Com was the company that didn't have a >>backup plan in place, "Lucington" is just following what the contract >>said...they deserve no flames for this. I can't understand how 3Com / USR could ever think that this, blaming the competition for their current crappy code, would ever work. The TCH system is horrible, I can't think of any way it could be worse and still provide the minimum level of usability that it needs to keep all of us from suing them our of business. The HiperAccess products are the worst I have ever seen. Example: 1) No way to get idle times extraced out of the unit for currently connected calls. Guess what? We know it has this information! It just will not give it up. 2) No easy to access a counter for total connect time per port. Guess what? We know it has this information! It just will not give it up. 3) Would a "show session" have killed them? "list conn", please... If 3Com wanted the Lucent code so badly why didn't they copy it's functionallity like and normal business would have done? To leave out features that are so obviously needed, if you are a large ISP and want to take control of your racks yourself, and then market it as a high density solution is just silly. I won't even start in on the complete lack of support owners of these units get!

Subject: Re: (usr-tc) Log Error Message
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-16 15:52:59

Thus spake Greg Coffey >We keep getting this error message in the log for one of our TC units. >Oct 16 13:45:53 usr Received a request while not in server mode >How do we fix it? Is this in reference to MPIP perhaps? Do you have MPIP servers set on any of your TC units? Check and make sure they're pointing to the right place? I remember having seen a similar message when having a netserver pointed to a netserver to get MPIP server service when the second netserver didn't have the MPIP server mode enabled. (did that convoluted sentence make sense?) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Radiator vs. Cistron
From: David Bolen <db3l@ans.net>
Date: 1998-10-16 15:59:12

cfb <cfb@ocn21.kdd-ok.ne.jp> writes: > Then again, my general opinion of companies who license technology, so > they too can cash in on a rapidly expanding market segment, is pretty > low. Typically companies that license aren't offering their customers > anything better and the licensing deal is usually structured so they > can't offer it to the customer at a lower price. So, why bother? A very good reason - it gets you in the door sooner (and presumably more robustly) than locally developing something. I have no complaints about how 3Com (then USR) went about this - they had a nice solid hardware platform, their local expertise was clearly on the modem front, and they used the contract with Lucent (then Livingston) to get a leg up on the terminal server front. To my mind, at the time, the TC rack was clearly superior to other equipment around (particularly in it's flashability and remote manageability) so that even though the NETServer code was basically just ComOS, the system as an integrated unit was more than just that component. Also, the whole issue of acquiring some components out of an integrated network system is pretty well established, and I would posit that it has in fact helped quite a bit in interoperability in many cases. I'm a big proponent of rolling your own code (as might be apparent to long time members of this list with respect to how I've designed our management of our TC deployment), but I don't have a problem acquiring reasonable chunks for components when appropriate. Take your typical TCP/IP stack - if I were developing a new device, I'd think long and hard about buying/acquiring someone else's stack rather than locally developing it - that's the kind of thing that needs a good real world workout to really ensure its robustness, and if you can avoid that learning curve in your product, that's great. Of course, for something like this there's already a commercial industry for embedded stacks, and the broad availability of BSD based kernels, but I think the approach scales to other sorts of products - such as the NETServer was in '94 - just one component out of an entire system. > "Soft" issues... Stammering managers who spout non-sense like "well, I > would have been fired if I had purchased Brand X instead of Brand Y". > When Brand Y has the same guts as Brand X, they deserved to be fired, > but for a much different reason. Except that's not the case here. 3Com/USR didn't sell the TC NETServer as "ComOS", so it's not like they were trying to sell units based on someone wanting to buy Livingston code, but from USR instead. It was my understanding at the time that 3Com was always planning to do their own thing, but this let them work on that in parallel while they had a working system. And that's where they are now - they have a perfectly acceptable (ignoring the issue of better or worse) new OS that is running on the HiperARC. Whether or not getting from a (then) to b (today) could have been achieved as well or differently is certainly debatable. But I don't think less of USR for making the deal, and choosing to take this route to reach where they are now. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) TC NS, ComOS, HiPer, 3Com, USR, Livingston, Lucent, et al
From: Curt Shambeau <curt@execpc.com>
Date: 1998-10-16 16:29:02

> Once upon a time David Bolen shaped the electrons to say... > >There wasn't any change - it was doing this from day 1. But it (nor > > You definitely have more experience here than I. I'd been told by some > friends at Bay, who were working with their X2 license, that there were > improvements in later X2 revisions which helped raise the speeds. That's probably X2 v2, which never really made daylight, because when it was ready, v.90 had already implemented all the improvements. X2 v2 would have meant a new client and server code. I think they finished the server side, but never really implemented the client side, because of v.90. My facts may be a little off, but I do remember some of the details. | Curtis V. Shambeau | curt@execpc.com | http://www.execpc.com/~curt | | Executive Vice President - Exec-PC, Inc. |

Subject: (usr-tc) Separating USR equipment on its own segment
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-16 16:43:01

On the topic of whining about Netservers supporting only RIP -- Our network has grown to the point that it stays very busy. The necessarily-incessant RIP broadcasts don't help anything. I've had an idea, and I'm looking for opinions: I'm considering putting all of our USR/3Com equipment on a segment of its own, and, further, a subnet of its own. To that end, I'm planning to buy ethernet hubs for all of it, renumber the devices themselves, and then connect them to a router. As such, the RIPv2 broadcasts will be confined to that network. And the router can redistribute RIP into OSPF for the rest of our equipment, so we won't even have to think about using RIP elsewhere on the network. These are the issues that I've considered -- - The netservers/ARCs will be on the same segment as the NMCs, thus satisfying the requirement specified in the NMC documentation - Some of our assigned IP address ranges are subnets out of the middle of other larger pools. The information from the USRs will have to be redistributed into another routing protocol to distribute this information - We'll have to put boxes on that subnet in order to trace network traffic - TCM &c. should work fine, as I understand its operation (It doesn't use directed broadcasts for host discovery, does it?) - This will increase the load on our router slightly, as it will have to forward data to our servers. (That traffic travels on a very-busy ethernet, now.) Any thoughts? It's not that big of an idea, I guess, but I'm hoping to get anyone's thoughts on it.

Subject: Re: (usr-tc) Separating USR equipment on its own segment
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-16 16:51:51

Thus spake Mark R. Lindsey > - Some of our assigned IP address ranges are subnets out > of the middle of other larger pools. The information from > the USRs will have to be redistributed into another > routing protocol to distribute this information Redistribute into OSPF...check. > - We'll have to put boxes on that subnet in order to trace > network traffic Eh...if that's important to you...sure...we don't worry about it. > - TCM &c. should work fine, as I understand its operation > (It doesn't use directed broadcasts for host discovery, > does it?) Nope, no directed broadcasts...they're evil anyway. Cisco config tip of the day. interface config mode: no ip directed-broadcast > - This will increase the load on our router slightly, > as it will have to forward data to our servers. > (That traffic travels on a very-busy ethernet, now.) If this kills your router...you need a bigger router anyway. :) >Any thoughts? It's not that big of an idea, I guess, but I'm >hoping to get anyone's thoughts on it. Pretty basic network design issue to deal with when you really get down to it...should be pretty easy to work out all the details...only took me a day or two to figure it all out and I'd never worked with OSPF before. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC NS, ComOS, HiPer, 3Com, USR, Livingston, Lucent, et
From: David Bolen <db3l@ans.net>
Date: 1998-10-16 16:53:23

MegaZone <megazone@megazone.org> writes: (removed ComOS items, to which I largely agree in fact if not necessarily tone :-)) > Just like USR/3Com's "The FCC limits us to 53.3K" crap on consumer modems - > when the limit is not on speed, but on power. Yeah, I hated that - but that was marketing, neither business/politics nor technical, which was the driver on the NETServer/ComOS. BTW, very similar comments were often made with respect to K56flex as well, so USR wasn't alone in this - they were just a bit more egregious than others. For example (random choice based on "K56flex" search on the Lucent site), at the bottom of the PM-3 announcement for the K56flex modems from Lucent (http://www.lucent.com:80/micro/NEWS/PRESS97/073197.html): "Actual speeds vary depending on line conditions. Due to FCC limitations, speeds in the U.S. are less than 56 kbits/s." > when the limit is not on speed, but on power. And K56flex was getting 54K > and even a rare 56K from time to time. So was x2. They just didn't want people complaining if it didn't. > X2 itself was later improved and > hit at least 54.6K for many users. There wasn't any change - it was doing this from day 1. But it (nor K56flex I'll bargain, but defer to you) was doing it for "many" users at any point. Stuff up above 52-53K is pretty rare - normally single or small single digits of percentages around the country. > It was a deflection tactic - not "we > rushed it and this is the best our code can do within the limits, at least > for now" but "blame the FCC". Sorry, this just doesn't match the NETServer item - with x2 USR was simply first to come up with a working protocol/implementation, and one that was more robust compared to the first K56flex implementations. It was locally developed, they were ahead of the other guys, and they just won this particular race. Different scenario entirely than the NETServer. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Separating USR equipment on its own segment
From: David Bolen <db3l@ans.net>
Date: 1998-10-16 16:59:45

mark@vielle.datasys.net (Mark R. Lindsey) writes: > Our network has grown to the point that it stays very busy. The > necessarily-incessant RIP broadcasts don't help anything. I've had an > idea, and I'm looking for opinions: I'm considering putting all of our > USR/3Com equipment on a segment of its own, and, further, a subnet of > its own. To that end, I'm planning to buy ethernet hubs for all of it, > renumber the devices themselves, and then connect them to a router. (...) > Any thoughts? It's not that big of an idea, I guess, but I'm > hoping to get anyone's thoughts on it. That's the only way we've designed our network from day one, although the benefit for the RIP stuff was not a primary focus in the design - in fact for the first year or so we didn't even support PPP dialup. All of our dialup equipment resides in racks (the granularity or scaling factor of the network) at sites which use routers to attach to the backbone. Each rack is a local ethernet, with it's own switch and router, although a few racks at a single site can be interconnected as a single ethernet segment to share an egress backbone router attachment. To the backbone, one of our dialup sites is just a multi-T1 or T3 attached customer. The entire ethernet and dialup space assigned to that site is routed by the backbone, but the dialup space is a static announcement maintained by the local site router (the site dialup prefix is statically routed to a nul interface on a Cisco) so users don't have any impact on backbone routing. The local router gets next hop information from the RIP announcements, but only uses that locally - no RIP information is redistributed into any of the backbone protocols. To my mind, it works very well, and keeps a nice firm separation between the dialup sites and equipment and the backbone. It also effectively obviates the whole need/desire for OSPF over RIP (heck, we're still using v1 at the moment with 32-bit announcements), although should OSPF be available there's nothing stopping from using it as an IGP for the dialup site. I'd probably still avoid infecting the backbone based on changing dialup routes at a local site though. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Radiator vs. Cistron
From: cfb <cfb@ocn21.kdd-ok.ne.jp>
Date: 1998-10-16 17:31:17

Jeff Mcadams wrote: > > Thus spake Kingsley S. Grant > >So it is the folks at Lucent who shold be getting the > >flame, Not 3Com. > > Oh, and I'll save Megazone from having to flame you on this statement. > > Lucent and 3Com made a business decision and had a contract...the > contract expired *LONG* ago. 3Com was the company that didn't have a > backup plan in place, "Lucington" is just following what the contract > said...they deserve no flames for this. I am somehow reminded of the Cabletron vs. Cisco spat that happened a few years ago... and that was just about a rouge entity in Cabletron's marketing department slamming cisco's gear, even though Cabletron had licensed the exact same equipment and code for their chassies. Personally, think the current 3Com vs. Lucent thing falls under the "not sh*iting in the bed you make" category. (a combination of "don't Sh*it where you sleep/eat" and "You must sleep in the bed you make") Then again, my general opinion of companies who license technology, so they too can cash in on a rapidly expanding market segment, is pretty low. Typically companies that license aren't offering their customers anything better and the licensing deal is usually structured so they can't offer it to the customer at a lower price. So, why bother? "Soft" issues... Stammering managers who spout non-sense like "well, I would have been fired if I had purchased Brand X instead of Brand Y". When Brand Y has the same guts as Brand X, they deserved to be fired, but for a much different reason. Companies who develop and stick to standards generally don't need to worry about the licensing, me-too want-ta-bees. Early adopters and market innovators are usually the ones who are rewarded the most in the end. People who make decisions to purchasing equipment based on "soft" factors should pay the price and usually do. Given the Rockwell-Lucent connection, I believe that Lucent knew a good deal in Livingston when they saw it. Is it really any surprise that Lucent has executed their acquired licensing agreement with 3Com to the tee? While purely anecdotal, it would be interesting to know just how much of the Livingston-3Com licensing agreement was disclosed prior to the Lucent acquisition. Maybe I have some of the timeline details wrong? I think we all know who the "winners" are in this particular market sector... What all of this has to do with "Radiator vs. Cistron" is beyond me.

Subject: Re: (usr-tc) TC NS, ComOS, HiPer, 3Com, USR, Livingston, Lucent, et
From: David Bolen <db3l@ans.net>
Date: 1998-10-16 17:33:03

MegaZone <megazone@megazone.org> writes: > You definitely have more experience here than I. I'd been told by some > friends at Bay, who were working with their X2 license, that there were > improvements in later X2 revisions which helped raise the speeds. Oh, I don't think I'd disagree with that - only that I don't think such improvements were a requirement to be able to achieve the higher speeds at all. I also tend to separate the idea of changes in the x2 protocol, versus changes in any specific implementation of that protocol. Certainly USR continued to work on their x2 client code (just as Rockwell/Lucent improved their K56flex client code) over time, but even in the very beginning the first USR clients could achieve the higher rates under the right (albeit unlikely) conditions. I suppose it's possible there might have also been some Bay-specific issues that weren't strictly protocol related, since they were doing their own implementation off of the spec. My involvement was purely with USR, and not any of the x2 licensees. > I just picked two of the more obvious cased of > deflection marketing - the modems and the dwindling TC NS support - as > examples of the type of marketing moves Good point - I was thinking more of the underlying NETServer drop issue, and not so much of how 3Com is _portraying_ that fact to customers. I'd agree the latter is probably marketing driven (a reasonable match to the portrayal of x2 rates), whereas the actual lack of support was probably an internal business decision (which I don't think maps to the x2 scenario much). Isn't this a "fun" industry :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) TC NS, ComOS, HiPer, 3Com, USR, Livingston, Lucent, et al
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-16 17:51:08

For those of you who have not read up on it: http://cnn.com/TECH/computing/9809/17/fcc.modems/ -----Original Message----- al >MegaZone <megazone@megazone.org> writes: > >> You definitely have more experience here than I. I'd been told by some >> friends at Bay, who were working with their X2 license, that there were >> improvements in later X2 revisions which helped raise the speeds. > >Oh, I don't think I'd disagree with that - only that I don't think >such improvements were a requirement to be able to achieve the higher >speeds at all. I also tend to separate the idea of changes in the x2 >protocol, versus changes in any specific implementation of that >protocol. > >Certainly USR continued to work on their x2 client code (just as >Rockwell/Lucent improved their K56flex client code) over time, but >even in the very beginning the first USR clients could achieve the >higher rates under the right (albeit unlikely) conditions. > >I suppose it's possible there might have also been some Bay-specific >issues that weren't strictly protocol related, since they were doing >their own implementation off of the spec. My involvement was purely >with USR, and not any of the x2 licensees. > >> I just picked two of the more obvious cased of >> deflection marketing - the modems and the dwindling TC NS support - as >> examples of the type of marketing moves > >Good point - I was thinking more of the underlying NETServer drop >issue, and not so much of how 3Com is _portraying_ that fact to >customers. I'd agree the latter is probably marketing driven (a >reasonable match to the portrayal of x2 rates), whereas the actual >lack of support was probably an internal business decision (which I >don't think maps to the x2 scenario much). > >Isn't this a "fun" industry :-) > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, 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. >

Subject: (usr-tc) TC Netserver discussion...observation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-17 09:13:42

You know...I find it amazing that in the course of this whole discussion about the NetServer and it's end of life'ing, that (if I remember correctly) *noone* from 3Com has commented. We've had some comments from former 3Com employees (Thanks Brian) but noone that works there now and can really come forth with current 3Com thoughts on this. I recently did a review of the addresses on the list...there are a not-insignificant number of 3com and USR addresses on the list, and that's understandable, what I don't understand, is that we get virtually no feedback from these folks...or 3Com much at all. In my experience, I can post a nice rant on this list (and usually cc: it to my sales rep) and get some calls and get in on some conference calls about my concerns, which is good...at least 3Com is making some effort to listen to our concerns and address them, but it seems that it would be much easier if 3Com would have a presense in fora such as this list, and by that, I mean, a two-way presense, not just listening. So, for the 3Com folks here... Feedback is important, I, at least, and I suspect many others here, feel like we're ranting into the wind and nothing is being heard. Particularly when we combine the lack of any feedback on list, whether that be explanation of why things are done as they are (and not excuses about lack of horsepower ;), or an indication that these issues are being addressed; and the lack of any indication in any other way that our issues are really being addressed. We got new hold music...and that's pretty cool...the virtual jukebox is a nifty idea...but lets face it...of the list of issues that were presented in the "gripe list" (whatever it was officially called) the hold music was pretty insignificant in the overall scheme of things. When you consider that the hold music (which was only half of an issue in the list), and MPIP in the HiPer ARC have been the only things that have really been dealt with. The hold times for tech support are down still...and have gotten reasonable, but the quality of the tech support when you do get through is still below standards. Maybe its improving...I haven't had many reasons to call tech support recently, I did have one call, and it wasn't all that encouraging ("I think you have a bad board, send it back"). Anyway...just pontificating on the whole state of affairs here. I'm not sure why we don't get feedback directly from 3Com here (they are participating in the totalservice newsgroups now at least), but it would be nice to see some sort of feedback on the issues we discuss outside of the specific technical help that we get from Tatai and Mike (and that is appreciated as well) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-17 09:49:17

Jeff, In regards to the NETServer a lot has been said and discussed. This is not the first time that you are talking about the NETServer and its cache etc. This discussion started - ended again started - ended and then comes back time and again. There is not point is discussing this. I agree with what David Bolen said in this list. As far as I am concerned there is no point in discussing with anyone in regards to this issue - this is a dead issue. The HiPer arc is here and it is the future. In regards to you calling support or complaining about any problem, we have - atleast I have either in email or by phone contacted you. In any of your problem irrespecitve of you cc-ing the sales people or not, there is someone from our support that replies. There are certain problem that we may miss or not reply in this list - but that is natural. It quite possible for me to miss one email off the 200+ emails I receive. That is the primary reason I did not want to join this discussion. It does not matter if the NETServer software or the hardware is the problem. We have HiPer arc and we shall concentrate on making this better and add feature that are requested. 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 Sat, 17 Oct 1998, Jeff Mcadams wrote: > You know...I find it amazing that in the course of this whole discussion > about the NetServer and it's end of life'ing, that (if I remember > correctly) *noone* from 3Com has commented. We've had some comments > from former 3Com employees (Thanks Brian) but noone that works there now > and can really come forth with current 3Com thoughts on this. > > I recently did a review of the addresses on the list...there are a > not-insignificant number of 3com and USR addresses on the list, and > that's understandable, what I don't understand, is that we get virtually > no feedback from these folks...or 3Com much at all. > > In my experience, I can post a nice rant on this list (and usually cc: > it to my sales rep) and get some calls and get in on some conference > calls about my concerns, which is good...at least 3Com is making some > effort to listen to our concerns and address them, but it seems that it > would be much easier if 3Com would have a presense in fora such as this > list, and by that, I mean, a two-way presense, not just listening. > > So, for the 3Com folks here... > > Feedback is important, I, at least, and I suspect many others here, feel > like we're ranting into the wind and nothing is being heard. > Particularly when we combine the lack of any feedback on list, whether > that be explanation of why things are done as they are (and not excuses > about lack of horsepower ;), or an indication that these issues are > being addressed; and the lack of any indication in any other way that > our issues are really being addressed. > > We got new hold music...and that's pretty cool...the virtual jukebox is > a nifty idea...but lets face it...of the list of issues that were > presented in the "gripe list" (whatever it was officially called) the > hold music was pretty insignificant in the overall scheme of things. > When you consider that the hold music (which was only half of an issue > in the list), and MPIP in the HiPer ARC have been the only things that > have really been dealt with. The hold times for tech support are down > still...and have gotten reasonable, but the quality of the tech support > when you do get through is still below standards. Maybe its > improving...I haven't had many reasons to call tech support recently, I > did have one call, and it wasn't all that encouraging ("I think you have > a bad board, send it back"). > > Anyway...just pontificating on the whole state of affairs here. > > I'm not sure why we don't get feedback directly from 3Com here (they are > participating in the totalservice newsgroups now at least), but it would > be nice to see some sort of feedback on the issues we discuss outside of > the specific technical help that we get from Tatai and Mike (and that is > appreciated as well) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-17 19:39:00

At 08:06 PM 10/17/98 -0400, Jeff Mcadams wrote: >Sorry...I'll no longer post to the list about this when this thread is >ended, but I *ASSURE* you, it is not a dead issue with me! 3Com *will* >be aware of my displeasure on this decision (I imagine many folks at >3Com already are). I've been demo'ing a HiPer Arc, and I have pretty >well determined at this point that, as off the 4.1.11 code release, we >will *NOT* be able to use the HiPer Arc for our dial-in server systems. >We either get more Netservers, or we go with another vendor. Jeff, I am new to this list and may have missed some of your previous comments. Can you give me a list of problems with the HiperArc? I have came up with a solution for some of it's shortcomings and may be able to help. If anyone has work arounds for the HiperArc, other than purchasing PM3 units - the thing we all should have done in the first place, please email me. I will be constructing a page for people like us that make things work even if they are inadequate. We all arn't about to throw away $10,000 without a fight.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-17 20:05:51

On Sun, 18 Oct 1998, Bob Purdon wrote: > > > I agree with what David Bolen said in this list. As far as I am > > concerned there is no point in discussing with anyone in regards to this > > issue - this is a dead issue. The HiPer arc is here and it is the future. > > Not for us it's not. We cannot afford the HiperARC. The last time I was > quoted on one I nearly fell off the chair. Trade up? Seems only US > customers were offered the trade up deal. > > If the NETserver is dropped then it'll be PM3 for us. It is your decision. I am only answering from the question Jeff asked. Why no one from 3com/USR was participating in this discussion? As far as the NETServer is concerned - whether its software or hardware - it has issues. The goal is to have HiPer arc without issues. krish > > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-17 20:06:21

Thus spake Tatai SV Krishnan >In regards to the NETServer a lot has been said and discussed. This is >not the first time that you are talking about the NETServer and its cache >etc. This discussion started - ended again started - ended and then >comes back time and again. There is not point is discussing this. Tatai, I didn't expect you to participate in this discussion...except for the possibility of coming forth with the *real* reason that the Netserver is being discontinued (not this "its underpowered" crap) >I agree with what David Bolen said in this list. As far as I am >concerned there is no point in discussing with anyone in regards to this >issue - this is a dead issue. The HiPer arc is here and it is the future. Sorry...I'll no longer post to the list about this when this thread is ended, but I *ASSURE* you, it is not a dead issue with me! 3Com *will* be aware of my displeasure on this decision (I imagine many folks at 3Com already are). I've been demo'ing a HiPer Arc, and I have pretty well determined at this point that, as off the 4.1.11 code release, we will *NOT* be able to use the HiPer Arc for our dial-in server systems. We either get more Netservers, or we go with another vendor. >In regards to you calling support or complaining about any problem, we >have - atleast I have either in email or by phone contacted you. I have gotten response from tech support, its still not the quality that I would like to see, but it is getting better. I mentioned the tech responses that we get on the list from you and Mike Wronski, and those are greatly appreciated. I'd *like* to see some more...uhm...."strategic" feedback from 3Com to the list. I know there are some people that are in rather strategic positions that are on the list, and I think its a shame that we don't hear from them. >In any of your problem irrespecitve of you cc-ing the sales people or >not, there is someone from our support that replies. I think all of my messages I have cc'ed to sales folks have been more general conceptual rants, not complaints about specific tech issues. As I said, you and Mike provide pretty good tech support on the list here. >It does not matter if the NETServer software or the >hardware is the problem. We have HiPer arc and we shall concentrate on >making this better and add feature that are requested. Then you are very likely to loose me as a customer then. This blind dismissal of the NetServer hardware product is a shame. If you have the opportunity, feel free to let anyone that deals with this issue know about my thoughts on this, I can guarentee you I will be letting Tom Goodman know. As always, I have nothing but the highest of praise for you and Mike Wronski in the job that you do. I do, however, think 3Com's handling of this, in general, has been pitiful. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-17 20:08:25

Thus spake Bob Purdon >> I agree with what David Bolen said in this list. As far as I am >> concerned there is no point in discussing with anyone in regards to this >> issue - this is a dead issue. The HiPer arc is here and it is the future. >Not for us it's not. We cannot afford the HiperARC. The last time I was >quoted on one I nearly fell off the chair. Trade up? Seems only US >customers were offered the trade up deal. >If the NETserver is dropped then it'll be PM3 for us. This is exactly the reason that I brought this up. 3Com *NEEDS* to realize how many customers they are *royally* pissing off by forsaking the NETServer hardware platform in this way. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: bryan s. blank <bryan@supernet.net>
Date: 1998-10-17 20:25:04

|o| >It does not matter if the NETServer software or the |o| >hardware is the problem. We have HiPer arc and we shall concentrate on |o| >making this better and add feature that are requested. |o| |o| Then you are very likely to loose me as a customer then. This blind |o| dismissal of the NetServer hardware product is a shame. If you have the |o| opportunity, feel free to let anyone that deals with this issue know |o| about my thoughts on this, I can guarentee you I will be letting Tom |o| Goodman know. As always, I have nothing but the highest of praise for |o| you and Mike Wronski in the job that you do. I do, however, think |o| 3Com's handling of this, in general, has been pitiful. i stand fully behind mr. mcadams in his comments. with his help, i have been able to recently make our netservers bearable, and save a good deal of money in what seemed like an almost necessary migration to a lucington environment. at this point, i'm ready to swap anyone's two netservers for my one hiperarc rack. ;) at some point, we all need to make decisions as to what path we are going to take. i do wonder if we're going to be able to change 3com's minds here. i've decided that the hiper is not the right platform for my shop, and it sounds like iglou is in the process of making a decision as to what they will start to use as they acquire more dial gear. maybe 3com isn't going to move on this decision. i am becoming more and more interested in what the chances of linux of *bsd on these racks are. mgetty, pppd, and gated are a very powerful combination. good luck everybody. |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-17 20:26:31

On Sat, 17 Oct 1998, Jeff Mcadams wrote: > Thus spake Tatai SV Krishnan > >In regards to the NETServer a lot has been said and discussed. This is > >not the first time that you are talking about the NETServer and its cache > >etc. This discussion started - ended again started - ended and then > >comes back time and again. There is not point is discussing this. > > Tatai, I didn't expect you to participate in this discussion...except > for the possibility of coming forth with the *real* reason that the > Netserver is being discontinued (not this "its underpowered" crap) > Jeff, irrespective - there are reason why we cannot comment on this issue. Strictly speaking its still a legal issue. All we know its a business decision, whether its good or bad its upto the management. > >I agree with what David Bolen said in this list. As far as I am > >concerned there is no point in discussing with anyone in regards to this > >issue - this is a dead issue. The HiPer arc is here and it is the future. > > Sorry...I'll no longer post to the list about this when this thread is > ended, but I *ASSURE* you, it is not a dead issue with me! 3Com *will* > be aware of my displeasure on this decision (I imagine many folks at > 3Com already are). I've been demo'ing a HiPer Arc, and I have pretty > well determined at this point that, as off the 4.1.11 code release, we > will *NOT* be able to use the HiPer Arc for our dial-in server systems. > We either get more Netservers, or we go with another vendor. No you should be free to post and this list is there only for such issues. Each and every customer has the right to say what he or she feels. The customer is right and it is a big concern. Your main point was about someone in 3com commenting on the list - that is what made me to reply. Your concerns are real and I only hope that management takes a look. But in no way or form do not think that I am trying to stop this discussion. All I wanted to say is that it is not practical for us ( from support ) to talk about this matter. > > >In regards to you calling support or complaining about any problem, we > >have - atleast I have either in email or by phone contacted you. > > I have gotten response from tech support, its still not the quality that > I would like to see, but it is getting better. I mentioned the tech > responses that we get on the list from you and Mike Wronski, and those > are greatly appreciated. I'd *like* to see some > more...uhm...."strategic" feedback from 3Com to the list. I know there > are some people that are in rather strategic positions that are on the > list, and I think its a shame that we don't hear from them. > Understood and will take up this with support managers. Ofcours if you do still experience problem do feel free to drop me an email. > >In any of your problem irrespecitve of you cc-ing the sales people or > >not, there is someone from our support that replies. > > I think all of my messages I have cc'ed to sales folks have been more > general conceptual rants, not complaints about specific tech issues. As > I said, you and Mike provide pretty good tech support on the list here. > Frankly we need more of support people to participate. > >It does not matter if the NETServer software or the > >hardware is the problem. We have HiPer arc and we shall concentrate on > >making this better and add feature that are requested. > > Then you are very likely to loose me as a customer then. This blind > dismissal of the NetServer hardware product is a shame. If you have the > opportunity, feel free to let anyone that deals with this issue know > about my thoughts on this, I can guarentee you I will be letting Tom > Goodman know. As always, I have nothing but the highest of praise for > you and Mike Wronski in the job that you do. I do, however, think > 3Com's handling of this, in general, has been pitiful. > -- NETServer as a product was not just a port from Livingston Comos to TC hub. A lot more than that. The Comos never had to deal with TDM bus or packet bus. A lot of development and a lot software development went into it. Unfortunately the technology transfer or you can call it Livingston/USR agreement did not go all very smoothly and we had problems. It is not fair to blame either of the company for all I can say is that I am not aware of all the problems. Yes this did lead to HiPer arc. So basically we did learn from our past. We were told that the new HiPer arc code will be ported the NETServer platform but then again I cannot comment on that either. Anyway - If its a support question and if you have problems do feel free. regards 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. >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-17 20:59:07

On Sun, 18 Oct 1998, Bob Purdon wrote: > > > > If the NETserver is dropped then it'll be PM3 for us. > > > > It is your decision. I am only answering from the question Jeff > > asked. Why no one from 3com/USR was participating in this discussion? > > As far as the NETServer is concerned - whether its software or > > hardware - it has issues. The goal is to have HiPer arc without > > issues. > > I understand that. The issue here is that (last time I checked) the > pricing for an empty HiPerARC chasis (card + chassis) here was so obscene > that the unloaded PM3 was MUCH cheaper. I am not sure what is the pricing of this card. I do know that the price was droped recently. I am not sure, will find from our Ausstralia office. > > We don't need 300+ ports per box - that's one of our points. 56 > ports/chassis suits us nicely. Sure, we could buy a HiPer bundle and put > 60 ports/box, but that's a horrendously expensive way of achieving the > same end. > Well it depends Some ISP require more ports some dont. When we first started with the NETServer we had two versions 24 port and 48 port. The 24 port did not go any where. People wanted more expansion capabilites. > Why would anyone want to have 60 port HiPer chassis'? Redundancy maybe? > That's certainly our reason. Our biggest POP has *three* (yes, only > three) NETserver based chassis. If one fails we can get by. No not for Redundance - ISP here and in Europe do see density as a big thing. The per port price has been droping and now you could buy more ports for the same price you may have paid for 48 port two/three years ago. > > If we had 180 ports worth of HiPer gear, in one chassis, and it fails... > No one can really give you a 100% gurantee. We can only go by statistics - I have seen installations with more than 300+ ports stable with HiPer arc. regards krish > Regards, > > Bob Purdon, > Technical Manager, > Southern Internet Services. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-17 22:52:41

At 08:06 PM 10/17/98 -0400, Jeff Mcadams wrote: > >Then you are very likely to loose me as a customer then. This blind >dismissal of the NetServer hardware product is a shame. I agree. And I have felt so for a long time feeling the NetServer was "dismissed" along time ago. I guess I ought to be thankful that we experienced the "Quake lag" problem so severely and bailed out of the NetServer along time ago. Apparently "fixing" Quake lag with HiperARC upgrades, "fixed" alot of future problems down the road. (note the sarcasm.. Quake lag was never fixed and there was no HiperARC upgrade!.. at least not back then) But Quake lag was a blessing in a nasty disguise.. <just basking in the irony of life> I really feel bad for you guys who have dozens or hundreds of these cards in service. We only had 4 or 5 and it cost us less than $12K to upgrade with some fancy legwork. That was a pretty good trick way back then.. We haven't seen a Quad or Netserver in almost a year (8mos?) and it's been great! We really like TCS now. And I'm sure you are happy for us and all (g), but here's my .02.. If there are any deficiencies in the HiperARC that prevent you from deployment over the NetServer, then you have two options. Urge 3COM to eliminate the deficiency in a reasonable time frame, or chose another vendor. Given a situation such as this, they would be crazy not to jump on it. After all, it's an "upgrade" and not a "downgrade" right? If you can't afford to upgrade, then you probably can't afford to switch vendors also.. Personally I just wouldn't quit until the "mission" was accomplished. I fought hard to get 3COM to be fair about this and have put forth considerable effort to get our ARCS by calling Tom Goodman and all the reps I could think of, selling equipment at a good price, working on the Top Ten List and letting my feelings be known, etc. Much of this would have to be done to switch vendors anyway.. I just feel that sometimes you get what you work for, not what you pay for.. USR/3COM handled the migration to arcs in a horrible manner and I won't soon forget that. In the beginning, there was the ARC for $6K. We bought one. HDM's for $6K.. We bought two. Need another chassis for those HDM's? another $4K. Then all of a sudden, unbelievable bundle announcements.. For $10.5K, you get a fully equipped chassis! <feeling pretty stupid> We bought more.. and so forth.. All in all, we spent at least $12K (don't really want to add it all up) selling off NetServer bundles with no official upgrade path or "Quake Lag Upgrade Kit" as I liked to call it.. Then after all my fancy legwork, they announce one. a sucky one.. so I wasn't angry about missing it. I think we did better just buying/selling on the open market to eliminate our woes months earlier.. I've never been so patient or forgiving but once it's all over, life is pretty sweet. We are solid and scaleable now.. As long as the new SS7 stuff doesn't antiquate what we have, we will be in good shape for a long time. So out with the old and in with the new! Jumping onto HiperARC's shouldn't cost more than selling NetServers and buying PM's.. either way, you probably aren't going to get much for the Netservers nowadays.. What is the current upgrade cost now? $3,500?? Should be able to find some folks with extra ones leftover from bundle harvesting for less maybe.. be resourceful, do alot of homework, and write the President of 3COM if you have to. But give them the chance to loose a customer or not. This puts the ball in their hands so the decision on what to do becomes easier.. (Of course, by that standard, we would have switched ;) Funny, I've never really been that much of an activist, a "loud customer", or very hard to please.. Nor have I really been patient either. But I really wanted to give 3COM the chance to do a good job. And I feel it paid off. At a tolerable cost. At the time, I think I just didn't want to prove MZ right and make him happy.. ;) Good Luck.. Allen >If you have the >opportunity, feel free to let anyone that deals with this issue know >about my thoughts on this, I can guarentee you I will be letting Tom >Goodman know. As always, I have nothing but the highest of praise for >you and Mike Wronski in the job that you do. I do, however, think >3Com's handling of this, in general, has been pitiful. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-17 23:53:52

At 03:23 PM 10/18/98 +1100, Bob Purdon wrote: > >> If you can't afford to upgrade, then you probably can't afford >> to switch vendors also.. > >Why should we pay to upgrade though? Our NETservers are barely 18 months >old. We were intending to get 3-4 years out of the NETservers before >upgrading. We're happy with the NETserver based solution and certainly >have no interested in shelling out more $$$ on the existing equipment. understood. I guess at the time I had my "feet to the fire" with user complaints about Quake lag. So I had strong daily incentive to fix the problem or else bleed customers to competitors. I also felt that there was a window in there between the introduction of the $10K bundle and when the bottom would drop out on the netserver market while people migrated to hiperarcs. Apparently I timed things right for our market over here and it really didn't cost that much.. Except for the first chassis, our cost for upgrade averaged $1500 per chassis. And we got HDM's in the process which shouldn't be overlooked. We like the higher densities cause we only have one big pop. (and limited A/C) > >> Jumping onto HiperARC's shouldn't cost more than selling NetServers >> and buying PM's.. > >If you live in the US maybe... If my memory is correct, I was quoted $14k >for an ARC and $14k for DSP cards. Even 30 ports worth of quads costs >under $12k. Ouch. What happens if you "mail ordered" some bundles from the U.S. and just pay customs? Are your import taxes just that high? I used to manufacture hardware and ship it all over the planet. It's no big deal 'cept politically.. Distributors and Dealers can be *very* territorial (and loud on the phone!). But there is always ways around that isn't there? ;) > >As for your cheap bundles over there - I wish. An ex-eval chassis, with >one quad, one NETserver and dual power supplies cost us $7k, plus another >$3k for the PRI card (already had a spare NMC). > >> What is the current upgrade cost now? $3,500?? > >The procedure here, apparently, is that you pull your NETserver, throw it >in the bin, and buy a shiny new $14k ARC. Upgrades? Trade-ups? Bundles? >Nobody's ever mentioned them here, and when I ask it falls on deaf ears... I can't believe that. I mean I'm sorry to hear that.. Why not visit the U.S. and buy some chassis "at the store" and bring em home to ma ma? Should get a free trip out of it anyways.. :) Seriously, if the import taxes are that steep, and you don't want to go into smuggling, then you are screwed. But if the distributors and/or 3COM are just ballzee, then there are ways to deal with that I'm sure.. Just use your imagination. You could really save some money on the used U.S. market I bet.. If you like netservers, i've heard of them going used for $3500.. But $9.5K for a new Hiper chassis is what I'd recommend. Buy em and harvest what you need to put where.. We have a stack of empty chassis I'll sell cheap.. all we ever seem to need are more HDM's and ARC's.. Is there any law saying I can't sell you equipment and ship it to you? Even if I have to buy it first and make a couple of hundred bux? If so, I'm unaware of it.. but again if it's import taxes then I understand.. Paying telco in Louisiana is enough torture for me.. Paying 14K for a damn ARC and tossing the Netserver in the trash would be murder.. However you would probably not sympathize with my telco bill either. ;) Allen > >Regards, > >Bob Purdon, >Technical Manager, >Southern Internet Services. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-18 00:16:48

Tatai SV Krishnan was heard to say: >Why no one from 3com/USR was participating in this discussion? As far as >the NETServer is concerned - whether its software or hardware - it has >issues. The goal is to have HiPer arc without issues. If the hiper ARC is so bloody powerful, why are you guys using a @%@#$ NT "box" for VoIP? I would have to say using NT-RAS is about the single stupidest thing could EVER be done. NT is not (and never has been) the answer to anything. (When M$ removes the GUI from the NT kernel, then I'll look at.) --Ricky

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-18 00:32:06

Bob Purdon was heard to say: >I understand that. The issue here is that (last time I checked) the >pricing for an empty HiPerARC chasis (card + chassis) here was so obscene >that the unloaded PM3 was MUCH cheaper. 3Com's pricing on almost everything has been insane... >We don't need 300+ ports per box - that's one of our points. 56 >ports/chassis suits us nicely. Sure, we could buy a HiPer bundle and put >60 ports/box, but that's a horrendously expensive way of achieving the >same end. 3Com seems to think people will use Netserver 16's and crap for the "low end" systems? The TC hardware with 48-60 modems is perfect for a vast majority of users. Only when you start backhauling dialtone, or otherwise have thousands of customers dialing into a POP does the high density hiperDSP setups make any sense. For a POP that needs 100 modems, it's sort of a waste to have a TC chassis with only 4 cards in it. Sure, it provides alot of expansion room... >Why would anyone want to have 60 port HiPer chassis'? Redundancy maybe? >That's certainly our reason. Our biggest POP has *three* (yes, only >three) NETserver based chassis. If one fails we can get by. And Interpath has only a handful of POPs with more than one chassis. Only on POP would fill a hiper chassis (14 PRI.) >If we had 180 ports worth of HiPer gear, in one chassis, and it fails... In all honesty, how mant _chassises_ have you had fail? Lots of NIC cards die -- I assume it's power spikes on the telco lines? A few NAC cards die. But, out of 47 chassises, (knock on wood) none of the chassises have ever failed. (I've had to reseat cards on occasion, but that's not a serious issue.) FWIW, I like the hiperARC. It really is *alot* better than the netserver. --Ricky

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-18 01:23:59

At 03:43 PM 10/18/98 +1100, Bob Purdon wrote: > >> In all honesty, how mant _chassises_ have you had fail? Lots of NIC >> cards die -- I assume it's power spikes on the telco lines? A few NAC >> cards die. But, out of 47 chassises, (knock on wood) none of the >> chassises have ever failed. (I've had to reseat cards on occasion, >> but that's not a serious issue.) > >None yet, but given past experience, none here too. very good hardware.. >would you trust 3COM's service people >to get parts to you on time? nope. but I wouldn't trust cisco or anyone if it were really critical. better to be safe than sorry.. and a bird in the hand is worth two in the warehouse.. ;) > >Our last experience with 3COM service was atrocious. On that occasion our >expectation may have been a bit high, and their warranty cover a bit poor, >but still, the crap we had to go through appeared to be the same as a >normal maintenance claim/request. Atrocious is a good word. We purchased a service contract from Source with a bundle back in March at ISPCON. We *still* can't get the contract "activated" seven months later! This is because we didn't purchase half a dozen contracts for all our gear or some BS. It's a long story.. But the bottom line is that we don't care so much. I don't want to be at anyones mercy and I constantly work to achieve independance of sorts. from the telco, 3COM, whoever want's us to rely on them without question. We really don't need the contract because of this list, an overall lack of problems, a smart admin, and a couple of really nice engineers at 3COM who really care. Combine this with a reliable hardware platform, and the fact that we had to run beta code anyway to get MPIP, and we really don't need total support for much.. at least not now. Someday I hope that total support won't be burdened and support contracts might be very profitable. And the contracts worth purchasing. Everyone wins. If the hardware is good, and your customers are happy, then tech support gets the benefits of design engineers good ideas and labor. lots of snowball effects and intertwined relationships here. > >We did learn that the serial numbers reported by TCM are no longer >acceptable as they're not long enough. Then they thought it'd be cool for >us to drive around the state taking photos of each card, scanning them, >and sending them to Singapore so they could read the serial number >themselves. Didn't matter that this was a 1000km round trip. > >This doesn't leave us with any real confidence in any maintenance >contract, despite it (when they finally activate it) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ hehe.. It will be over by the time they activate it.. for us anyway.. Allen

Subject: Re: (usr-tc) TC Netserver discussion...observationy
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-18 01:32:23

Bob Purdon was heard to say: >> In all honesty, how mant _chassises_ have you had fail? Lots of NIC >> cards die -- I assume it's power spikes on the telco lines? A few NAC >> cards die. But, out of 47 chassises, (knock on wood) none of the >> chassises have ever failed. (I've had to reseat cards on occasion, >> but that's not a serious issue.) > >None yet, but given past experience, would you trust 3COM's service people >to get parts to you on time? Never have... that's why I keep in-house spares :-) Any downtime at all is generally not acceptable. --Ricky

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-18 08:05:07

Thus spake Tatai SV Krishnan >On Sun, 18 Oct 1998, Bob Purdon wrote: >> We don't need 300+ ports per box - that's one of our points. 56 >> ports/chassis suits us nicely. Sure, we could buy a HiPer bundle and put >> 60 ports/box, but that's a horrendously expensive way of achieving the >> same end. >Well it depends Some ISP require more ports some dont. This is exactly my point right here. Some ISPs require high density and would buy HiPer equipment...I'd even say many would...but *some* ISP's don't need this density (in fact it can be considered a drawback) and would prefer to keep buying the quad/netserver types of bundles. For IgLou's case? We'd probably buy both depending on our needs for deployment. In some places, we could really use the high density stuff, in other cities (ie, where we just started POPs) we'd much rather have the lower-density stuff. >When we first >started with the NETServer we had two versions 24 port and 48 port. The >24 port did not go any where. People wanted more expansion capabilites. More expansion capabilities are good, and if I get a quad/netserver chassis, I can pop in some hiper dsp's and hiper arcs into the same chassis and expand it farther. But when I'm starting a new POP, I don't want to put HiPer stuff in it to start with...its a waste of money, and honestly, its rather difficult to manage at that low of port density. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-18 08:25:28

Thus spake Tatai SV Krishnan >On Sat, 17 Oct 1998, Jeff Mcadams wrote: >> Tatai, I didn't expect you to participate in this discussion...except >> for the possibility of coming forth with the *real* reason that the >> Netserver is being discontinued (not this "its underpowered" crap) >Jeff, irrespective - there are reason why we cannot comment on this >issue. Strictly speaking its still a legal issue. All we know its a >business decision, whether its good or bad its upto the management. The only legal issue that I'm aware of with respect to the NETServer is with the software, and I understand that. As I said earlier though, just because the software is going away doesn't mean the hardware has to. Pilgrim should run quite well on a 486/100, that's been my suggestion all along. >All I wanted to say is that it is not practical for us ( >from support ) to talk about this matter. I understand that completely...I didn't expect any participation from support people on this...its not your realm to deal with. :) There are quite a few other people from USR/3Com on the list though that this would fit more into their realm. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-18 08:52:50

> I agree with what David Bolen said in this list. As far as I am > concerned there is no point in discussing with anyone in regards to this > issue - this is a dead issue. The HiPer arc is here and it is the future. Not for us it's not. We cannot afford the HiperARC. The last time I was quoted on one I nearly fell off the chair. Trade up? Seems only US customers were offered the trade up deal. If the NETserver is dropped then it'll be PM3 for us. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-18 09:24:58

On Sun, 18 Oct 1998, Ricky Beam wrote: > Tatai SV Krishnan was heard to say: > >Why no one from 3com/USR was participating in this discussion? As far as > >the NETServer is concerned - whether its software or hardware - it has > >issues. The goal is to have HiPer arc without issues. > > If the hiper ARC is so bloody powerful, why are you guys using a @%@#$ > NT "box" for VoIP? I would have to say using NT-RAS is about the single > stupidest thing could EVER be done. NT is not (and never has been) the > answer to anything. (When M$ removes the GUI from the NT kernel, then > I'll look at.) Ricky, If you do not like @#@$@$ NT its again your problem. This has nothing to do with either HiPer arc being powerful or not. AT this point using NT is the best bet per management. It is quite possible that you may see this with HIPer. Again this has nothing to do whether HiPer is powerful or not. HiPer is aimed to be the NETServer + capable of having new features., regards krish > > --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. >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-18 09:47:03

-----Original Message----- >>On Sun, 18 Oct 1998, Bob Purdon wrote: >>> We don't need 300+ ports per box - that's one of our points. 56 >>> ports/chassis suits us nicely. Sure, we could buy a HiPer bundle and put >>> 60 ports/box, but that's a horrendously expensive way of achieving the >>> same end. >>Well it depends Some ISP require more ports some dont. > >This is exactly my point right here. Some ISPs require high density and >would buy HiPer equipment...I'd even say many would...but *some* ISP's >don't need this density (in fact it can be considered a drawback) and >would prefer to keep buying the quad/netserver types of bundles. For >IgLou's case? We'd probably buy both depending on our needs for >deployment. In some places, we could really use the high density stuff, >in other cities (ie, where we just started POPs) we'd much rather have >the lower-density stuff. Well, the way I see it is this: a 48 port HiPer bundle costs roughly half what I paid for a 48 port NETServer/Quad/PRI card bundle a little more than a year ago, and roughly the same as what you can find a full NETServer bundle for now (a bit more). I personally (for almost the same price) would rather have the fuller and more extensible feature set of the ARC (not to mention performance), as well as the capability to expand without big hassles (pop in a card, not a new chassis). My rack space is limited so I'm all for something that fits in 1/8th the space. I would especially use this somewhere that I've just installed a POP, because the growth rate is an unknown. If I never install more than the first 48 ports, it's no big loss, but if it grows beyond that, I'd just pop in a new HDM and go. I agree it sucks that there will be no more software revisions for the NETServer, but we very rarely have any problems with any of that equipment, and I forsee it serving a useful purpose in our organization for 2-5 years to come, even without software upgrades. The only real issue I've ever had with the NETServers is MPIP, and that still plagues us to this day. From what I've heard the ARC does no better with it (I'm trying it next week), so I guess it remains at the top of my gripe list no matter what the platform. Oh well, I hope this thread ends soon, because my mail client groans now everytime I check mail :) Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Subject: RE: (usr-tc) TC Netserver discussion...observation
From: Steve McConnell <stevem@magneto.emji.net>
Date: 1998-10-18 11:03:17

> The hold times for tech support are down >still...and have gotten reasonable, speak for yourself. last week I waited for 4 hours (I got cut off 3 times when they tried to pick me up, and then they blamed it on me when I told them about it) and finally just went off on some poor CSR and she got someone on the line. >quality of the tech support when you do get through is still below >standards totally agree, I should not know more than tech support about the product, expecially as I know I am an idiot at times, but the last two times I had a problem I figured it out right after they decided to replace half the chassis. just my .02 steve Steve McConnell EMJ Internet mailto:stevem@emji.net http://www.emji.net 919-363-4441x126 919-363-4425 FAX

Subject: (usr-tc) New to list and USR, how do I upgrade TC modems?
From: Jake Messinger <jake@ams.com>
Date: 1998-10-18 11:27:42

Hi, Im new to the list. Ive read over the USR/3com website and Im just not sure how I can upgrade these Total Control modems I have. Let me tell you the hardware: 1 USR total control chassis 20 USR analog/digital quad modem cards, various revisions 20 analog/digital quad modem connectors (no other cards) I have the firmware for a couple of the revisions. What else do I need to upgrade the modems? What/where is the procedure? Keep in mind I do not have any nmc cards or anything with an ethernet cable connected to the TC rack. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-18 11:28:43

Hi, Perhaps it's time for another "top 10" list. It seems the only people here that have received and acknowledgement or resolution to their problems are those that have pestered various 3com folks vigorously. I suggest gathering a list of issues and then sharing our contacts and distributing the list to as many 3com sales/marketing people and resellers as we can. As an ISP that is currently looking to do another dialup push, we are looking to double capacity from 6 NetServer and 1 Arc chassis. That means we can reasonably consider other vendors again... I assume there are others in this position, and it's to everyone's benefit to communicate directly to sales that they are in danger of losing some of their current sales relationships. Here's a sampling of things I'd like to see on the list: - Tech Support. It still blows. I want, at level one, someone who understands basic troubleshooting. I want courtesy and respect from the tech staff. I do not want someone who knows less than I do asking for full access to my chassis. Troubleshoot *with* me, not for me. - MPIP. Getting alot of calls about this. From what I gather it does not work well in the NetServers and is in beta on the ARC. - Software. There needs to be better access to emergency fixes like the recent WebTV fix. - Support Contracts. There is *no* justification for the price. I think most of you will agree that Cisco is one of the priciest vendors around. However, a 24x7x4 support/service contract on a router worth $60,000 is only $1300. This includes full access to software, tech support (very good support as well), an excellent web site for educating yourself on the product and it's features, and 4 hour replacement of any failed component. They also do not require me to get coverage on other Cisco products that I own. Is it just me, or is charging 1/3 of the purchase price for support criminal? I think the policy of requiring a contract on all pieces is just barely legal. What if I have a toasted quad chassis that I use for testing? Why am I required to pay for support on that to get support on my production chassis? And what about those who choose not to get a contract? If I bought an ARC three months ago and want to use an advertised feature (MPIP), upgrade to the final v.90 card that meets the ratified v.90 spec, and have all the bugs worked out I *can't*. I've paid the price for the advertised product, but without paying more money, I can't have the product do what it was promised to do. - Follow-Through. 3com/USR has turned around and screwed early adopters again and again. I won't go into this too much, because I know many of you that bought when X2 came out or when the ARC was released feel the burn. 3com at least should be buying some vaseline for this process. I understand this is 'business', but customer loyalty can be gotten in numerous ways. I would never ever recommend this stuff to someone. Not so much for any product flaws, but due to the attitude in management. They seem to be in this for the quick money and have little or no interest in generating long term relationships with customers. That's scary in this business. With development moving at the pace it does these days, the customer needs assurance that he/she is valuable as a customer. See, my list is short ;) Now, we all have some contacts at 3com, and some of us even have some friends in the trade press. I'd very much like to put together the collective feelings you folks have and forward them on to as many of those contacts as possible. We deserve better than this. Charles On Sat, 17 Oct 1998, Allen Marsalis wrote: > Date: Sat, 17 Oct 1998 22:52:41 -0500 > From: Allen Marsalis <am@shreve.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) TC Netserver discussion...observation > > At 08:06 PM 10/17/98 -0400, Jeff Mcadams wrote: > > > >Then you are very likely to loose me as a customer then. This blind > >dismissal of the NetServer hardware product is a shame. > > I agree. And I have felt so for a long time feeling the NetServer > was "dismissed" along time ago. I guess I ought to be thankful that > we experienced the "Quake lag" problem so severely and bailed out of > the NetServer along time ago. Apparently "fixing" Quake lag with > HiperARC upgrades, "fixed" alot of future problems down the road. > (note the sarcasm.. Quake lag was never fixed and there was no > HiperARC upgrade!.. at least not back then) But Quake lag was a > blessing in a nasty disguise.. <just basking in the irony of life> > > I really feel bad for you guys who have dozens or hundreds of these > cards in service. We only had 4 or 5 and it cost us less than > $12K to upgrade with some fancy legwork. That was a pretty good > trick way back then.. We haven't seen a Quad or Netserver in > almost a year (8mos?) and it's been great! We really like TCS now. > And I'm sure you are happy for us and all (g), but here's my .02.. > > If there are any deficiencies in the HiperARC that prevent you > from deployment over the NetServer, then you have two options. > Urge 3COM to eliminate the deficiency in a reasonable time frame, > or chose another vendor. Given a situation such as this, they > would be crazy not to jump on it. After all, it's an "upgrade" > and not a "downgrade" right? > > If you can't afford to upgrade, then you probably can't afford > to switch vendors also.. Personally I just wouldn't quit until > the "mission" was accomplished. I fought hard to get 3COM to > be fair about this and have put forth considerable effort to > get our ARCS by calling Tom Goodman and all the reps I could > think of, selling equipment at a good price, working on the Top > Ten List and letting my feelings be known, etc. Much of this > would have to be done to switch vendors anyway.. I just feel > that sometimes you get what you work for, not what you pay for.. > > USR/3COM handled the migration to arcs in a horrible manner > and I won't soon forget that. In the beginning, there was > the ARC for $6K. We bought one. HDM's for $6K.. We bought > two. Need another chassis for those HDM's? another $4K. Then > all of a sudden, unbelievable bundle announcements.. For $10.5K, > you get a fully equipped chassis! <feeling pretty stupid> > We bought more.. and so forth.. > > All in all, we spent at least $12K (don't really want to add it > all up) selling off NetServer bundles with no official upgrade path > or "Quake Lag Upgrade Kit" as I liked to call it.. Then after all > my fancy legwork, they announce one. a sucky one.. so I wasn't angry > about missing it. I think we did better just buying/selling on the open > market to eliminate our woes months earlier.. > > I've never been so patient or forgiving but once it's all over, > life is pretty sweet. We are solid and scaleable now.. As long as > the new SS7 stuff doesn't antiquate what we have, we will be in good > shape for a long time. > > So out with the old and in with the new! Jumping onto HiperARC's > shouldn't cost more than selling NetServers and buying PM's.. > either way, you probably aren't going to get much for the Netservers > nowadays.. > > What is the current upgrade cost now? $3,500?? Should be able to > find some folks with extra ones leftover from bundle harvesting for less > maybe.. be resourceful, do alot of homework, and write the President > of 3COM if you have to. But give them the chance to loose a customer > or not. This puts the ball in their hands so the decision on what to > do becomes easier.. (Of course, by that standard, we would have switched ;) > > Funny, I've never really been that much of an activist, a "loud customer", > or very hard to please.. Nor have I really been patient either. But > I really wanted to give 3COM the chance to do a good job. And I feel > it paid off. At a tolerable cost. At the time, I think I just didn't > want to prove MZ right and make him happy.. ;) Good Luck.. > > Allen > > >If you have the > >opportunity, feel free to let anyone that deals with this issue know > >about my thoughts on this, I can guarentee you I will be letting Tom > >Goodman know. As always, I have nothing but the highest of praise for > >you and Mike Wronski in the job that you do. I do, however, think > >3Com's handling of this, in general, has been pitiful. > >-- > >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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: (usr-tc) Is the USR Netserver 8i+ any good?
From: Jake Messinger <jake@ams.com>
Date: 1998-10-18 11:29:17

A fellow wants to sell me a used USR Netserver 8i+. Is it any good? I want to feed bri's into an access server and be able to give isdn and/or 56k service on each channel of the BRI circuits. I have a radius server. What would a 6 month old unit be worth? ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-18 11:51:46

On Sun, 18 Oct 1998, Jake Messinger wrote: > Hi, Im new to the list. > > Ive read over the USR/3com website and Im just not sure how I can upgrade > these Total Control modems I have. Let me tell you the hardware: > > 1 USR total control chassis > 20 USR analog/digital quad modem cards, various revisions > 20 analog/digital quad modem connectors > (no other cards) > > I have the firmware for a couple of the revisions. What else do I need to > upgrade the modems? What/where is the procedure? Keep in mind I do not > have any nmc cards or anything with an ethernet cable connected to the TC > rack. You can upgrade no problem but since you have n NMC you must basically do it one at a time using a program called pcsdl.exe which supplied with the quad code. Essentially you have to connect the quad cable to a pc and download one modem at a time. regards krish > > > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ > Jake Messinger, VP. ph:713-772-6690 Lucent Dealer > AMS, Inc. fx:713-774-3498 Medical Billing > 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services > Houston, Texas 77074 www.ams.com/~jake and Hardware > > Adjunct Professor University of Houston, CBA jake@uh.edu > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems?
From: Jake Messinger <jake@ams.com>
Date: 1998-10-18 11:55:51

Thanx for the help. I actually finally did find some documentation on doing 1 modem at a time... I have one other question regarding the Netsperver 8i and 16i. Do they support STAC compression? ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Subject: (usr-tc) Does the 8i+ and 16i+ support compression?
From: Jake Messinger <jake@ams.com>
Date: 1998-10-18 11:57:45

Does the USR 8i+ and 16i+ support stac compression? If a customer had an ascend pipeline 50 for example, could they connect and get compression? And can I setup an on-demaind dialout on the netserver to connect to an upstream provider and bond muiple channels via mppp? ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: andy <smitha@mach3ww.com>
Date: 1998-10-18 12:11:21

On Sun, 18 Oct 1998, Jeff Mcadams wrote: > The only legal issue that I'm aware of with respect to the NETServer is > with the software, and I understand that. As I said earlier though, > just because the software is going away doesn't mean the hardware has > to. Pilgrim should run quite well on a 486/100, that's been my > suggestion all along. Warning: This is just my .02, it may not be worth reading, what do i know, i'm just a 20 year old college student, i don't know much about business.... But as I see it... If they would spend as much money paying some hacker to port Pilgrim to the Netserver, as they are paying some high priced lawyer to bully Lucent, we wouldn't have this problem. What makes me mad is this: When I pay for a product, I expect it to work. Is that such a radical idea? I understand that computers and software have bugs. But the least they could do is get the basic stuff working (no quake lag). I'm not asking for VOIP, or anything else really special. Just something that works well for our 56k dial-up users. Obviously, it must NOT work well because we're all bitching.... I think the way they handled the WebTV fix was awful. What the hell is a "service release" if they don't post it. They should post SR's for every single bug they find. They didn't consider the WebTV issue to be a serious bug? They didn't even post a warning next to the code that said "causes webtv users to have problems" when they found out about it. Thats nearly criminal, to know about a problem, yet lead the lemmings out to sea. I just never got that whole deal....maybe that was just a cruel way of getting back at us. Hey 3com, its also a good way to lose customers! As far as service contracts, their prices are crazy. I know 3com is "trying" to do a better job with the tech support. Thank you 3com. I've noticed the surveys on the newgroups, and I've been called a few times and surveyed on the quality of the tech support. They didn't score too high, but I know they are at least trying to improve it. Overall, just a few suggestions reguarding tech support: Make them friendly, train them vigoriously, and pay them well. It makes perfect sense to port Pilgrim. They get out from under Lucents shadow, they have one code base, ect. Even if it doesn't take care of the quake lag because of this "so called" cache problem, it would make sense to port it anyway. The only reason I can why 3com wants to ditch the netserver is clear, they want to sell more HiperArc's. Thats fine, if that is 3com's stance, that is 3com's stance. They should just say so. If they make that choice, then I'll make a choice. Here I come PM3. I think its clear, 3com has failed their customers. Lots of damage has taken place, and its going to take some radical changes for it to be repaired. If its not, I will do everything in my power to push people towards other vendors. Infact, I'll make up a form letter and send it to ever person who posts to ISP mailing lists, asking "what Remote access system to buy?". If we seriously want our issues to be addressed, we need to hit them in the pocketbook. Thank you, - andrew

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems?
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-18 12:29:20

Jake, it's a piece of cake. Since you don't have an NMC, you need to do it via the DTE on each quad card. You need to do this once per card (just pick one of the 4 DTE ports). You will also need a program called PCSDL.EXE (if you don't have that, let me know and I will email it to you outside this list). >From a DOS prompt (preferably completely outside Windoze as it sometimes messes with timing on the com ports). Have PCSDL and the .NAC and .SDL files in the directory. Cut and paste the command lines below into batch files. For single sided cards (components only on one side of the NAC card) and assuming you are installing the latest (5.10.9, which is QR051009.NAC and QR030300.SDL) pcsdl -p1 -r57600 -nNAqr -nSDqr -vNA5.10.9 -vSD3.3.0 For doube sided cards (components on both sides of the NAC card) and assuming you are installing the latest (5.9.9, which is QF050909.NAC and QF030200.SDL) pcsdl -p1 -r57600 -nNAqf -nSDqf -vNA5.9.9 -vSD3.2.0 I am assuming the COM port off your DOS PC is COM1:, if it is COM2: change -p1 to -p2. If it is any other COM port, or non-standard IRQs, email me (or use a different PC). Don't worry, it won't let you flash the wrong code to the wrong card type. Also, the cards are hot-swappable, so just pull 'em out (the NAC, or card in front) to see whether there are components on one or both sides. After you are done flashing the code to all the quads, go to each DTE (yup, all of them) and type AT&F1&W. That will restore all the settings to the hardware flow control template and you should be able to rock and roll from there. I am assuming whoever you bought this stuff from gave you the 4 DTE fan-out cables (as we like to call them, the "quadropus" cables) for each quad. If you don't have 5.9.9/5.10.9 and can't figure out the changes to the command line, let me know. The SDL files haven't changed in a couple years so I assume you have those. Just send me the list of NAC files you have. JP Jake Messinger <jake@ams.com> on 10/18/98 11:27:42 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) Hi, Im new to the list. Ive read over the USR/3com website and Im just not sure how I can upgrade these Total Control modems I have. Let me tell you the hardware: 1 USR total control chassis 20 USR analog/digital quad modem cards, various revisions 20 analog/digital quad modem connectors (no other cards) I have the firmware for a couple of the revisions. What else do I need to upgrade the modems? What/where is the procedure? Keep in mind I do not have any nmc cards or anything with an ethernet cable connected to the TC rack. ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ Jake Messinger, VP. ph:713-772-6690 Lucent Dealer AMS, Inc. fx:713-774-3498 Medical Billing 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services Houston, Texas 77074 www.ams.com/~jake and Hardware Adjunct Professor University of Houston, CBA jake@uh.edu ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-18 12:36:30

> > If the NETserver is dropped then it'll be PM3 for us. > > It is your decision. I am only answering from the question Jeff > asked. Why no one from 3com/USR was participating in this discussion? > As far as the NETServer is concerned - whether its software or > hardware - it has issues. The goal is to have HiPer arc without > issues. I understand that. The issue here is that (last time I checked) the pricing for an empty HiPerARC chasis (card + chassis) here was so obscene that the unloaded PM3 was MUCH cheaper. We don't need 300+ ports per box - that's one of our points. 56 ports/chassis suits us nicely. Sure, we could buy a HiPer bundle and put 60 ports/box, but that's a horrendously expensive way of achieving the same end. Why would anyone want to have 60 port HiPer chassis'? Redundancy maybe? That's certainly our reason. Our biggest POP has *three* (yes, only three) NETserver based chassis. If one fails we can get by. If we had 180 ports worth of HiPer gear, in one chassis, and it fails... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-18 12:40:14

On Sun, 18 Oct 1998, andy wrote: > On Sun, 18 Oct 1998, Jeff Mcadams wrote: > > > The only legal issue that I'm aware of with respect to the NETServer is > > with the software, and I understand that. As I said earlier though, > > just because the software is going away doesn't mean the hardware has > > to. Pilgrim should run quite well on a 486/100, that's been my > > suggestion all along. > > Warning: > > This is just my .02, it may not be worth reading, what do i know, i'm > just a 20 year old college student, i don't know much about business.... > > But as I see it... > > If they would spend as much money paying some hacker to port Pilgrim to > the Netserver, as they are paying some high priced lawyer to bully Lucent, > we wouldn't have this problem. > > What makes me mad is this: When I pay for a product, I expect it to work. > Is that such a radical idea? I understand that computers and software have > bugs. But the least they could do is get the basic stuff working > (no quake lag). I'm not asking for VOIP, or anything else really special. > Just something that works well for our 56k dial-up users. Obviously, it > must NOT work well because we're all bitching.... > This is not how a big company works :-). Its not that we need hackers to port code. There are some issues which I cannot discuss. Lucent is not the problem. There is more to it. This still being leagal I cannot say much on it. > I think the way they handled the WebTV fix was awful. What the hell is a > "service release" if they don't post it. They should post SR's for every > single bug they find. They didn't consider the WebTV issue to be a > serious bug? They didn't even post a warning next to the code that said > "causes webtv users to have problems" when they found out about it. Thats > nearly criminal, to know about a problem, yet lead the lemmings out to > sea. I just never got that whole deal....maybe that was just a cruel way > of getting back at us. Hey 3com, its also a good way to lose customers! > No No No. Let me say it again - There is no Service Release for Web TV yet. WebTV and other fixes will be out in a service release. There is an Engineering Release which we can give out to customers. Everybody in this list and in 3com support know that there is a problem with WebTV and they know which code fixes this. A service release is a release that fixes all major issues since a general release. An Engineering release is one fix that fixes a problem for one particular issue. Therefore it is not posted. Yes we do know how to post the service release and will do it as soon as we get the a service Release. Currently I am repeating this - IF YOU OR ANY ONE NEED THIS CODE PLEASE OPEN A TICKET WITH SUPPORT OR EMAIL ME OR SEND AN EMAIL TO THIS LIST. krish > As far as service contracts, their prices are crazy. I know 3com is > "trying" to do a better job with the tech support. Thank you 3com. I've > noticed the surveys on the newgroups, and I've been called a few times and > surveyed on the quality of the tech support. They didn't score too high, > but I know they are at least trying to improve it. Overall, just a few > suggestions reguarding tech support: Make them friendly, train them > vigoriously, and pay them well. > > It makes perfect sense to port Pilgrim. They get out > from under Lucents shadow, they have one code base, ect. Even if it > doesn't take care of the quake lag because of this "so called" cache > problem, it would make sense to port it anyway. The only reason I can why > 3com wants to ditch the netserver is clear, they want to sell more > HiperArc's. Thats fine, if that is 3com's stance, that is 3com's stance. > They should just say so. If they make that choice, then I'll make a > choice. Here I come PM3. > > I think its clear, 3com has failed their customers. Lots of damage has > taken place, and its going to take some radical changes for it to be > repaired. If its not, I will do everything in my power to push people > towards other vendors. Infact, I'll make up a form letter and send it to > ever person who posts to ISP mailing lists, asking "what Remote access > system to buy?". > > If we seriously want our issues to be addressed, we need to hit them in > the pocketbook. > > Thank you, > > - > andrew > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Requested Features
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-18 12:47:00

How do I get my requests in for fixes to the HiperArc? 1. Idle times available with SNMP 2. Total connect time available with SNMP

Subject: (usr-tc) Quake Lag Qustion
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-18 12:47:17

What is the Quake lag problem? What units are susceptible?

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-18 13:10:14

> Well it depends Some ISP require more ports some dont. Exactly. We're in the latter category. > When we first started with the NETServer we had two versions 24 port > and 48 port. The 24 port did not go any where. People wanted more > expansion capabilites. I can understand that on a 24 port box :-) I understand your point (always have). Some need big systems, some don't. It just seems that 3COM are orphaning those that don't. Those that don't often don't have the spare capital to be able to afford the entry price of the higher density solutions. I'd love to be able to put a couple of HiPer systems in our remote POP's (redundancy) and keep slotting on one DSP card every 6 months until the year 2008. We can't afford that sort of up front cost. > > Why would anyone want to have 60 port HiPer chassis'? Redundancy maybe? > > That's certainly our reason. Our biggest POP has *three* (yes, only > > three) NETserver based chassis. If one fails we can get by. > > No not for Redundance - ISP here and in Europe do see density as a big > thing. The per port price has been droping and now you could buy more > ports for the same price you may have paid for 48 port two/three years ago. You've lost me a bit there... I can see the benefits of higher density in terms of reduced rack space in co-lo sites, but the smaller guys don't really have that concern (at least not here). Higher density systems may well be cheaper in the US, but for the number of ports/box we need, that certainly isn't the case with 3COM here in Australia. > > If we had 180 ports worth of HiPer gear, in one chassis, and it fails... > > > > No one can really give you a 100% gurantee. I agree, that's why we have multiple chassis. We don't want all our eggs in the one basket. > We can only go by statistics - I have seen installations with more > than 300+ ports stable with HiPer arc. I don't doubt that. We have two sites with one single NETserver based chassis - they're stable too (other than the FC2/FC3 issue). Heaven help us though if a critical card breaks there. Yes, we have a maintenance contract. Even 2 hours total downtime at one of these POP's is considered unacceptable though. As soon as we can justify the cost of another NAS at those POP's, we'll do it. That way, if one fails, we can still operate at half capacity while parts arrive. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-18 13:40:29

On Sun, 18 Oct 1998, Jeff Mcadams wrote: > Thus spake Tatai SV Krishnan > >No No No. Let me say it again - There is no Service Release for Web TV > >yet. WebTV and other fixes will be out in a service release. There is > >an Engineering Release which we can give out to customers. Everybody in > >this list and in 3com support know that there is a problem with WebTV and > >they know which code fixes this. A service release is a release that > >fixes all major issues since a general release. An Engineering release > >is one fix that fixes a problem for one particular issue. Therefore it > >is not posted. Yes we do know how to post the service release and will > >do it as soon as we get the a service Release. Currently I am repeating > >this - IF YOU OR ANY ONE NEED THIS CODE PLEASE OPEN A TICKET WITH SUPPORT > >OR EMAIL ME OR SEND AN EMAIL TO THIS LIST. > > If I might make a friendly (seriously...no ranting here at all :) > suggestion here. From my understanding, 3Com seems to work serially on > releases. All of the work in 3.8.99 for example is also included in > 3.8.98, so...you may have a fix in 3.8.82 for WebTV (just picking > version numbers at random) but that release is attempting to also fix 8 > other problems that have popped up in other releases. As a suggestion, > work on fixes like these in parallel if you can...start working on the > WebTV fix is 3.8.99, maybe work on another fix in 3.8.98, but *don't* > include the work you've done on WebTV stuff in it. When you have each > individual issue fixed, you can roll that fix (and others that have > successfully been fixed) into a service release (the idea of a service > release is good IMHO). The upshot of all this is...you can then give > out ER releases that (for example) fix WebTV, without breaking other > issues that are currently in progress for fixes and may actually be in > *worse* shape than the actual release code. This type of number system is confusing. You are almost right here. Here is how it goes. Say the release version is 3.8.0 - The first Engineering release fixing a problem or supporting a feature will be 3.8.99. The second one will be 3.8.98. Now techinically every fix in 3.8.99 should be 3.8.98. If there is a version 3.8.80 say then it should have all the fixes of 3.8.0 - through 3.8.81. Now if there is a possiblilty that say after 10 or 12 ER releases we have had a few bug and a few features - then we come up with one release which incorporates all the fixes and still have it as ER - based on our testing here and customers application/request it will be made as a service release. The webTV fix 4.1.78 has solved the web TV problem but still has problems with others ( namely MPIP, accounting, unicode charecters, etc ) The fix will be in a service release. krish > > Anyway...just my $.02 on this subject...like I said...no ranting, just a > suggestion. :) > -- > Jeff McAdams Email: jeffm@iglou.com > Head Network Administrator Voice: (502) 966-3848 > IgLou Internet Services (800) 436-4456 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Does the 8i+ and 16i+ support compression?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-18 14:07:50

Thus spake Francis Fong >Also does it support SNMP Managment, beside the NetServer Manager? Can I >use a standard SNMP Management Software to browse the NetSevter, using the >MIB file inside? Who has the MIB Library of this? NETServer supports just the basic MIB-II...nothing more. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-18 14:14:55

Thus spake Tatai SV Krishnan >No No No. Let me say it again - There is no Service Release for Web TV >yet. WebTV and other fixes will be out in a service release. There is >an Engineering Release which we can give out to customers. Everybody in >this list and in 3com support know that there is a problem with WebTV and >they know which code fixes this. A service release is a release that >fixes all major issues since a general release. An Engineering release >is one fix that fixes a problem for one particular issue. Therefore it >is not posted. Yes we do know how to post the service release and will >do it as soon as we get the a service Release. Currently I am repeating >this - IF YOU OR ANY ONE NEED THIS CODE PLEASE OPEN A TICKET WITH SUPPORT >OR EMAIL ME OR SEND AN EMAIL TO THIS LIST. If I might make a friendly (seriously...no ranting here at all :) suggestion here. From my understanding, 3Com seems to work serially on releases. All of the work in 3.8.99 for example is also included in 3.8.98, so...you may have a fix in 3.8.82 for WebTV (just picking version numbers at random) but that release is attempting to also fix 8 other problems that have popped up in other releases. As a suggestion, work on fixes like these in parallel if you can...start working on the WebTV fix is 3.8.99, maybe work on another fix in 3.8.98, but *don't* include the work you've done on WebTV stuff in it. When you have each individual issue fixed, you can roll that fix (and others that have successfully been fixed) into a service release (the idea of a service release is good IMHO). The upshot of all this is...you can then give out ER releases that (for example) fix WebTV, without breaking other issues that are currently in progress for fixes and may actually be in *worse* shape than the actual release code. Anyway...just my $.02 on this subject...like I said...no ranting, just a suggestion. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Quake Lag Qustion
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-18 14:18:53

Thus spake Richard Stuplich >What is the Quake lag problem? >What units are susceptible? NETServer cards in Total Control chassis' don't handle UDP streams very well. Pretty much all versions of code have this issue...though some are better than others. We're running 3.7.76 (an ER release I believe) and it doesn't seem to be hit too hard with it. I've heard others talk that 3.8.1 has it pretty bad. :/ It's called Quake lag because the networking code in Quake makes use of a large number of small UDP packets (which, lot's of small packets are harder to deal with than a few number of large packets) so this application is where this problem is most noticeable. Theoretically, streaming audio and video is likely impacted as well though those applications will typically use fewer, larger packets that don't get hit by it as hard. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-18 15:23:28

> If you can't afford to upgrade, then you probably can't afford > to switch vendors also.. Why should we pay to upgrade though? Our NETservers are barely 18 months old. We were intending to get 3-4 years out of the NETservers before upgrading. We're happy with the NETserver based solution and certainly have no interested in shelling out more $$$ on the existing equipment. > Jumping onto HiperARC's shouldn't cost more than selling NetServers > and buying PM's.. If you live in the US maybe... If my memory is correct, I was quoted $14k for an ARC and $14k for DSP cards. Even 30 ports worth of quads costs under $12k. As for your cheap bundles over there - I wish. An ex-eval chassis, with one quad, one NETserver and dual power supplies cost us $7k, plus another $3k for the PRI card (already had a spare NMC). > What is the current upgrade cost now? $3,500?? The procedure here, apparently, is that you pull your NETserver, throw it in the bin, and buy a shiny new $14k ARC. Upgrades? Trade-ups? Bundles? Nobody's ever mentioned them here, and when I ask it falls on deaf ears... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-18 15:43:51

> In all honesty, how mant _chassises_ have you had fail? Lots of NIC > cards die -- I assume it's power spikes on the telco lines? A few NAC > cards die. But, out of 47 chassises, (knock on wood) none of the > chassises have ever failed. (I've had to reseat cards on occasion, > but that's not a serious issue.) None yet, but given past experience, would you trust 3COM's service people to get parts to you on time? Our last experience with 3COM service was atrocious. On that occasion our expectation may have been a bit high, and their warranty cover a bit poor, but still, the crap we had to go through appeared to be the same as a normal maintenance claim/request. We did learn that the serial numbers reported by TCM are no longer acceptable as they're not long enough. Then they thought it'd be cool for us to drive around the state taking photos of each card, scanning them, and sending them to Singapore so they could read the serial number themselves. Didn't matter that this was a 1000km round trip. This doesn't leave us with any real confidence in any maintenance contract, despite it (when they finally activate it) being 8x5 24 hour. Even then, if we went with the most expensive, fastest contract, it's still not fast enough. 4 hours downtime is unacceptable. When we can justify multiple chassis, we'll have backup - if one fails, we can run 50% capacity until aprts arrive. Some service is better than none at all. (Actually, I think we did have a chassis fail - shortly after delivery back in 1997 - I might be wrong though). Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-18 16:51:07

andy was heard to say: >If they would spend as much money paying some hacker to port Pilgrim to >the Netserver, as they are paying some high priced lawyer to bully Lucent, >we wouldn't have this problem. Well, if 3Com management would get out of the programer's way and let them do what they know needs to be done, then things would be alot different. They also need to learn how to test stuff. In testing USR hardware before we started deploying it over a year ago, I found dozens of problems and I wasn't even looking for anything. >As far as service contracts, their prices are crazy. I know 3com is >"trying" to do a better job with the tech support. Thank you 3com. I've >noticed the surveys on the newgroups, and I've been called a few times and >surveyed on the quality of the tech support. They didn't score too high, >but I know they are at least trying to improve it. Overall, just a few >suggestions reguarding tech support: Make them friendly, train them >vigoriously, and pay them well. You're always going to have trouble with helpdesk. Maintaining clue levels is very difficult for people who don't deal with the hardware much. Take a lesson from Cisco TAC... their support people have a lab full of "toys" to play with for the days they aren't on the phones; plus, they can replicate your setup to see what the problem is. >It makes perfect sense to port Pilgrim. They get out >from under Lucents shadow, they have one code base, ect. Even if it Well, it's my impression they need to learn how to manage a diverse code tree. At min. they need to have a standard coding style... --Ricky

Subject: Re: (usr-tc) Radiator vs. Cistron
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-18 17:13:52

On Fri, 16 Oct 1998, Kingsley S. Grant wrote: > 3Com software OS. If! 3Com wins the court battle then you will get the > updates for the Netserver if they lose you will not and will never. So > it is the folks at Lucent who shold be getting the flame, Not 3Com. Lucent is not at fault here. Lucent and 3Com agreed that 3Com could use the code until a certain date, at which time, 3Com would have replacement code available. 3Com did not have a new OS available, so they continued to use the Lucent code. 3Com and Lucent sued each other over this. The agreement was extended until the end of 1998. Brian

Subject: Re: (usr-tc) Netserver OS
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-18 20:59:10

On Fri, 16 Oct 1998, cfb wrote: > Lucent has executed their acquired licensing agreement with 3Com to the > tee? While purely anecdotal, it would be interesting to know just how > much of the Livingston-3Com licensing agreement was disclosed prior to > the Lucent acquisition. Maybe I have some of the timeline details > wrong? Prior to the acquisition by Lucent, Livingston had filed documents with the SEC for an IPO. There was a lengthy discussion of the Livingston/USR licensing agreement. Livingston was making around 12% of their revenue off the licensing agreement, if I remember right. (This was before Livingston's revenue took off with the PM3.) Brian

Subject: (usr-tc) Universal Port ( voice, data, fax )
From: henry moats <hmoats@netcom.com>
Date: 1998-10-18 20:59:29

Is anybody doing 3com's "Universal Port" solution for their analog, data, VOIP and fax solutions? Can they do it? Does it work? Does it require an Edgeserver Card? Thanks

Subject: Re: (usr-tc) TC Netserver discussion...observationy
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-18 21:18:23

> >None yet, but given past experience, would you trust 3COM's service people > >to get parts to you on time? > > Never have... that's why I keep in-house spares :-) Any downtime at all > is generally not acceptable. Would be nice to have the luxury. Best we can justify is having multiple chassis to enable us to operate in a degraded fashion during failures. If we lose a card at a one chassis POP, we can pull cards from our multi-chassis POP temporarily... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-18 21:29:49

> Atrocious is a good word. We purchased a service contract from Source > with a bundle back in March at ISPCON. We *still* can't get the > contract "activated" seven months later! This is because we didn't > purchase half a dozen contracts for all our gear or some BS. It's a > long story.. That's interesting. Our contract covers only selected components within our chassis as otherwise the cost is prohibitive. I think a Quad DIGITAL NAC was around $300/year (yeah, EACH). At $4200 for a chassis full, it's cheaper to buy 3 each year for spares :-) > But the bottom line is that we don't care so much. I don't want to be at > anyones mercy and I constantly work to achieve independance of sorts. from > the telco, 3COM, whoever want's us to rely on them without question. Unfortunately we have to rely on 3COM to a certain degree, but we don't count on them delivering anything on time - we just can't afford to. It's not just a 3COM thing - we don't rely on anyone except ourselves doing the right thing at the right time. > We really don't need the contract because of this list, an overall > lack of problems, a smart admin, and a couple of really nice engineers > at 3COM who really care. Combine this with a reliable hardware > platform, and the fact that we had to run beta code anyway to get > MPIP, and we really don't need total support for much.. at least not > now. The only thing we really need support for is (a) Software upgrades, and (b) Hardware replacement. We tried getting NETservers replaced under warranty, but that was worse than pulling teeth. We were told that the process would be a lot easier if we had a contract. In other words, "this will be difficult, but we can make it easy if you pay us more". They didn't say that, but that's certainly how it felt from our end. > Someday I hope that total support won't be burdened and support contracts > might be very profitable. And the contracts worth purchasing. Everyone > wins. If the hardware is good, and your customers are happy, then tech > support gets the benefits of design engineers good ideas and labor. lots > of snowball effects and intertwined relationships here. Agreed. > >This doesn't leave us with any real confidence in any maintenance > >contract, despite it (when they finally activate it) > > hehe.. It will be over by the time they activate it.. for us anyway.. Not bloody likely... Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-18 22:07:59

On Sun, 18 Oct 1998, Tatai SV Krishnan wrote: > is one fix that fixes a problem for one particular issue. Therefore it > is not posted. Yes we do know how to post the service release and will > do it as soon as we get the a service Release. Currently I am repeating > this - IF YOU OR ANY ONE NEED THIS CODE PLEASE OPEN A TICKET WITH SUPPORT > OR EMAIL ME OR SEND AN EMAIL TO THIS LIST. Krish, This is not directed at you, as you don't have control over these issues... This is one point I continue to take issue with. I wasn't even bit by the bug, but you have to remember one thing: Not all customers call support when they first run into problems. Not all customers are on this mailing list. Some customers don't even have support contracts. How would they know that they didn't horribly misconfigure something? Imagine a large ISP with a handful of WebTV users. Would the problem even be noticed the same day? How can you fix this? Even if you won't post code to the website, at least have a "Release Notes" section or something similar on the site so that people grabbing the code are aware there is a problem. Then they can shell out the $1200/chassis for the software to fix the webtv problem. Or am I now starting to see how management thinks. "Ohh.. don't post any warning about this, they'll eventually pay us for a software contract, and I guess they'll need a support contract to figure out the problem too..." What 3com is teaching us here is to very carefully not only the hardware and software when you buy, but the entire support mechanism behind it. It can make or break your business. Of course when we bought, support was reasonably priced, and we were told by the salesman "oh just buy one contract, that'll be fine." He works for Cisco now so.... Charles > > > krish > > > As far as service contracts, their prices are crazy. I know 3com is > > "trying" to do a better job with the tech support. Thank you 3com. I've > > noticed the surveys on the newgroups, and I've been called a few times and > > surveyed on the quality of the tech support. They didn't score too high, > > but I know they are at least trying to improve it. Overall, just a few > > suggestions reguarding tech support: Make them friendly, train them > > vigoriously, and pay them well. > > > > It makes perfect sense to port Pilgrim. They get out > > from under Lucents shadow, they have one code base, ect. Even if it > > doesn't take care of the quake lag because of this "so called" cache > > problem, it would make sense to port it anyway. The only reason I can why > > 3com wants to ditch the netserver is clear, they want to sell more > > HiperArc's. Thats fine, if that is 3com's stance, that is 3com's stance. > > They should just say so. If they make that choice, then I'll make a > > choice. Here I come PM3. > > > > I think its clear, 3com has failed their customers. Lots of damage has > > taken place, and its going to take some radical changes for it to be > > repaired. If its not, I will do everything in my power to push people > > towards other vendors. Infact, I'll make up a form letter and send it to > > ever person who posts to ISP mailing lists, asking "what Remote access > > system to buy?". > > > > If we seriously want our issues to be addressed, we need to hit them in > > the pocketbook. > > > > Thank you, > > > > - > > andrew > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-18 22:12:59

On Sun, 18 Oct 1998, Ricky Beam wrote: > You're always going to have trouble with helpdesk. Maintaining clue levels > is very difficult for people who don't deal with the hardware much. Take a > lesson from Cisco TAC... their support people have a lab full of "toys" to > play with for the days they aren't on the phones; plus, they can replicate > your setup to see what the problem is. And that's no BS, either. The only rant I have for Cisco is that you will have more problems working through a problem in "bleeding edge" images (11.3T series being my favorite ;). But if you are on a stable release (which is nice to have available) you get all the help you need. Even if you get a new tech they are generally curious enough to replicate your problem and run it by a superior. It makes for a nice generalism with their code: If it's brand new and feature-filled, be careful, otherwise you will most likely be OK. And a customer-accessible bug database doesn't hurt either. Charles > >It makes perfect sense to port Pilgrim. They get out > >from under Lucents shadow, they have one code base, ect. Even if it > > Well, it's my impression they need to learn how to manage a diverse code > tree. At min. they need to have a standard coding style... > > --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. > =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) Does the 8i+ and 16i+ support compression?
From: Francis Fong <francisf@synergy-hk.com.hk>
Date: 1998-10-19 01:08:58

Also does it support SNMP Managment, beside the NetServer Manager? Can I use a standard SNMP Management Software to browse the NetSevter, using the MIB file inside? Who has the MIB Library of this? Rgds, Francis On Sun, 18 Oct 1998, Jake Messinger wrote: > Does the USR 8i+ and 16i+ support stac compression? > > If a customer had an ascend pipeline 50 for example, could they connect > and get compression? > > And can I setup an on-demaind dialout on the netserver to connect to an > upstream provider and bond muiple channels via mppp? > > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ > Jake Messinger, VP. ph:713-772-6690 Lucent Dealer > AMS, Inc. fx:713-774-3498 Medical Billing > 8300 Bissonnet #400 jake@ams.com , ICQ# 4403734 Internet Services > Houston, Texas 77074 www.ams.com/~jake and Hardware > > Adjunct Professor University of Houston, CBA jake@uh.edu > ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~ > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-19 09:48:15

On Sat, 17 Oct 1998, Jeff Mcadams wrote: > I recently did a review of the addresses on the list...there are a > not-insignificant number of 3com and USR addresses on the list, and > that's understandable, what I don't understand, is that we get virtually > no feedback from these folks...or 3Com much at all. Most of the 3Com employees on this list are probably in tech support. They may not have any information on what features are being added, or what bugs are being fixed, or management may not allow them to comment on these things. Brian

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-19 09:53:11

On Sun, 18 Oct 1998, Charles Sprickman wrote: > On Sun, 18 Oct 1998, Tatai SV Krishnan wrote: > > > is one fix that fixes a problem for one particular issue. Therefore it > > is not posted. Yes we do know how to post the service release and will > > do it as soon as we get the a service Release. Currently I am repeating > > this - IF YOU OR ANY ONE NEED THIS CODE PLEASE OPEN A TICKET WITH SUPPORT > > OR EMAIL ME OR SEND AN EMAIL TO THIS LIST. > > Krish, > > This is not directed at you, as you don't have control over these > issues... > > This is one point I continue to take issue with. I wasn't even bit by the > bug, but you have to remember one thing: Not all customers call support > when they first run into problems. Not all customers are on this mailing > list. Some customers don't even have support contracts. How would they > know that they didn't horribly misconfigure something? Imagine a large > ISP with a handful of WebTV users. Would the problem even be noticed the > same day? This is where I have to disagree. If a customer has a 3com product and has the latest code - it is not correct to say that he does not know about calling support. A customer can get code for HiPer arc only two ways 1. From the manufacture ( 3com ) if he buys a new chassis 2. They can download the same from 3com web site ( I am talking about 4.1.11) Now there is a third way of having someone give it to him. If he runs into problem then Case 1. The customer has the new product that has problems - he is covered by warrenty, he has support for 90 days irrespective of the support contract. We will support him. He does know the 800 number may not know this list but can send an email atleast to the web manager ( totalservice ) or even call his reseller and find out. Case 2. If the customer downloads this code in the web - he does have access to web to send an email or call support. Now in both cases the customer does have and does know how to get this problem fixed. So it is not correct to say that the customer does not know support and does not know about this list so he is helpless. > > How can you fix this? Even if you won't post code to the website, at > least have a "Release Notes" section or something similar on the site so > that people grabbing the code are aware there is a problem. Then they can > shell out the $1200/chassis for the software to fix the webtv problem. So again you are tell me that a customer know where to download the release code but cannot send an email to support? And as far as I know sending an email to support does not need a contract for $1200. If this code fixed most of the issues yes we shall have a service release. Currently it does not. > > Or am I now starting to see how management thinks. "Ohh.. don't post any > warning about this, they'll eventually pay us for a software contract, and > I guess they'll need a support contract to figure out the problem too..." > No it does not matter what the management thinks. If you email support for a bug then if there is a fix you will get it. What clearly makes the difference is how the customer gets this code. If you can download the code ( released version 4.1.11 ) from the web site what stops you from emailing to support regarding a problem. If the email has been sent and if no one in support answers - then there is a problem. Again if there is a service release we will be posting it as soon as we make sure it has all the fixes. regards krish > What 3com is teaching us here is to very carefully not only the hardware > and software when you buy, but the entire support mechanism behind it. It > can make or break your business. Of course when we bought, support was > reasonably priced, and we were told by the salesman "oh just buy one > contract, that'll be fine." He works for Cisco now so.... > > Charles > > > > > > > krish > > > > > As far as service contracts, their prices are crazy. I know 3com is > > > "trying" to do a better job with the tech support. Thank you 3com. I've > > > noticed the surveys on the newgroups, and I've been called a few times and > > > surveyed on the quality of the tech support. They didn't score too high, > > > but I know they are at least trying to improve it. Overall, just a few > > > suggestions reguarding tech support: Make them friendly, train them > > > vigoriously, and pay them well. > > > > > > It makes perfect sense to port Pilgrim. They get out > > > from under Lucents shadow, they have one code base, ect. Even if it > > > doesn't take care of the quake lag because of this "so called" cache > > > problem, it would make sense to port it anyway. The only reason I can why > > > 3com wants to ditch the netserver is clear, they want to sell more > > > HiperArc's. Thats fine, if that is 3com's stance, that is 3com's stance. > > > They should just say so. If they make that choice, then I'll make a > > > choice. Here I come PM3. > > > > > > I think its clear, 3com has failed their customers. Lots of damage has > > > taken place, and its going to take some radical changes for it to be > > > repaired. If its not, I will do everything in my power to push people > > > towards other vendors. Infact, I'll make up a form letter and send it to > > > ever person who posts to ISP mailing lists, asking "what Remote access > > > system to buy?". > > > > > > If we seriously want our issues to be addressed, we need to hit them in > > > the pocketbook. > > > > > > Thank you, > > > > > > - > > > andrew > > > > > > > > > - > > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > > with "unsubscribe usr-tc" in the body of the message. > > > For information on digests or retrieving files and old messages send > > > "help" to the same address. Do not use quotes in your message. > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the 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 Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork@inch.com access@inch.com | > = =----------------= > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-19 10:28:47

I think it was written by a UNIX junky. Kinda reminds me of un-tarring a file ;) Your point is duly noted and is in as a feature request. Guess I forgot to put in the smiley after "its' a piece of cake" as I was kidding a bit. Generally on products where it is used all the time we include a batch file (go.bat or something like that) with the distribution. JP Kevin Benton <s1kevin@tims.net> on 10/19/98 10:10:00 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) (KRISH!) On Sun, 18 Oct 1998, John Powell wrote: > Date: Sun, 18 Oct 1998 12:29:20 -0500 > From: John Powell <John_Powell@mw.3com.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? > > Jake, it's a piece of cake. > ... > > pcsdl -p1 -r57600 -nNAqr -nSDqr -vNA5.10.9 -vSD3.3.0 > > For doube sided cards (components on both sides of the NAC card) and > assuming you are installing the latest (5.9.9, which is QF050909.NAC and > QF030200.SDL) > > pcsdl -p1 -r57600 -nNAqf -nSDqf -vNA5.9.9 -vSD3.2.0 A piece of cake if you've done it 100,000 times maybe... (okay, maybe I'm exaggerating a little :) Krish - can we *PLEASE* put in a feature request to menuize the selection of filenames, etc in PCSDL? That thing is so cryptic that I often have to type a command line 4 or 5 times just to get it right. We're network engineers, not cryptographers. Having help available on a per item basis would also be very helpful. Also, what if we're about to upgrade an NMC but we don't have the SDL file, but just the NAC file? We have to copy it from an older version? Okay... I'm just saying it'd be nice for the program to let me know things like that instead of just throwing a useless error message at me. I'm assuming of course that the menuized version would ask me what kind of card I have and make a good guess at what the filename is, and show me a list of versions based on the type of card I've specified (from the filenames), etc. If nobody wants to modify pcsdl.exe, maybe you guys could write sdlmenu.exe or something which would call pcsdl.exe with the correct parameters. pcsdl.exe = user friendly... NOT! Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-19 11:10:00

On Sun, 18 Oct 1998, John Powell wrote: > Date: Sun, 18 Oct 1998 12:29:20 -0500 > From: John Powell <John_Powell@mw.3com.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? > > Jake, it's a piece of cake. > ... > > pcsdl -p1 -r57600 -nNAqr -nSDqr -vNA5.10.9 -vSD3.3.0 > > For doube sided cards (components on both sides of the NAC card) and > assuming you are installing the latest (5.9.9, which is QF050909.NAC and > QF030200.SDL) > > pcsdl -p1 -r57600 -nNAqf -nSDqf -vNA5.9.9 -vSD3.2.0 A piece of cake if you've done it 100,000 times maybe... (okay, maybe I'm exaggerating a little :) Krish - can we *PLEASE* put in a feature request to menuize the selection of filenames, etc in PCSDL? That thing is so cryptic that I often have to type a command line 4 or 5 times just to get it right. We're network engineers, not cryptographers. Having help available on a per item basis would also be very helpful. Also, what if we're about to upgrade an NMC but we don't have the SDL file, but just the NAC file? We have to copy it from an older version? Okay... I'm just saying it'd be nice for the program to let me know things like that instead of just throwing a useless error message at me. I'm assuming of course that the menuized version would ask me what kind of card I have and make a good guess at what the filename is, and show me a list of versions based on the type of card I've specified (from the filenames), etc. If nobody wants to modify pcsdl.exe, maybe you guys could write sdlmenu.exe or something which would call pcsdl.exe with the correct parameters. pcsdl.exe = user friendly... NOT! Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-19 11:10:35

Tatai SV Krishnan was heard to say: >This is where I have to disagree. If a customer has a 3com product and >has the latest code - it is not correct to say that he does not know >about calling support. A customer can get code for HiPer arc only two ways >1. From the manufacture ( 3com ) if he buys a new chassis ... >Case 1. The customer has the new product that has problems - he is >covered by warrenty, he has support for 90 days irrespective of the >support contract. We will support him. He does know the 800 number may >not know this list but can send an email atleast to the web manager ( >totalservice ) or even call his reseller and find out. I have to agree here... if someone buy a TC chassis and doesn't have the fancy black flip-folder with all the support info in there -- it's the warranty information pack in a vacuum sealed static bag, then there is a problem. Everyone of the 47 chassis we have came with that folder. >> How can you fix this? Even if you won't post code to the website, at >> least have a "Release Notes" section or something similar on the site so >> that people grabbing the code are aware there is a problem. Then they can >> shell out the $1200/chassis for the software to fix the webtv problem. > >So again you are tell me that a customer know where to download the >release code but cannot send an email to support? And as far as I know >sending an email to support does not need a contract for $1200. Sending the email, no. However, without a valid contract ID, nothing will be done. I've had simple (already fixed in an ER) problems drop on the floor without even lifting a finger to fix anything because the contract ID I used had expired -- I've got 7 ids... every time I called, I was quoted a new number (being paranoid, I keep everything) This happens too often to ignore it. 3Com appears to be alot more greedy with respect to software updates than every other code shop on the planet. (Even Cisco gives away updates to IOS when there are problems.) --Ricky

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-19 11:12:20

Thus spake Brian Elfert >On Sat, 17 Oct 1998, Jeff Mcadams wrote: >> I recently did a review of the addresses on the list...there are a >> not-insignificant number of 3com and USR addresses on the list, and >> that's understandable, what I don't understand, is that we get virtually >> no feedback from these folks...or 3Com much at all. >Most of the 3Com employees on this list are probably in tech support. There were several that I recognized as not being in support. I'll refrain from naming any names or positions as I think that would be uncool, but rest assured, there are 3Com folks on this list that *certainly* have knowledge about this situation...of if they don't, then I've even *more* concerned about the state of 3Com. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-19 11:27:09

;) I might also add the direction we are moving is AWAY from platform specific apps like PCSDL and to more generic methods like xmodem/zmodem. That way it can be done reliably from just about any platform (even a Mac has decent terminal support). Courier, I-modem, HiPer, etc. are already there. I think most will agree that is far more desirable. Thanks again for the comments. JP Kevin Benton <s1kevin@tims.net> on 10/19/98 10:40:16 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) (KRISH!) On Mon, 19 Oct 1998, John Powell wrote: > I think it was written by a UNIX junky. Kinda reminds me of un-tarring a > file ;) Oh, come on, that's easy. Try cpio... :) cpio -iBv --format=crc ... > Your point is duly noted and is in as a feature request. Guess I forgot to > put in the smiley after "its' a piece of cake" as I was kidding a bit. > Generally on products where it is used all the time we include a batch file > (go.bat or something like that) with the distribution. What's funny about that is that I *AM* a "UNIX junky" as you put it and it's still cryptic. Of course, if you were to provide pcsdl(8) for it, that might help a tad bit :) (sly grin j/k) Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Quake Lag Qustion
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 11:40:10

3COM does have a solution that handles quake rather well. Try using quad modems with a HiPer ARC. You should see no lag or almost no lag at all. -----Original Message----- >Thus spake Richard Stuplich >>What is the Quake lag problem? >>What units are susceptible? > >NETServer cards in Total Control chassis' don't handle UDP streams very >well. Pretty much all versions of code have this issue...though some >are better than others. We're running 3.7.76 (an ER release I believe) >and it doesn't seem to be hit too hard with it. I've heard others talk >that 3.8.1 has it pretty bad. :/ > >It's called Quake lag because the networking code in Quake makes use of >a large number of small UDP packets (which, lot's of small packets are >harder to deal with than a few number of large packets) so this >application is where this problem is most noticeable. Theoretically, >streaming audio and video is likely impacted as well though those >applications will typically use fewer, larger packets that don't get hit >by it as hard. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-19 11:40:16

On Mon, 19 Oct 1998, John Powell wrote: > I think it was written by a UNIX junky. Kinda reminds me of un-tarring a > file ;) Oh, come on, that's easy. Try cpio... :) cpio -iBv --format=crc ... > Your point is duly noted and is in as a feature request. Guess I forgot to > put in the smiley after "its' a piece of cake" as I was kidding a bit. > Generally on products where it is used all the time we include a batch file > (go.bat or something like that) with the distribution. What's funny about that is that I *AM* a "UNIX junky" as you put it and it's still cryptic. Of course, if you were to provide pcsdl(8) for it, that might help a tad bit :) (sly grin j/k) Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-19 11:41:59

On Sun, 18 Oct 1998, Allen Marsalis wrote: > problems, a smart admin, and a couple of really nice engineers at 3COM who > really care. Combine this with a reliable hardware platform, and the fact > that we had to run beta code anyway to get MPIP, and we really don't need > total support for much.. at least not now. Reliable hardware? I keep getting one modem on a card that sits at "modem unavailable" mode. Resetting the config, and trying a dozen other things doesn't help. When I call 3Com, they just RMA the cards. I currently have one or two cards with a bad modem, and I returned two or three quad modem cards due to this issue. Brian

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 11:45:46

3COM does have the ability to duplicate most customer environments. I know, I used to do it for some situations. As a tech, your only requirement is to want to go through the trouble of setting it up. As far as the "lab full of toys"; 3COM is working very hard to create an environment where every tech will have time off the phone to do just that. Give it a little time. It will get there. -----Original Message----- >andy was heard to say: >>If they would spend as much money paying some hacker to port Pilgrim to >>the Netserver, as they are paying some high priced lawyer to bully Lucent, >>we wouldn't have this problem. > >Well, if 3Com management would get out of the programer's way and let them >do what they know needs to be done, then things would be alot different. >They also need to learn how to test stuff. In testing USR hardware before >we started deploying it over a year ago, I found dozens of problems and I >wasn't even looking for anything. > >>As far as service contracts, their prices are crazy. I know 3com is >>"trying" to do a better job with the tech support. Thank you 3com. I've >>noticed the surveys on the newgroups, and I've been called a few times and >>surveyed on the quality of the tech support. They didn't score too high, >>but I know they are at least trying to improve it. Overall, just a few >>suggestions reguarding tech support: Make them friendly, train them >>vigoriously, and pay them well. > >You're always going to have trouble with helpdesk. Maintaining clue levels >is very difficult for people who don't deal with the hardware much. Take a >lesson from Cisco TAC... their support people have a lab full of "toys" to >play with for the days they aren't on the phones; plus, they can replicate >your setup to see what the problem is. > >>It makes perfect sense to port Pilgrim. They get out >>from under Lucents shadow, they have one code base, ect. Even if it > >Well, it's my impression they need to learn how to manage a diverse code >tree. At min. they need to have a standard coding style... > >--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. >

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-10-19 11:50:14

On Mon, 19 Oct 1998, John Powell wrote: > I might also add the direction we are moving is AWAY from platform specific > apps like PCSDL and to more generic methods like xmodem/zmodem. That way > it can be done reliably from just about any platform (even a Mac has decent > terminal support). Courier, I-modem, HiPer, etc. are already there. I > think most will agree that is far more desirable. how about tftp upload support for the NMC? The ARC can do it why cant the NMC :-/ How about telnet management for the NMC? :-/ -Dan

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 11:54:25

Most of them use it to keep abreast of issues not to participate. In fact, I only know of a few 3COM employees who have ever participated. I was one. Krish and about 3 or 4 others comprised the rest. Mostly just Krish. -----Original Message----- > > >On Sat, 17 Oct 1998, Jeff Mcadams wrote: > >> I recently did a review of the addresses on the list...there are a >> not-insignificant number of 3com and USR addresses on the list, and >> that's understandable, what I don't understand, is that we get virtually >> no feedback from these folks...or 3Com much at all. > >Most of the 3Com employees on this list are probably in tech support. > >They may not have any information on what features are being added, or >what bugs are being fixed, or management may not allow them to comment on >these things. > >Brian > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 12:02:47

Where are you seeing Modem Unavailable? If you are seeing this in a performance Session monitor when monitoring the T1 or PRI then the most common reason is the Line Interface Source on the modem is either incorrect or after it was changed the T1 or PRI card did not remap. Try setting it, saving it, and resetting the modem card. If you have done all that then the modem card probably is bad. Either that or you have your T1 card in a bad slot. -----Original Message----- > > >On Sun, 18 Oct 1998, Allen Marsalis wrote: > >> problems, a smart admin, and a couple of really nice engineers at 3COM who >> really care. Combine this with a reliable hardware platform, and the fact >> that we had to run beta code anyway to get MPIP, and we really don't need >> total support for much.. at least not now. > >Reliable hardware? I keep getting one modem on a card that sits at "modem >unavailable" mode. Resetting the config, and trying a dozen other things >doesn't help. When I call 3Com, they just RMA the cards. > >I currently have one or two cards with a bad modem, and I returned two or >three quad modem cards due to this issue. > >Brian > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Quake Lag Qustion
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 12:04:27

I know and agree. just thought you would want to know what has been tested and proven to work. Since most people are upgrading from the NetServer to the HiPer ARC they will have this combination. It will be a solution for them -----Original Message----- >Thus spake Brian K McIntire >>3COM does have a solution that handles quake rather well. Try using quad >>modems with a HiPer ARC. You should see no lag or almost no lag at all. > >Not really what I call a fix for the problem...solution maybe, not a fix >though. I'd prefer a fix. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Quake Lag Qustion
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-19 12:51:00

Thus spake Brian K McIntire >3COM does have a solution that handles quake rather well. Try using quad >modems with a HiPer ARC. You should see no lag or almost no lag at all. Not really what I call a fix for the problem...solution maybe, not a fix though. I'd prefer a fix. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-19 13:25:15

Brian Elfert was heard to say: >Reliable hardware? I keep getting one modem on a card that sits at "modem >unavailable" mode. Resetting the config, and trying a dozen other things >doesn't help. When I call 3Com, they just RMA the cards. > >I currently have one or two cards with a bad modem, and I returned two or >three quad modem cards due to this issue. What happens if you reseat the card? --Ricky

Subject: (usr-tc) Re: Modems getting stuck
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-19 13:39:41

On Mon, 19 Oct 1998, Brian K McIntire wrote: > Where are you seeing Modem Unavailable? > If you are seeing this in a performance Session monitor when monitoring the > T1 or PRI then the most common reason is the Line Interface Source on the > modem is either incorrect or after it was changed the T1 or PRI card did not > remap. Try setting it, saving it, and resetting the modem card. If you > have done all that then the modem card probably is bad. Either that or you > have your T1 card in a bad slot. I feel stupid. The line interface setting was bad. I don't know why I didn't try that before. I'm 99% sure I checked that on the cards that the 3Com techs gave me RMAs for. I still think reliability is an issue. Modems shouldn't just lose settings like that. Brian

Subject: (usr-tc) Re: Modems getting stuck
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-19 13:39:41

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-19 13:44:11

On Mon, 19 Oct 1998, Ricky Beam wrote: > Brian Elfert was heard to say: > >Reliable hardware? I keep getting one modem on a card that sits at "modem > >unavailable" mode. Resetting the config, and trying a dozen other things > >doesn't help. When I call 3Com, they just RMA the cards. > > > >I currently have one or two cards with a bad modem, and I returned two or > >three quad modem cards due to this issue. > > What happens if you reseat the card? Tried that. The chassis has been power cycled since then too. Actually, someone else gave me the answer this time. The line setting was wrong. I'm 99% sure in the past that this was checked before 3Com RMAed the cards. Brian

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-19 13:44:11

Subject: Re: (usr-tc) Requested Features
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-19 14:05:26

At 02:15 PM 10/19/98 -0400, Mike Andrews wrote: >On Sun, 18 Oct 1998, Richard Stuplich wrote: > >> How do I get my requests in for fixes to the HiperArc? >> >> 1. Idle times available with SNMP >> 2. Total connect time available with SNMP > >#2 is doable now -- the time-of-day that the session started is in there, >so all you need to do is subtract that from the current time to get the >length of the session. I'm not looking for a "work around", I am looking for a features to be added to the SNMP code. How do you request a feature? Sure you can sync your time with NTP and subtract one from the other, or do like I did and read the time the unit believes it is and then use that to subtract to get the connect time. This doesn't answer the question, how do we get requests in for features that need to be in the code? The Idle time unavailability would have stopped us from purchasing this unit, if we would have known that it lacked such a fundamental requirement of ours. * Don't tell me you can set the idle time during authentication, this is not what we need. We need the current Idle time available in any manner. Like the PM line. *

Subject: Re: (usr-tc) Requested Features
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-19 14:15:20

On Sun, 18 Oct 1998, Richard Stuplich wrote: > How do I get my requests in for fixes to the HiperArc? > > 1. Idle times available with SNMP > 2. Total connect time available with SNMP #2 is doable now -- the time-of-day that the session started is in there, so all you need to do is subtract that from the current time to get the length of the session. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound?

Subject: (usr-tc) ISDN: Netserver vs. Modems
From: Mark Lemmert <techmgr@dataex.com>
Date: 1998-10-19 14:17:05

Currently I am terminating the ISDN calls on the Netserver (I-ports) and am having problems with routes getting 'jammed' in the system for ISDN callers with static addresses. Essentially what happens is sometimes the caller will disconnect from a Netserver and the route for their static IP won't be flushed out, so they won't be connected but the route will remain. The client will then connect to a difference Netserver and a new route will be created on that server. I am broadcasting the routes via RIP so the border routers end up with two routes for the clients static IP when this happens and the client has problems. 3com has suggested that I terminate the ISDN calls on the quad modems instead of on the Netserver to solve this problem. Has any body else had this problem? Can anybody give an opinion on whether 3coms suggested fix is likely to have an affect on this? Thanks! Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: David Bolen <db3l@ans.net>
Date: 1998-10-19 14:35:55

"John Powell" <John_Powell@mw.3com.com> writes: > I think it was written by a UNIX junky. Kinda reminds me of un-tarring a > file ;) Aieee - please... don't insult us honest Unix programmers. I don't know of a single Unix programmer in the known universe that would force you to specify a filename via up to three discrete options (-nna/-vna or -nsd/-vsd and potentially -d) rather than just supply a filename on the command line. This was clearly written by a DOS/PC based programmer (perhaps more at home with assembly programs without user interfaces) who might have had a bit too much caffeine (or something) at the time :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: David Bolen <db3l@ans.net>
Date: 1998-10-19 14:35:55

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-19 14:39:36

At 11:41 AM 10/19/98 -0500, Brian Elfert wrote: > >On Sun, 18 Oct 1998, Allen Marsalis wrote: > >> problems, a smart admin, and a couple of really nice engineers at 3COM who >> really care. Combine this with a reliable hardware platform, and the fact >> that we had to run beta code anyway to get MPIP, and we really don't need >> total support for much.. at least not now. > >Reliable hardware? I keep getting one modem on a card that sits at "modem >unavailable" mode. Resetting the config, and trying a dozen other things >doesn't help. When I call 3Com, they just RMA the cards. > >I currently have one or two cards with a bad modem, and I returned two or >three quad modem cards due to this issue. > Well back when we decided to eliminate our Quake problems once and for all, we sold every netserver/quad modem chassis in the house! We purchased a considerable number of ARC/HDM chassis to replace these, and many more since then to accomodate growth. maybe 7 or 8 total.. We haven't had a single card go out on us however we did get a bad powersupply once in one of the chassis. Source Technology promptly replaced the unit and we somehow lost the bad unit instead of shipping it back. Source actually wrote it off, or took the hit, or something. Nice guys over there at Source.. Now if they could just get our support contract activated.. :-\ Allen

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-19 14:39:36

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-19 14:44:51

Subject: (usr-tc) NMC mess up with 0.0.0.0 address
From: Sean Barrett <sbarrett@cyberzone.net>
Date: 1998-10-19 15:07:17

Anybody know how to undo a 0.0.0.0 NIC address setting on a NMC card. We were clearing it out for a swap and now with the 0.0.0.0 address it keeps rebooting..... Worse yet- The company we were trading with did the same thing... :-) Sean Barrett CyberZone Internet

Subject: Re: (usr-tc) Requested Features
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-19 15:10:53

Mike Andrews was heard to say: >> 1. Idle times available with SNMP >> 2. Total connect time available with SNMP > >#2 is doable now -- the time-of-day that the session started is in there, >so all you need to do is subtract that from the current time to get the >length of the session. Accouting for DST and other such sh*t. Interesting story... back when we were using netblazers, someone went around resetting clocks for DST. (I warned them.) The net result was some users with negative online times. (And for an unsigned number....) --Ricky

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-19 15:12:18

David Bolen was heard to say: >"John Powell" <John_Powell@mw.3com.com> writes: >> I think it was written by a UNIX junky. Kinda reminds me of un-tarring a >> file ;) > >Aieee - please... don't insult us honest Unix programmers. Heh, it's supposed to be cryptic and difficult... it keep the *ahem* stupid people away from it. <grin> --Ricky

Subject: Re: (usr-tc) NMC mess up with 0.0.0.0 address
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-19 15:14:16

Sean Barrett was heard to say: >Anybody know how to undo a 0.0.0.0 NIC address setting on a NMC card. We >were clearing it out for a swap and now with the 0.0.0.0 address it >keeps rebooting..... Worse yet- The company we were trading with did the >same thing... :-) You need the flash *completely* erased... take the flash simm, put it in a netserver, flash it with the netserver code, put it back in the nmc, and flash it back with the NMC code. It is a mess, but it will erase the flash most effectively. --Ricky

Subject: Re: (usr-tc) NMC mess up with 0.0.0.0 address
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 15:17:10

I have worked with dozens of NMC's were someone reported this problem. I was able to resolve most of them by having them flip dips 5 & 6 on the NMC nac and reflash with pcsdl as the NMC comes up. -----Original Message----- >Sean Barrett was heard to say: >>Anybody know how to undo a 0.0.0.0 NIC address setting on a NMC card. We >>were clearing it out for a swap and now with the 0.0.0.0 address it >>keeps rebooting..... Worse yet- The company we were trading with did the >>same thing... :-) > >You need the flash *completely* erased... take the flash simm, put it in >a netserver, flash it with the netserver code, put it back in the nmc, and >flash it back with the NMC code. It is a mess, but it will erase the >flash most effectively. > >--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. >

Subject: Re: (usr-tc) ISDN: Netserver vs. Modems
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 15:20:40

Whenever you are discussing issues on this list please be more informative. There have been many issues with the NetServer over the years. What version are you running? Can't relate what you are doing to what I'm doing without knowing what version. By the way I would definately stop terminating calls on the NetServer Munich daughter board. In fact I would remove the munich daughter board. All its ever done is cause problems. -----Original Message----- >Currently I am terminating the ISDN calls on the Netserver (I-ports) >and am having problems with routes getting 'jammed' in the system >for ISDN callers with static addresses. > >Essentially what happens is sometimes the caller will disconnect >from a Netserver and the route for their static IP won't be flushed >out, so they won't be connected but the route will remain. The client >will then connect to a difference Netserver and a new route will >be created on that server. I am broadcasting the routes via RIP so >the border routers end up with two routes for the clients static IP >when this happens and the client has problems. > >3com has suggested that I terminate the ISDN calls on the quad modems >instead of on the Netserver to solve this problem. Has any body else >had this problem? Can anybody give an opinion on whether 3coms suggested >fix is likely to have an affect on this? Thanks! > > > > >Mark Lemmert cto@athenet.net >Chief Technical Officer (920)954-9799 >AthEnet Data Exchange http://www.athenet.net > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Re: Modems getting stuck
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 15:31:37

There are a variety of reasons why the settings may have not been saved on the modems. Make sure the NMC configuration group does not have a setting "Auto Config Upon Card Initialization" ENABLED. I would not recommend using this. The NMC will re program an reset card based on configurations in its own NVRAM. You can place good setting in its NVRAM if you always save chassis to nvram after making any changes but it's not worth the trouble and I know it doesn't work right with DSP's. Since most people are moving to DSP's now adays I just wouldn't use it. Also make sure you have a good rev level of NMC and TCM code when you save to nvram on the quads. If not you may be screwing something up there. One thing I can atest to is the quality of the Hardware 3COM uses. I have experience with close to 5,000 chassis' while and after working in an AOL service center. I can tell you we had very few problems overall when the Hardware was installed properly, with good grounds, ups, and configured and managed by experienced technicians. "Extremely reliable". AOL, as some of you may know, has close to 11,000 chassis now. Most are in production. They choose USR chassis and stuck with them because with a user base of over 17,000,000 they had to go with the best. Call me biased:-) I would have never gone to work for 3COM after AOL if I didn't love the product. -----Original Message----- > > >On Mon, 19 Oct 1998, Brian K McIntire wrote: > >> Where are you seeing Modem Unavailable? >> If you are seeing this in a performance Session monitor when monitoring the >> T1 or PRI then the most common reason is the Line Interface Source on the >> modem is either incorrect or after it was changed the T1 or PRI card did not >> remap. Try setting it, saving it, and resetting the modem card. If you >> have done all that then the modem card probably is bad. Either that or you >> have your T1 card in a bad slot. > >I feel stupid. The line interface setting was bad. I don't know why I >didn't try that before. I'm 99% sure I checked that on the cards that the >3Com techs gave me RMAs for. > >I still think reliability is an issue. Modems shouldn't just lose >settings like that. > >Brian > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Power Requirements
From: System Administrator <sysadmin@evcom.net>
Date: 1998-10-19 15:32:34

Can anyone tell me what the power requirements for a chassis with 6 HiperDSP, 1 HiperARC (that's sufficient, right?), and 1 NMC card would be? Is the 70amp module enough? Many thanks! -- Jesse Sipprell Technical Operations Director Evolution Communications, Inc. * Finger sysadmin@evcom.net for my PGP Public Key *

Subject: (usr-tc) Power Requirements
From: System Administrator <sysadmin@evcom.net>
Date: 1998-10-19 15:32:34

Subject: (usr-tc) Netserver assigned confusion?
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-19 15:36:14

Hi, I have a NetServer running: FX-1-NSVR> vers U.S. Robotics Total Control (tm) NETServer Card V.34/ISDN with Frame Relay V3.7.73 Build date: Mar 19 1998 From 'show global', I have the assigned and pool sizes set: Assigned Address: xxx.xxx.xxx.129 Reported Address: 0.0.0.0 Assigned Pool Size: 32 Periodic CHAP timeout: 0 And a show session shows this: S1 alleyat xxx.xxx.xxx.170 Netwrk In ESTABLISHED 34 0 S2 gaelon xxx.xxx.xxx.183 Netwrk In ESTABLISHED 11 0 S3 geben xxx.xxx.xxx.154 Netwrk In ESTABLISHED 4:54 0 S4 doniba xxx.xxx.xxx.187 Netwrk In ESTABLISHED 6 2 S5 sribe xxx.xxx.xxx.169 Netwrk In ESTABLISHED 2:36 0 S6 jinante varick-TC1-fx-15 Netwrk In ESTABLISHED 5 0 As you can see, there's plenty of IPs being assigned out of the specified range. None of these users have profiles that specify static IP addresses. Any ideas on how to fix this? I'd rather keep this rev of code as it's been working very well for us other than this little problem... Thanks, Charles =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: (usr-tc) Netserver assigned confusion?
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-19 15:36:14

Subject: Re: (usr-tc) NMC mess up with 0.0.0.0 address
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 15:36:22

Anyone with basic troubleshooting skills can figure out how to fix many of the problems we run accross. The software is fairly user friendly once you had a chance to read the documentation and play with it. I have seen the problem you are reporting below. I have duplicated it many times. My fix was the same as yours. But I was not happy leaving the rev level old. Try restoring from defaults on the NMC. Or just flip dip 5 on and flash it forward again. It should work. -----Original Message----- <MatthewS@staff.brunswickmicro.nb.ca> >On Monday, October 19, 1998 4:07 PM, Sean Barrett >[SMTP:sbarrett@cyberzone.net] wrote: >> Anybody know how to undo a 0.0.0.0 NIC address setting on a NMC card. We >> were clearing it out for a swap and now with the 0.0.0.0 address it >> keeps rebooting..... Worse yet- The company we were trading with did the >> same thing... :-) >> > >I ran into the same thing when performing a trade-up for a HiPerARC. >NETServer broke, got the trade-up card 2 days later. Installed it. Found >out the NMC needs a memory upgrade before it'll work with the HiPer (thanks, >Source). Ordered memory upgrade, got it 2 days later. Installed NMC memory >and flashed it with latest code. Upon reboot, the card started rebooting >continuously. So I called USR support. Can anyone guess what their >response was? "It must be a bad card, ship it back." Well crap, after >having 5 days downtime, I wasn't about to ship the NMC back to USR so they >could "repair or replace at their discretion within 10 to 15 working days". >I flashed it with code that was a little older and it worked great and >hasn't had a hiccup since. > >I'm a little concerned that USR is taking a knee-jerk reaction to troubles >and ordering a hardware replacement. I've never been formally trained on >this stuff yet I seem to do quite well at debunking most troubles. > >God help you if you don't have a hardware contract. And for God's sake, >don't let them pass you to Logistics if you don't have a contract. > >Be Seeing You... > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 >A quart of wheat for a day's wages, and three quarts of barley for a day's >wages, and do not damage the oil and the wine! >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) ISDN: Netserver vs. Modems
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-19 15:45:33

The true problem is usually that the RIP routes have to timeout on the border router (about 2-5 minutes wait time) before it will take the new route over the old one. I believe this is a problem inherent in RIP itself, and not in either the NETServer or the Quads. I've never tried terminating ISDN on the Digital Quads, but I would assume it would have the same RIP timeout problem, as the NETServer still is the thing that propagates the routes. I think 3Com is just throwing you a bone until they support OSPF (probably not anytime soon and even then you'll have to upgrade to ARC to get it). You might try it on one of your boxes (and I might try it on one of mine) and see if it makes a difference. I doubt it. Although, if what you're saying is that the routes NEVER disappear, then I haven't seen that problem before. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- 3com has suggested that I terminate the ISDN calls on the quad modems instead of on the Netserver to solve this problem. Has any body else had this problem? Can anybody give an opinion on whether 3coms suggested fix is likely to have an affect on this? Thanks!

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-19 15:49:28

: "John Powell" <John_Powell@mw.3com.com> writes: : : > I think it was written by a UNIX junky. Kinda reminds me of un-tarring a : > file ;) Quoth David Bolen: : Aieee - please... don't insult us honest Unix programmers. : : I don't know of a single Unix programmer in the known universe that : would force you to specify a filename via up to three discrete : options (-nna/-vna or -nsd/-vsd and potentially -d) rather than just : supply a filename on the command line. Thanks, David, for the defense. If it *was* written by a Unix coder, it was probably meant as a spoof on DOS programs.

Subject: Re: (usr-tc) Power Requirements
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-19 15:52:16

Yes -----Original Message----- >Can anyone tell me what the power requirements for a chassis with 6 >HiperDSP, 1 HiperARC (that's sufficient, right?), and 1 NMC card would be? >Is the 70amp module enough? > > >Many thanks! > >-- >Jesse Sipprell >Technical Operations Director >Evolution Communications, Inc. > >* Finger sysadmin@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. >

Subject: RE: (usr-tc) NMC mess up with 0.0.0.0 address
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-10-19 16:32:22

On Monday, October 19, 1998 4:07 PM, Sean Barrett [SMTP:sbarrett@cyberzone.net] wrote: > Anybody know how to undo a 0.0.0.0 NIC address setting on a NMC card. We > were clearing it out for a swap and now with the 0.0.0.0 address it > keeps rebooting..... Worse yet- The company we were trading with did the > same thing... :-) > I ran into the same thing when performing a trade-up for a HiPerARC. NETServer broke, got the trade-up card 2 days later. Installed it. Found out the NMC needs a memory upgrade before it'll work with the HiPer (thanks, Source). Ordered memory upgrade, got it 2 days later. Installed NMC memory and flashed it with latest code. Upon reboot, the card started rebooting continuously. So I called USR support. Can anyone guess what their response was? "It must be a bad card, ship it back." Well crap, after having 5 days downtime, I wasn't about to ship the NMC back to USR so they could "repair or replace at their discretion within 10 to 15 working days". I flashed it with code that was a little older and it worked great and hasn't had a hiccup since. I'm a little concerned that USR is taking a knee-jerk reaction to troubles and ordering a hardware replacement. I've never been formally trained on this stuff yet I seem to do quite well at debunking most troubles. God help you if you don't have a hardware contract. And for God's sake, don't let them pass you to Logistics if you don't have a contract. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 A quart of wheat for a day's wages, and three quarts of barley for a day's wages, and do not damage the oil and the wine! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-10-19 16:59:01

On Mon, 19 Oct 1998, David Bolen wrote: > Although tools such as TCM integrate the process, you can actually > perform NMC based uploads using discrete SNMP and tftp tools (say an > SNMP package and the stock tftp utility on a Unix system) if you > really wanted to. And this is documented where? Yes, I really want to. I hate using m$doze to manage the racks. -Dan

Subject: Re: (usr-tc) ISDN: Netserver vs. Modems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-19 17:28:13

Thus spake Peter D. Mayer >The true problem is usually that the RIP routes have to timeout on the >border router (about 2-5 minutes wait time) before it will take the new >route over the old one. I believe this is a problem inherent in RIP itself, >and not in either the NETServer or the Quads. I've never tried terminating >ISDN on the Digital Quads, but I would assume it would have the same RIP >timeout problem, as the NETServer still is the thing that propagates the >routes. That's inherent with RIP, but Cisco at least gives you a knob to adjust the timers. You can shorten them down so that its not a problem in this respect. This comes at the possible expense of stability of the network, but in a simple network, it shouldn't be a problem. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) ISDN: Netserver vs. Modems
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-19 18:03:11

Peter D. Mayer was heard to say: >I think 3Com is just throwing you a bone until they support OSPF (probably >not anytime soon and even then you'll have to upgrade to ARC to get it). >You might try it on one of your boxes (and I might try it on one of mine) >and see if it makes a difference. I doubt it. Actually, the ARC handles RIPv2 (multicast) much better than the netserver. Routes appear and disapper almost instantly. Doing things that drive the netservers nuts, the arc does just fine. (No 30-60 seconds waits for the route to be reannounced and accepted.) --Ricky

Subject: Re: (usr-tc) Re: Modems getting stuck
From: Jamie Orzechowski <mhz@recorder.ca>
Date: 1998-10-19 18:19:01

I have seen my PRI card loose it's settings about 3 times in 8 months ... usually just one of he SPAN's would loose it's switch type setting but the other SPAN would be fine ... -----Original Message----- > > >On Mon, 19 Oct 1998, Brian K McIntire wrote: > >> Where are you seeing Modem Unavailable? >> If you are seeing this in a performance Session monitor when monitoring the >> T1 or PRI then the most common reason is the Line Interface Source on the >> modem is either incorrect or after it was changed the T1 or PRI card did not >> remap. Try setting it, saving it, and resetting the modem card. If you >> have done all that then the modem card probably is bad. Either that or you >> have your T1 card in a bad slot. > >I feel stupid. The line interface setting was bad. I don't know why I >didn't try that before. I'm 99% sure I checked that on the cards that the >3Com techs gave me RMAs for. > >I still think reliability is an issue. Modems shouldn't just lose >settings like that. > >Brian > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) ISDN: Netserver vs. Modems
From: Mark Lemmert <techmgr@dataex.com>
Date: 1998-10-19 18:46:37

>Date: Mon, 19 Oct 1998 15:45:33 -0400 >From: "Peter D. Mayer" <dmayer@netwalk.com> >Subject: Re: (usr-tc) ISDN: Netserver vs. Modems > >The true problem is usually that the RIP routes have to timeout on the >border router (about 2-5 minutes wait time) before it will take the new >route over the old one. I believe this is a problem inherent in RIP itself, >and not in either the NETServer or the Quads. I've never tried terminating >ISDN on the Digital Quads, but I would assume it would have the same RIP >timeout problem, as the NETServer still is the thing that propagates the >routes. > >I think 3Com is just throwing you a bone until they support OSPF (probably >not anytime soon and even then you'll have to upgrade to ARC to get it). >You might try it on one of your boxes (and I might try it on one of mine) >and see if it makes a difference. I doubt it. > >Although, if what you're saying is that the routes NEVER disappear, then I >haven't seen that problem before. > >Peter D. Mayer >NetWalk System Administrator I don't think the problem I'm having is a RIP timeout issue. I used to have that 'classic' problem when static IP clients would redial and hit a different chassis, it would take 30-60 seconds for the old route on the Ciscos to die and the new one to take over. For anybody having that problem setup your Netservers to broadcast only with RIP version 2 and put the following in your Cisco RIP config ! router rip timers basic 30 180 0 240 15 ! I have had the above in place for 6-8 months and it works perfectly. The problem I am having is *sometimes* when an ISDN client disconnects the router never dies in the *Netserver*, it just sits there in some sort of limbo, pointed to interface RMT6000 or some such thing, and keeps getting broadcast to the Ciscos. When the client connects again, another route is created in another Netserver which is then broadcast and then the Ciscos have two routes for the same IP. I am running 3.7.72 on the Netservers, but I plan soon to upgrade to 3.8.1 3com is telling me that terminating the ISDN calls on the quad modems instead of the I ports will fix this, but I got the feeling they were reaching for something as opposed to they had seen this and had a fix. Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net

Subject: Re: (usr-tc) Requested Features
From: Laurie J Collinsworth <ljc1@cornell.edu>
Date: 1998-10-19 19:01:33

At 02:15 PM 10/19/98 -0400, Mike Andrews wrote: >On Sun, 18 Oct 1998, Richard Stuplich wrote: > >> How do I get my requests in for fixes to the HiperArc? >> >> 1. Idle times available with SNMP >> 2. Total connect time available with SNMP > >#2 is doable now -- the time-of-day that the session started is in there, >so all you need to do is subtract that from the current time to get the >length of the session. > > >Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org >VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net >Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ >If Milli Vanilli fell in the forest, would someone else make the sound? Mike has also wrote a very nice snmp utility called arcwho which has connect time. I pulled it off his usrtoys site. $ ./arcwho arc1 snmpwalk users... snmpwalk ips... snmpwalk pppstat... snmpwalk ppptype... snmpwalk starttime... snmpwalk slotchan... Port User Host/Inet/Dest Type Dir Status Time Idle ---- --------------- ---------------- ------- --- ------------- ------ ------ 101 rlg1-1connect 128.253.49.103 Netwrk In ESTABLISHED 3:54 n/a 102 cas52 128.253.49.20 Netwrk In ESTABLISHED 3:01 n/a 103 ss183 128.253.49.40 Netwrk In ESTABLISHED 3:51 n/a 104 seh22 128.253.49.95 Netwrk In ESTABLISHED 31 n/a 105 sl129 128.253.49.126 Netwrk In ESTABLISHED 6:29 n/a 106 dgg6 128.253.49.93 Netwrk In ESTABLISHED 6 n/a [snip] --- Laurie Collinsworth CIT/NCS Cornell University

Subject: (usr-tc) Get PMWHO for HiperArc
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-19 19:11:00

Whip it, Beat it, Make it look like a PortMaster! I know there is another solution for this but I don't like having to sync my time on the HiperArc with a system to ensure that the data is correct. The tool I created works without SNMP, without Synchronizing the times, it does everything, other than Idle times... The HiperArc kinda sucks. I have a version of pmcom as well that works, I just have to comment it up before I move it to the web site... http://home.dwave.net/arctools/ will get you the current hawho.c and when hacom.c is done it will be there as well. A great thanks goes out to the people who created pmwho and pmcom, without it I would have had no base to work from. Richard B. Stuplich DataWave, Not just faster, Better. President, DataWave Technologies 16 T1 circuits and growing strong. DataWave, Wausau's first local ISP to have a direct connection to the midwest NAP, a full T1, 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 1998 Richard Stuplich, see http://dw.net/cr/

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: David Bolen <db3l@ans.net>
Date: 1998-10-19 19:41:25

Dan Hollis <goemon@sasami.anime.net> writes: > how about tftp upload support for the NMC? The ARC can do it why cant the > NMC :-/ Um, since the upload process via the NMC has always been tftp (since the product was first introduced), is there something specific you are looking for? (The pcsdl/zmodem discussion is for the fallback serial approach only when in-band IP access to the NMC is unavailable for some reason). True, you have to first issue a small number of SNMP commands to let the NMC know just what slot(s) - including itself - you want the tftp to apply to, but that's sort of a natural consequence of it managing more than a single card (unlike the ARC), and it also permits the single tftp upload to be sent to any number of like cards in the chassis at once, which definitely helps with efficiency. Although tools such as TCM integrate the process, you can actually perform NMC based uploads using discrete SNMP and tftp tools (say an SNMP package and the stock tftp utility on a Unix system) if you really wanted to. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: David Bolen <db3l@ans.net>
Date: 1998-10-19 20:14:48

> And this is documented where? Well, the use of the chassis command tables for an SDL-1 software download (all the original cards with SDL/NAC file combinations) used to have a section in the SNMP MIB reference guide, at least as of the NMC 3.x documentation, which was the last time I really looked. The SDL-2 stuff (later cards with DMF files only) changed slightly, but only that you used an SDL2 function code in the slot command table, and sent the single DMF file rather than the SDL file and NAC file in two stages. I know things got re-arranged in the doc set later on, so I don't have a specific manual or section reference, but it should be with the NMC stuff. I just took a peek at a slightly dated online copy I had of the NMC 5.x CD documentation and it appears to have two SDL related documents - one for SDL-1 and one for SDL-2. They both include a chapter on doing it from a generic MIB browser. The short of it is that you use the chassis command table (uchasCmd) to issue a function request (uchasCmdFunction) for one or more slots for a softwareDownload or softwareDownload2 (SDL-1 or SDL-2) depending on the card types involved. That starts the process as follows (during the process the uchasCmdResult is the object polled in between steps, and uchasCmdResult/uchasCmdCode give final results): SDL-1: If any card but the NMC itself, first: * TFTP the SDL file to the NMC * Poll the command table (SNMP get) for transfer completion Then, for all card types: * TFTP the NAC file to the NMC * Poll the command table for final completion and results SDL-2 * TFTP the DMF file to the NMC * Poll the command table for final completion and results -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-19 20:49:42

: On Mon, 19 Oct 1998, David Bolen wrote: : > Although tools such as TCM integrate the process, you can actually : > perform NMC based uploads using discrete SNMP and tftp tools (say an : > SNMP package and the stock tftp utility on a Unix system) if you : > really wanted to. : : And this is documented where? I believe it's documented in the MIB reference, and in the NMC documentation. There's a lot of good stuff on the CDs they ship with TC hardware.

Subject: Re: (usr-tc) ISDN: Netserver vs. Modems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-19 21:03:21

Thus spake Mark Lemmert >3com is telling me that terminating the ISDN calls on the quad modems instead >of the I ports will fix this, but I got the feeling they were reaching for >something >as opposed to they had seen this and had a fix. Believe it or not, it might actually help. I know it doesn't seem related, but I remember some squirrely behavior from the NETServer when we terminated cards on the Munich board. You won't be disappointed by terminating ISDN on the quad's almost assuredly, so its a good step to take anyway, and who knows, it just might fix what you're seeing! I know it really sounds bizarre, but it wouldn't surprise me. You mentioned the route pointing to RMT6000 or something like that too...that almost sounds like its a tunnel'ed link coming from another NETServer...is that when you're seeing this happen? That might be something that's significant in this as well, FYI. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Whitespace in radacct logs (src included)
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-19 21:43:42

Maybe I haven't read enough documentation, but I was surprised to come across some RADIUS accounting entries with whitespace in odd places -- e.g., User-Name = "cbbarthon " That broke one of my midnight log file munchers, because it was expecting User-Name = "cbbarthon" Generalizing a bit, I'd imagine that User-Name = " cbbarthon " and User-Name = " cbbarthon" are just as likely to show up. Following is a gawk script that eats RADIUS accounting logs and spits out <username> <session length> for each Stop entry in the log, where <username> is what you'd expect and the <session length> is what you'd expect, in seconds. Maybe it'll be useful. It handles duplicate accounting records, but depends on uniqueness in the session ID for the period it's processing. In practice, you wouldn't want to push this past a month. #!/usr/bin/gawk -f ## Grok a radius log today! # lists the properly-closed sessions from the radacct logs from # the basic livingston radiusd from responses from USR 3.x Total-Control # netservers and HARCs # # Mark R. Lindsey <mark@datasys.net> # Mon Aug 3 23:06:52 EDT 1998 # update Mon Oct 19 21:34:51 EDT 1998 BEGIN { RS=""; } { for (field=1 ; field <= NF; ++field) { ## Grab the sessionId if ($field ~ /Acct-Session-Id/) sessionId=$(field+2); ## The record type if ($field ~ /Acct-Status-Type/) recordType=$(field+2); ## The user name in question ## -- The user name may look like one of these: ## "blah" case 1 ## " blah" case 2 ## "blah " case 3 ## " blah " case 4 if ($field ~ /User-Name/) { ### The userName is usually sitting here with ### a quote on each side -- usual_userName=$(field+2); ### chop off those quotes. This will either leave ### a username with no surrounding quotes ### (cases 1 & 3), or null (cases 2 & 4) gsub(/"/,"",usual_userName); ### if this is a case 3, then gaze right, and ### chop off all quotes. (probably only one in that ### case if (length(usual_userName) == 0) { usual_userName=$(field+3); gsub(/"/,"",usual_userName); } userName=usual_userName; } ## The session time; this will only be present if this ## is a stop record (recordType) if ($field ~ /Acct-Session-Time/) sessionTime=$(field+2); } } ## This checks to see if we have a `Stop' record, and, if so, if we've ## never seen this session before. (Sessions is a table of session ## IDs; note that session IDs can roll over -- don't depend on unique ## session IDs for more than a month) If so, then print out the username ## (minus surrounding quotes), and the length of the session in seconds. ## Then put this session in the Sessions table, in case of dups. (they ## happen) ((recordType == "Stop") && (!(sessionId in Sessions))) { printf("%s %010s\n", userName, sessionTime) ## We keep track of sessions, in case of dups Sessions[sessionId]=1 }

Subject: Re: (usr-tc) Requested Features
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-19 23:26:39

On Mon, 19 Oct 1998, Ricky Beam wrote: > Mike Andrews was heard to say: > >> 1. Idle times available with SNMP > >> 2. Total connect time available with SNMP > > > >#2 is doable now -- the time-of-day that the session started is in there, > >so all you need to do is subtract that from the current time to get the > >length of the session. > > Accouting for DST and other such sh*t. The ARC only understands GMT, and Unix keeps time internally as GMT, so this shouldn't really be an issue... > Interesting story... back when we were using netblazers, someone went around > resetting clocks for DST. (I warned them.) The net result was some users with > negative online times. (And for an unsigned number....) Oops. :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound?

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-20 00:48:31

yuck, yuck. Nothing quite like tossing an M80 in a snake pit ;) I was really just creating a diversion for Krish (and I knew that would stir up the pot a bit). I still want to know who the jerk is that required an "f" inadditon to the "x" when extracting a file with tar. That stumped me and pissed me off until I finally asked Krish for help (and that is painful in itself). I didn't want to come off defending pcsdl though, it is truly a piece of trash from a human interface perspective. I just wanted to note that some UNIX commands rival it on that front. Mostly for yucks though. On the note of the file that made me struggle with tar........ your SNMP tools. After figuring out my problem with tar, I tried getting that stuff running. When I ran usr I got the error "usr: can't load library 'libncurses.so.4'". I found a whole bunch of libncurses.so.xx, but no .4. I noticed all the other files were just links back to /usr/lib/libncurses.so.1.9.9e, so I just made another link from libncurses.so.4. Nice thought you say, but no go. When I did that I got a "page segmentation fault" error. I assume libncurses is some kind of library file and your program uses functions in that library. I am also guessing that I don't have the latest or something. Any quick tips (don't spend too much time on it)? JP David Bolen <db3l@ans.net> on 10/19/98 01:35:55 PM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) (KRISH!) "John Powell" <John_Powell@mw.3com.com> writes: > I think it was written by a UNIX junky. Kinda reminds me of un-tarring a > file ;) Aieee - please... don't insult us honest Unix programmers. I don't know of a single Unix programmer in the known universe that would force you to specify a filename via up to three discrete options (-nna/-vna or -nsd/-vsd and potentially -d) rather than just supply a filename on the command line. This was clearly written by a DOS/PC based programmer (perhaps more at home with assembly programs without user interfaces) who might have had a bit too much caffeine (or something) at the time :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, 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.

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-20 01:14:00

OOOOOOOOPS. Hit send and realized I sent to the group, not David directly as intended. . Time to go to get some sleep. Sorry for that. Not to say if anyone who knows libncurses wants to throw me a tip..... JP PS. I really do like Linux/Unix, just a bit frustrating at times ;) John Powell/MW/US/3Com 10/20/98 12:48 AM cc: (KRISH!) (Document link not converted) yuck, yuck. Nothing quite like tossing an M80 in a snake pit ;) I was really just creating a diversion for Krish (and I knew that would stir up the pot a bit). I still want to know who the jerk is that required an "f" inadditon to the "x" when extracting a file with tar. That stumped me and pissed me off until I finally asked Krish for help (and that is painful in itself). I didn't want to come off defending pcsdl though, it is truly a piece of trash from a human interface perspective. I just wanted to note that some UNIX commands rival it on that front. Mostly for yucks though. On the note of the file that made me struggle with tar........ your SNMP tools. After figuring out my problem with tar, I tried getting that stuff running. When I ran usr I got the error "usr: can't load library 'libncurses.so.4'". I found a whole bunch of libncurses.so.xx, but no .4. I noticed all the other files were just links back to /usr/lib/libncurses.so.1.9.9e, so I just made another link from libncurses.so.4. Nice thought you say, but no go. When I did that I got a "page segmentation fault" error. I assume libncurses is some kind of library file and your program uses functions in that library. I am also guessing that I don't have the latest or something. Any quick tips (don't spend too much time on it)? JP David Bolen <db3l@ans.net> on 10/19/98 01:35:55 PM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) (KRISH!) "John Powell" <John_Powell@mw.3com.com> writes: > I think it was written by a UNIX junky. Kinda reminds me of un-tarring a > file ;) Aieee - please... don't insult us honest Unix programmers. I don't know of a single Unix programmer in the known universe that would force you to specify a filename via up to three discrete options (-nna/-vna or -nsd/-vsd and potentially -d) rather than just supply a filename on the command line. This was clearly written by a DOS/PC based programmer (perhaps more at home with assembly programs without user interfaces) who might have had a bit too much caffeine (or something) at the time :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, 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.

Subject: Re: (usr-tc) NMC mess up with 0.0.0.0 address
From: Matthew Opoka <phantom@magnolia.net>
Date: 1998-10-20 01:15:47

Flash too and old old code then fix the address and flash back to a new code. -----Original Message----- >Anybody know how to undo a 0.0.0.0 NIC address setting on a NMC card. We >were clearing it out for a swap and now with the 0.0.0.0 address it >keeps rebooting..... Worse yet- The company we were trading with did the >same thing... :-) > > >Sean Barrett >CyberZone Internet > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-20 08:55:52

On Tue, 20 Oct 1998, John Powell wrote: > I still want to know who the jerk is that required an "f" inadditon to the > "x" when extracting a file with tar. That stumped me and pissed me off > until I finally asked Krish for help (and that is painful in itself). I > didn't want to come off defending pcsdl though, it is truly a piece of > trash from a human interface perspective. I just wanted to note that some > UNIX commands rival it on that front. Mostly for yucks though. Keep in mind tar is "tape archiver". That explains the "f". If you ran it without "f", it would still work, provided you had a tape loaded up ;) And don't forget about those man pages, they document everything. Curious about coding style? Try "man style" or "man perlstyle" (yep, doesn't apply to all Unices, but most free ones). And don't forget the infamous "man man". Generally the difference I've found between UNIX and DOS is that with UNIX you can slowly understand the "why" such as in the above example. With DOS, sometimes you figure out the "why" and it's just "oh, it's an OS that Gates bought for $50,000 some years ago"... Charles > > On the note of the file that made me struggle with tar........ your SNMP > tools. > > After figuring out my problem with tar, I tried getting that stuff running. > When I ran usr I got the error "usr: can't load library 'libncurses.so.4'". > I found a whole bunch of libncurses.so.xx, but no .4. I noticed all the > other files were just links back to /usr/lib/libncurses.so.1.9.9e, so I > just made another link from libncurses.so.4. Nice thought you say, but no > go. When I did that I got a "page segmentation fault" error. > > I assume libncurses is some kind of library file and your program uses > functions in that library. I am also guessing that I don't have the latest > or something. Any quick tips (don't spend too much time on it)? > > JP > > > > > > > David Bolen <db3l@ans.net> on 10/19/98 01:35:55 PM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (John Powell/MW/US/3Com) > Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , > (KRISH!) > > > > > "John Powell" <John_Powell@mw.3com.com> writes: > > > I think it was written by a UNIX junky. Kinda reminds me of un-tarring a > > file ;) > > Aieee - please... don't insult us honest Unix programmers. > > I don't know of a single Unix programmer in the known universe that > would force you to specify a filename via up to three discrete > options (-nna/-vna or -nsd/-vsd and potentially -d) rather than just > supply a filename on the command line. > > This was clearly written by a DOS/PC based programmer (perhaps more at > home with assembly programs without user interfaces) who might have > had a bit too much caffeine (or something) at the time :-) > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, 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. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-20 09:44:20

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-20 11:02:53

On Tue, 20 Oct 1998, Kevin Benton wrote: > FYI: tar without the f option will make or get its archive from > stdin/stdout. > > tar c . | ( cd some_other_directory ; tar xv ) > > This will copy a directory and everything below it to another directory. OOPS! I too goofed. I just realized that this is not true for all implementations of tar. Charles makes a great point about checking man for the proper way to use it, though I must caution everyone that some man pages don't always match the command (esp. on Linux where they're not keeping man pages up to date enough for my liking). E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: (usr-tc) Re: ISDN: Netserver vs. Modems
From: Mark Lemmert <cto@athenet.net>
Date: 1998-10-20 11:10:38

Thus spake Mark Lemmert >>3com is telling me that terminating the ISDN calls on the quad modems instead >>of the I ports will fix this, but I got the feeling they were reaching for >>something >>as opposed to they had seen this and had a fix. >Believe it or not, it might actually help. I know it doesn't seem >related, but I remember some squirrely behavior from the NETServer when >we terminated cards on the Munich board. You won't be disappointed by >terminating ISDN on the quad's almost assuredly, so its a good step to >take anyway, and who knows, it just might fix what you're seeing! I >know it really sounds bizarre, but it wouldn't surprise me. > >You mentioned the route pointing to RMT6000 or something like that >too...that almost sounds like its a tunnel'ed link coming from another >NETServer...is that when you're seeing this happen? That might be >something that's significant in this as well, FYI. >- -- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 I'm not sure if these jammed routes are left over from a tunneled link or if they are from the original connection. I guess it might make sense that it is the tunneled link as there are some issues with 3.7.24 and MPIP. I think I will take 3coms advise on this and see if it or upgrading to 3.8.1 fixes the problem. Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? ,
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-20 11:13:00

>Keep in mind tar is "tape archiver". That explains the "f". If you ran >it without "f", it would still work, provided you had a tape loaded up ;) When I did, it just sat there (obviously waiting for a tape)....for hours No error like: "a tape drive doesn't exist <you idiot>" that would have clued me in to the problem. Most DOS programs (and to be fair, most UNIX programs) will at least give you some kind of "hey dummy" error that will set you on the right path to t-shooting the problem. >And don't forget about those man pages, they document everything. Unfortunately, the most common use I have seen for tar is similar to pkzip/pkunzip. Though "f" is documented in every book and the man page, it is not intuitive if you don't understand the historical purpose of the program. -f, --file [HOSTNAME:]F use archive file or device F (default /dev/rmt0) That line makes complete sense AFTER I was told to use it and the history of tar, it did not even occur to me it was applicable when I was struggling with it. Seems about 30% of the UNIX commands follow this trend (all with good historical reasons, I'm sure). Maybe I should just learn C and modify tar to create my own "jpzip" and "jpunzip" and make it work like a stupid DOS user, like me, would expect. Even better, instead of jpzip, I'll name it after my dog. I can see it now:"spot -p -r filename.tar.gz *.*" and "unspot -d filename.tar.gz" ;-) Anyway, this has drifted off-topic enough. My fault, sorry. Thanks for the suggestions, and witholding the flames I deserved on this thread (I'll get those in-person at the office). JP

Subject: Re: (usr-tc) New to list and USR, how do I upgrade TC modems? , (KRISH!)
From: John T. Farmer <jfarmer@goldsword.com>
Date: 1998-10-20 11:25:17

On Tue, 20 Oct 1998 09:44:20 -0400 (EDT) Kevin Benton said: >tar c . | ( cd some_other_directory ; tar xv ) > >This will copy a directory and everything below it to another directory. >As you can imagine, Unix is something that grows on you. Considering that >it was written initially about 20 years ago, not bad for an OS 2/3rd's my >age... :) As you can imagine, Unix has come a long way with getting more Actually, if your 30, then Unix predates you :^> Ken Thompson & Co. had the first version running on a cast off PDP-7 in early 1969. It made it's way out to the Universities in '74. (The famous Version 6 package...) And many of it's design ideas were based on Ken Thompson & Dennis Ritchie's experences with the GE MULTICS system before that... John <There's my off-topic $0.02 worth...> John T. Farmer Proprietor, GoldSword Systems jfarmer@goldsword.com Public Internet Access in East Tennessee Office: (423)691-6498 for info, e-mail to info@goldsword.com Network Design, Internet Services & Servers, Consulting

Subject: (usr-tc) pmwho/pmcom for hiperarc (hawho/hacom)
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-20 12:08:26

I have finished my hawho and hacom programs. These are based on the program pmcom. Without PMCOM, and it's authors, hawho and hacom would not exist. These tools are specifically written for the poor Portmaster users who have a few misplaced 3com hiper access chassis in their equipment rooms. HAWHO slaps a hiperarc up a bit and gets a coherent Livingston 'sh ses' output from it without SNMP tools and without using NTP, synchronizing times or whatever other bull crap is needed to do this with SNMP. I still plan on making hacom look to see if it is a portmaster or a hiperarc and work on both. That way a single tool could be used to make a hiperarc more like a portmaster. HACOM sends commands to a hiperarc and shows the results. If you use pmcom for managing portmasters this tool will be a welcome addition to your suite of tools. If you make fixes or updates to this code, please mail me so I can update my software as well. I would do the same for you. Thanks! http://www.dw.net/arctools/ mailto:dick@dwave.net hawho.c connects to a hiperarc and then issues a "sh time" and gets the current time the device thinks it is, issues a "list con" and calculates the current connect lenghts and remembers, issues a "list ip route" and matchs up with data from "list con", prints results in this form: Port User Host/Inet/Dest Type Dir Status Start Idle ---- --------------- ---------------- ------- --- ------------- ------ ------ Sah wesley 207.0.68.244 Netwrk In ESTABLISHED 13:59 0 NOTE: The Start is the toal connect time, just like a "sh ses" on a Portmaster. If the hiperarc wasn't so useless as to not have idle time available (in any form) I'd have idle times correct as well, it doesn't so I don't. It always says 0 for idle times. 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, a full T1, 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 1998 Richard Stuplich, see http://dw.net/cr/

Subject: RE: (usr-tc) pmwho/pmcom for hiperarc (hawho/hacom)
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-20 13:49:31

pmwho and pmcom will do this. Search on altavista for +pmwho +pmcom At least the netserver code I have works just like a Portmaster, making the device very easy to use and have all the features an ISP would need, includeing Idle times. :-) At 03:04 PM 10/20/98 -0300, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: >On Tuesday, October 20, 1998 2:08 PM, Richard Stuplich [SMTP:dick@dwave.net] >wrote: >> >> These tools are specifically written for the poor Portmaster users who >have >> a few misplaced 3com hiper access chassis in their equipment rooms. >> > >Does anybody know if there are any such tools for the NETServer card? I >realize that the NETServer probably can't list users through SNMP and it >would probably involve something close to an 'expect' script, but I just >thought I'd ask... > >Be Seeing You... > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 >A quart of wheat for a day's wages, and three quarts of barley for a day's >wages, and do not damage the oil and the wine! >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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, a full T1, 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 1998 Richard Stuplich, see http://dw.net/cr/

Subject: RE: (usr-tc) pmwho/pmcom for hiperarc (hawho/hacom)
From: Bob Fager <rdfager@cube.ice.net>
Date: 1998-10-20 13:57:58

pmwho and pmcom work on a netserver with almost no modification since the netserver's OS is nearly the same as a PM's OS. If you're having problems getting it to work send me an email and I'll be glad to send you the code that works on our netservers. Bob On Tue, 20 Oct 1998, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: > > Does anybody know if there are any such tools for the NETServer card? I > realize that the NETServer probably can't list users through SNMP and it > would probably involve something close to an 'expect' script, but I just > thought I'd ask... > > Be Seeing You... > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 > A quart of wheat for a day's wages, and three quarts of barley for a day's > wages, and do not damage the oil and the wine! > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Interfaces falling down
From: Dave Martin <dpm@netcetera.com>
Date: 1998-10-20 14:03:51

We have one TC chassis (TCS 3.1.2) with an ARC, 2 DSPs and 12 Quads that occasionally starts downing various of the modem interfaces. It seems to happen more often on the DSPs, but it happens on the Quads, too. Reseting/rebooting the Quads/DSPs doesn't help, nor does rebooting the ARC. Cycling power to the chassis doesn't have any effect. The only procedure that has brought the interfaces back up is to physically remove all the NICs & NACs and reinsert them one by one. Not fun for remote POPs. I have hesitated to upgrade the ARC to 4.1.11 since the ISP that owns the equipment does have clients with WebTV thingies that have connection problems with this release. Questions: Has anyone experienced the above problem? If so, did upgrading the ARC firmware fix the problem? If so, what version did you upgrade to? I'm opening a trouble ticket for this problem, but wanted to share your experiences before the 1st level 3com tech support "engineer" instructs me to send back the whole chassis with all the cards to fix the problem ;-) TIA... Dave Martin Netcetera, Inc. dpm@netcetera.com "Infinity Welcomes Careful Drivers"

Subject: Re: (usr-tc) Re: ISDN: Netserver vs. Modems
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-20 14:30:08

Actually their suggestion makes perfect sense now that you say it's the Virtual ports that are hanging. I have noticed this problem from time to time myself, I guess it's just that none of the hung ports had a static IP so I didn't pay any attention to it and they disappeared eventually. Maybe if you use the Quad's S ports to terminate instead of the ISDN gateway's I ports then there are no Virtual ports, and thus no chance of the port hanging? I could see their logic in having you switch then. I may try it on several of my chassis in the next week and see how it affects things. I'll let you know if any good or bad things happen. Just to get this straight, do you set the "ISDN-GW Slot" to 1 or 0 to terminate on the quads? Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- Thus spake Mark Lemmert >>3com is telling me that terminating the ISDN calls on the quad modems instead >>of the I ports will fix this, but I got the feeling they were reaching for >>something >>as opposed to they had seen this and had a fix. >Believe it or not, it might actually help. I know it doesn't seem >related, but I remember some squirrely behavior from the NETServer when >we terminated cards on the Munich board. You won't be disappointed by >terminating ISDN on the quad's almost assuredly, so its a good step to >take anyway, and who knows, it just might fix what you're seeing! I >know it really sounds bizarre, but it wouldn't surprise me. > >You mentioned the route pointing to RMT6000 or something like that >too...that almost sounds like its a tunnel'ed link coming from another >NETServer...is that when you're seeing this happen? That might be >something that's significant in this as well, FYI. >- -- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 I'm not sure if these jammed routes are left over from a tunneled link or if they are from the original connection. I guess it might make sense that it is the tunneled link as there are some issues with 3.7.24 and MPIP. I think I will take 3coms advise on this and see if it or upgrading to 3.8.1 fixes the problem. Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Re: ISDN: Netserver vs. Modems
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-20 14:39:56

Thus spake Peter D. Mayer >Just to get this straight, do you set the "ISDN-GW Slot" to 1 or 0 to >terminate on the quads? 0 -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: RE: (usr-tc) pmwho/pmcom for hiperarc (hawho/hacom)
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-10-20 15:04:55

On Tuesday, October 20, 1998 2:08 PM, Richard Stuplich [SMTP:dick@dwave.net] wrote: > > These tools are specifically written for the poor Portmaster users who have > a few misplaced 3com hiper access chassis in their equipment rooms. > Does anybody know if there are any such tools for the NETServer card? I realize that the NETServer probably can't list users through SNMP and it would probably involve something close to an 'expect' script, but I just thought I'd ask... Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 A quart of wheat for a day's wages, and three quarts of barley for a day's wages, and do not damage the oil and the wine! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: Re: (usr-tc) pmwho/pmcom for hiperarc (hawho/hacom)
From: Leon McCalla <ascend@caribbeanlink.com>
Date: 1998-10-20 15:53:30

the latest versions of pmwho will do this. look at the revision history and you'll see that it was tweaked this year to accomodate netservers. Leon

Subject: (usr-tc) Porting Linux to the Netserver
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-20 16:04:33

Howdy, all -- I've a question: just what would it take to port Linux to the Netserver? I understand that it's using a 486 CPU; most have 16 meg of RAM and a 2 meg flash device is plenty for a small system. If we could port Linux to the Netserver, we'd have an open-source system that *we* could adapt to our needs, with the nice features provided by the TCs' call-termination hardware. Thougts?

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: David Bolen <db3l@ans.net>
Date: 1998-10-20 16:20:17

mark@vielle.datasys.net (Mark R. Lindsey) writes: > I've a question: just what would it take to port Linux to the Netserver? > I understand that it's using a 486 CPU; most have 16 meg of RAM and > a 2 meg flash device is plenty for a small system. At a minimum, 3Com would have to agree to release a few technical details about interfacing with the NIC, or you'd never get on the ethernet :-) You'd also have to deal with the fact that it could only run as an embedded system without a local disk. I suppose for some items that would be fine though. Clearly also, without information from 3Com on the technical details of packet bus interfacing you'd be an isolated card within the chassis. But I think the biggest problem is going to be getting the code onto the card - there's no media to use, and without much more information from 3Com on SDL file formats I can't see how to properly install Linux (and even with that you'd have to be able to create a binary that understands during the boot process that it is loading from flash). IMO, the whole thing might be theoretically doable, but it would need quite a bit of internals information from 3Com. The EdgeServer is a nicer platform for this sort of thing (although you'd still need the NIC information, that would be it) since its a much closer match for a PC and can still do things like access the packet and management busses, but of course, that's not a solution to NETServer card reuse :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Interfaces falling down
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-20 16:41:11

You should be running at least 4.0.30. To answer your question, yes, I have seen this before. One of the reasons for the problem occuring with one of the customer's I dealt with was there was one card in the chassis that was causing garbage on the packet bus. You may want to try inserting one card at a time and see if you can tell when it starts to mess up again. When it does you know what card is doing it. It could be the HiPer ARC code. I had another issue where the fix was to connect to the console of the HiPer ARC and type delete config, run quick setup and reconfigure. Hipe this helps. -----Original Message----- >We have one TC chassis (TCS 3.1.2) with an ARC, 2 DSPs and 12 Quads that >occasionally starts downing various of the modem interfaces. It seems to >happen more often on the DSPs, but it happens on the Quads, too. >Reseting/rebooting the Quads/DSPs doesn't help, nor does rebooting the ARC. >Cycling power to the chassis doesn't have any effect. The only procedure >that has brought the interfaces back up is to physically remove all the >NICs & NACs and reinsert them one by one. Not fun for remote POPs. > >I have hesitated to upgrade the ARC to 4.1.11 since the ISP that owns the >equipment does have clients with WebTV thingies that have connection >problems with this release. > >Questions: > >Has anyone experienced the above problem? >If so, did upgrading the ARC firmware fix the problem? >If so, what version did you upgrade to? > >I'm opening a trouble ticket for this problem, but wanted to share your >experiences before the 1st level 3com tech support "engineer" instructs me >to send back the whole chassis with all the cards to fix the problem ;-) > >TIA... > > >------------------------------------------------------------------------ >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. >

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-20 16:57:37

Mark R. Lindsey was heard to say: >I've a question: just what would it take to port Linux to the Netserver? >I understand that it's using a 486 CPU; most have 16 meg of RAM and >a 2 meg flash device is plenty for a small system. 1) 4meg of flash or more -- 8M would probably be plenty. 2) board level information pertaining to its "PC"ness 3) information for programming the midplane packet bus/TDM bus logic 4) information on the management bus protocols (if you want the NMC to still work with it.) 5) information on the packet bus protocol used to communicate with the modem cards. >If we could port Linux to the Netserver, we'd have an open-source system >that *we* could adapt to our needs, with the nice features provided by >the TCs' call-termination hardware. It would not be a totally open-source system. There are parts of the source that would have to be protected as trade-secrets -- ie. the bus protocols and logic interface protocols. What you would have is an embedded Linux system. I would certainly like to see this. At one point, I think USR was working on FBSD for the Edgeserver series hardware. But that was just rumor or sales babel. --Ricky

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-20 16:59:51

David Bolen was heard to say: >You'd also have to deal with the fact that it could only run as an >embedded system without a local disk. I suppose for some items that >would be fine though. Ever seen a netblazer... everything is on one 1.44M floppy. It runs in 4M of RAM and ... --Ricky

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-20 17:21:45

Hm. There is a version of FreeBSD that can be crammed down to floppy size, or run from flash. See http://www.freebsd.org/~picobsd. As has been mentioned, you'd still have the not-so-minor detail of how to program the packet bus and other proprietary hardware, but it's a start. I've been meaning to try it out on my router at home so I can remove the hard disk from it... Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound? On Tue, 20 Oct 1998, David Bolen wrote: > mark@vielle.datasys.net (Mark R. Lindsey) writes: > > > I've a question: just what would it take to port Linux to the Netserver? > > I understand that it's using a 486 CPU; most have 16 meg of RAM and > > a 2 meg flash device is plenty for a small system. > > At a minimum, 3Com would have to agree to release a few technical > details about interfacing with the NIC, or you'd never get on the > ethernet :-) > > You'd also have to deal with the fact that it could only run as an > embedded system without a local disk. I suppose for some items that > would be fine though. > > Clearly also, without information from 3Com on the technical details of > packet bus interfacing you'd be an isolated card within the chassis. > > But I think the biggest problem is going to be getting the code onto > the card - there's no media to use, and without much more information > from 3Com on SDL file formats I can't see how to properly install > Linux (and even with that you'd have to be able to create a binary > that understands during the boot process that it is loading from > flash). > > IMO, the whole thing might be theoretically doable, but it would need > quite a bit of internals information from 3Com. > > The EdgeServer is a nicer platform for this sort of thing (although > you'd still need the NIC information, that would be it) since its a > much closer match for a PC and can still do things like access the > packet and management busses, but of course, that's not a solution to > NETServer card reuse :-) > > -- David > > /-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, 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. >

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: David Bolen <db3l@ans.net>
Date: 1998-10-20 17:30:42

Ricky Beam <jfbeam@Interpath.net> writes: > I would certainly like to see this. At one point, I think USR was working > on FBSD for the Edgeserver series hardware. But that was just rumor or > sales babel. You can use BSD/OS 2.1 on the original EdgeServer (I forget which parts are formally available from BSDI or which from 3Com - likely not published, but probably available via request), and BSD/OS 4.0 is supported directly (or maybe you get an ethernet driver from 3Com, I forget) on the EdgeServer/PRO. This doesn't include management/packet bus stuff, but just operating it as a rack mounted PC (which is enormously useful IMO on its own). Porting FreeBSD (or really any of the Unixes) would be easy if 3Com would publish just a small number of items about NIC communication. Given the 2 100bT ports on the EdgeServer/PRO, 2 2GB disks, 2 processors, one could imagine this to be a pretty useful (albeit pricey) ISP machine - think 5 of them rack mounted in 8.75" of space. While BSD/OS certainly works, I wonder if a case could be made for releasing that info if thinking that the free Unixes would increase popularity? -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: David Bolen <db3l@ans.net>
Date: 1998-10-20 17:32:29

Ricky Beam <jfbeam@Interpath.ne> writes: > Ever seen a netblazer... Yeah, rejected them as an option for our network back in '94 :-) > everything is on one 1.44M floppy. It runs in > 4M of RAM and ... As I said, it would probably be fine though. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: David Bolen <db3l@ans.net>
Date: 1998-10-20 17:43:00

Mike Andrews <mandrews@termfrost.org> writes: > As has been mentioned, you'd still have the not-so-minor detail of how to > program the packet bus and other proprietary hardware, but it's a start. But it's kind of a non-starter unless you first solve the problem of how to download your proposed kernel to the flash/hardware to try to run it :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-20 17:58:54

: Hm. There is a version of FreeBSD that can be crammed down to floppy : size, or run from flash. See http://www.freebsd.org/~picobsd. A full linux installation could easily fit in 2 megabytes. Lots of people use the results of the Linux Router Project -- LRP -- that puts everything you need for a basic router, including gated, on a floppy. And if I'm not mistaken, the typical FreeBSD installation starts with a single floppy. I don't think the 2 meg flash device is a problem.

Subject: Re: (usr-tc) Dumb question: PRIs and analog calls
From: Vito Maselli <vito_maselli@mw.3com.com>
Date: 1998-10-20 19:10:58

Mike, Your e-mails a little confusing. When you say ver 2.5.1 your talking about your Dual T1/PRI card. When you mention 3.8.1 your talking about your Netserver card. Are you trying to upgrade your TC Hub to TCS 3.3 ( System release 3.3) ? Vito "Mike Hamrich" <mhamrich@drfast.net> on 10/01/98 06:33:09 PM Please respond to usr-tc@lists.xmission.com cc: (Vito Maselli/MW/US/3Com) How do you install the V.90 3.8.1 release. Is there any magic order of cards that should be followed. Also is it OK to go from 2.5.1 to 3.8.1 my predecessor did not keep the chassis to current :) Dave Winston -----Original Message----- >On Wed, 30 Sep 1998, Mark R. Lindsey wrote: > >> Thanks for the help. >> >> Would I be right to guess that v.90 and X2 work on such lines, too. > >Yup. In theory it should work *better* with PRI than with CT1, because of >the extra 8K of bandwidth per channel. (23 channels of 64K instead of 24 >channels of 56K (b8zs) or 48K (ami)). We've never actually tried using >CT1 here so I can't back that up with personal experience, but I can say >that we have people getting 53333 connects with v.90 on our PRI's... > > >[munch] >> : >Thus spake Mark R. Lindsey >> : >>Can a cht1 card, and the quad modems it talks to, or an HDM, be configured >> : >>to terminate a PRI that takes calls both from analog modems and ISDN >> : >>users? >> : > >> : >>Excuse my ignorance, please; I've never worked with ISDN. I've been under >> : >>the impression that PRI == ISDN calls only, but our BellSouth salespeople >> : >>told us that they can send analog calls down the B channels. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Radius auth problems with ARC
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-20 22:30:13

Ok, so I got my first HiPer box last week and I'm just now configuring it. Everything seems setup properly so I tried to dial in. I get a nice 48000/V.90 connect and hit the login prompt. Typed my username and password and was denied. So to the syslogs I go. Quite simply "Unable to authenticate user". Then I looked at my Radius error logs and found odd usernames and passwords that look almost like mine, but not quite. Radius secret problem right? Maybe not. I switched my secret on the ARC and the radius server told me I had the wrong one. Then I reset it on both sides and restarted the radius server and the secrets don't match error dropped out. I've set up this box just like my other 8 (NETServers) in the radius server, and used the same secret for all of them. I've tried darn near every authentication setting I can find, with the same results. Suffice it to say that A) the server is allowed to send packets to my radius server, and B) I've triple checked that the secret is the same. I even broke down and tried the HARM (amazingly like the old NETServer manager isn't it?) to configure it, same results. Anybody else have these kind of problems on initial config of the ARC? What might I be missing? I've even deleted the whole config and started from scratch. Any input is greatly appreciated. BTW: is there a "Migration Guide" of sorts to help us reasonably advanced NETServer users quickly learn our way around the Hiper equipment? I feel very out-of-sorts wandering around the ARC command line. (feels like there might be 30 settings I'm missing, but they're buried under 10 layers of command structure). Probably not. Oh well. Thanks for any suggestions, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-20 22:52:09

At 05:43 PM 10/20/98 EDT, David Bolen wrote: >Mike Andrews <mandrews@termfrost.org> writes: > >> As has been mentioned, you'd still have the not-so-minor detail of how to >> program the packet bus and other proprietary hardware, but it's a start. > >But it's kind of a non-starter unless you first solve the problem of >how to download your proposed kernel to the flash/hardware to try to >run it :-) Is the pcsdl software on the netserver/harc side contained in or part of the flash? or does it reside in ROM somewhere?.. If it is part of the flash itself, then one does not necessarily have to adopt that exact same protocol do they? If the first pcsdl session uploaded "your" code and save it and rebooted, then the next pcsdl session doesn't have to be "pcsdl" at all, but anything you choose to code into it right? Now if the actual serial code is in ROM, then can't it be read and later disassembled? So either way, it seems "doable".. The sign of a situation where the actual serial drivers are embedded in the flash, is when a device can become "unflashable" due to an interruption in a previous flash or something. If it's in ROM, the device should always be able to receive a new flash.. Anyone ever crash/corrupt a netservers or hiperarcs flash memory so bad, the card was kaput and wouldn't even accept a download? Compiling and moving the binary data into flash doesn't seem to be as big an obsticle as knowing the address map and packet bus info like you say. Is the flash removable? I forget, hadn't seen a netserver in so long.. If so, surely it can be flashed by other means.. (the first time anyway) Related question. I heard early on that the hiperarc booted with a "kernel" of sorts much like unix and was curious as to how unix like (internally) is the hiperarc? (i.e. is it based on any familar kernels we might have heard of? or are they just calling their bootstrap a kernel to be cool.) Allen > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, 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. > >

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-20 23:00:13

David Bolen was heard to say: >Given the 2 100bT ports on the EdgeServer/PRO, 2 2GB disks, 2 >processors, one could imagine this to be a pretty useful (albeit >pricey) ISP machine - think 5 of them rack mounted in 8.75" of space. >While BSD/OS certainly works, I wonder if a case could be made for >releasing that info if thinking that the free Unixes would increase >popularity? As I understand it, the ethernet on the ARC (100bT) is PCI based. As long as the system can see the PCI data, then it should work. That adds a new meaning to "cluster"... 16 "PC"s in one USR chassis? If anyone has an Edgeserver Pro, put linux on a floppy and see if it boots. That's the first step :-) --Ricky

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-20 23:01:34

David Bolen was heard to say: >Ricky Beam <jfbeam@Interpath.ne> writes: >> Ever seen a netblazer... > >Yeah, rejected them as an option for our network back in '94 :-) If I could get a netblazer on a card for the TC, I would worship its creator. --Ricky

Subject: Re: (usr-tc) Radius auth problems with ARC
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-20 23:11:05

Peter D. Mayer was heard to say: >So to the syslogs I go. Quite simply "Unable to authenticate user". Then I >looked at my Radius error logs and found odd usernames and passwords that >look almost like mine, but not quite. Radius secret problem right? Maybe >not. Have you tried to capture some network traffic and see what the packet actually looks like? The password is encrypted, but the rest of the packet should be readable. (unless it hashed the entire packet?) >the secret is the same. I even broke down and tried the HARM (amazingly >like the old NETServer manager isn't it?) to configure it, same results. Except HARM is SNMP based. If HARM can do it, you can do it. HARM just packages things better than the crazy, albeit an improvement, command-line. >BTW: is there a "Migration Guide" of sorts to help us reasonably advanced >NETServer users quickly learn our way around the Hiper equipment? I feel >very out-of-sorts wandering around the ARC command line. (feels like there >might be 30 settings I'm missing, but they're buried under 10 layers of >command structure). Probably not. Oh well. No, but 3Com is attempting to develop a translation utility that will get the configuration settings from the NETServer and spit out something that is supposed to come close to setting up the ARC the same way. Of course, the ARC has alot more functions and setting and stuff. Basically, read the manual for the arc and rewrite whatever you previously used to configure the netserver(s). I put my base config out on the web, FWIW. (http://enterprise.interpath.net/~jfbeam/USR/hiperARC-setup) --Ricky

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: David Bolen <db3l@ans.net>
Date: 1998-10-20 23:14:12

Ricky Beam <jfbeam@Interpath.net> writes: > That adds a new meaning to "cluster"... 16 "PC"s in one USR chassis? If > anyone has an Edgeserver Pro, put linux on a floppy and see if it boots. > That's the first step :-) Well, 5 is the limit per chassis - the E/Pro is a 3 slot component. The older EdgeServer was 2 slot. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-21 09:25:23

On Tue, 20 Oct 1998, Allen Marsalis wrote: > >But it's kind of a non-starter unless you first solve the problem of > >how to download your proposed kernel to the flash/hardware to try to > >run it :-) > > Is the pcsdl software on the netserver/harc side contained in or part > of the flash? or does it reside in ROM somewhere?.. If it is part of > the flash itself, then one does not necessarily have to adopt that > exact same protocol do they? PCSDL will not send .DMF files which is what the HARC uses. I still want to find out from 3Com how PCSDL works so I can have a utility which works on a Linux box to do the same thing... Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) HiPer ARC Security Breach?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-21 09:48:44

On Wed, 21 Oct 1998, K Mitchell wrote: > The following showed up in my Event Log this morning: > 10/21/1998 6:56:58=09204.171.31.2=0943=09113=09[RADSERV] Failed login: = =D7=FB > Unknown Domain: =09p=EC"=EB=E7__+=88t=3Dm7_ =8B=86=84=D9=B5__1=C8Q=9A_l= =9A=C6P_x > 10/21/1998 6:57:50=09204.171.31.2=095=09114=09[RADSERV] Security Breach f= rom > 204.171.31.2 > 10/21/1998 6:58:11=09204.171.31.2=095=09114=09[RADSERV] Security Breach f= rom > 204.171.31.2 >=20 > 204.171.31.2 is my ARC IP, yet nothing showed up on the ARC console port, > which was open at the time. This basically tells that the secret is not matching. Security Breach=20 means secret mismatch. Also on the HiPer you may want to see how ppp is set. Set ppp authe to=20 pap and try this again. krish >=20 > Any ideas? >=20 > Thanks, > Kirk >=20 >=20 > Kirk Mitchell-General Manager sysadmin@keyconn.net > Keystone Connect http://www.keyconn.net > Altoona, PA 814-941-5000 We Unlock the World >=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

Subject: Re: (usr-tc) per user filters on HiPerARC
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-21 09:55:13

On Wed, 21 Oct 1998, Mark van Wouw wrote: > INFORMATION FOR USER: <userid> > Status: INACTIVE Is your RADIUS server overriding the user info since the user is inactive? Have you tried setting up the filter in RADIUS? Kevin Benton SOTA Technologies E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) Radius auth problems with ARC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-21 09:57:02

On Tue, 20 Oct 1998, Peter D. Mayer wrote: > Ok, so I got my first HiPer box last week and I'm just now configuring it. > Everything seems setup properly so I tried to dial in. I get a nice > 48000/V.90 connect and hit the login prompt. Typed my username and password > and was denied. > The first thing that you need to make sure is if the secrets are correct. Change the secret and try. You can do a _auth username password to verify if the user gets authenticated from the hiper arc console. > So to the syslogs I go. Quite simply "Unable to authenticate user". Then I > looked at my Radius error logs and found odd usernames and passwords that > look almost like mine, but not quite. Radius secret problem right? Maybe > not. > It may not entierly be secret problem - It could be a secret problem. What you need to do is find out if you are using chap or pap. Typically if the user is being authenticated using the system password then chap will not work. so change your ppp set ppp auTHENTICATION_PREFERENCE pap and try it again. Also on the arc you have radius monitor to see what you send and receive mon radius is the command. krish > I switched my secret on the ARC and the radius server told me I had the > wrong one. Then I reset it on both sides and restarted the radius server > and the secrets don't match error dropped out. I've set up this box just > like my other 8 (NETServers) in the radius server, and used the same secret > for all of them. I've tried darn near every authentication setting I can > find, with the same results. Suffice it to say that A) the server is > allowed to send packets to my radius server, and B) I've triple checked that > the secret is the same. I even broke down and tried the HARM (amazingly > like the old NETServer manager isn't it?) to configure it, same results. > > Anybody else have these kind of problems on initial config of the ARC? What > might I be missing? I've even deleted the whole config and started from > scratch. > > Any input is greatly appreciated. > > BTW: is there a "Migration Guide" of sorts to help us reasonably advanced > NETServer users quickly learn our way around the Hiper equipment? I feel > very out-of-sorts wandering around the ARC command line. (feels like there > might be 30 settings I'm missing, but they're buried under 10 layers of > command structure). Probably not. Oh well. > > Thanks for any suggestions, > 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. >

Subject: (usr-tc) HiPer ARC Security Breach?
From: K Mitchell <mitch@keyconn.net>
Date: 1998-10-21 10:11:28

The following showed up in my Event Log this morning: 10/21/1998 6:56:58 204.171.31.2 43 113 [RADSERV] Failed login: =D7=FB Unknown Domain: p=EC"=EB=E7__+=88t=3Dm7_ =8B=86=84=D9=B5__1=C8Q=9A_l=9A=C6P= _x 10/21/1998 6:57:50 204.171.31.2 5 114 [RADSERV] Security Breach from 204.171.31.2 10/21/1998 6:58:11 204.171.31.2 5 114 [RADSERV] Security Breach from 204.171.31.2 204.171.31.2 is my ARC IP, yet nothing showed up on the ARC console port, which was open at the time. 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

Subject: Re: (usr-tc) Disabling pause prompt in netserver
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-21 12:05:46

On Wed, 21 Oct 1998, Adam Snodgrass wrote: > Hello, > > Quick question...is there any undocumented command in the Netserver card for > the Total Control chassis that will disable the "Press Return For More" > prompt, or perhaps set the number of rows to some large number, and > essentially accomplish the same feat? For the purposes of a short perl > script I'm writing, this feature serves no purpose. Thanks in advance for > any assistance. (: NO. krish > > Regards, > Adam Snodgrass > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-21 12:33:03

At 09:25 AM 10/21/98 -0400, Kevin Benton wrote: >On Tue, 20 Oct 1998, Allen Marsalis wrote: > >> >But it's kind of a non-starter unless you first solve the problem of >> >how to download your proposed kernel to the flash/hardware to try to >> >run it :-) >> >> Is the pcsdl software on the netserver/harc side contained in or part >> of the flash? or does it reside in ROM somewhere?.. If it is part of >> the flash itself, then one does not necessarily have to adopt that >> exact same protocol do they? > >PCSDL will not send .DMF files which is what the HARC uses. I still want >to find out from 3Com how PCSDL works so I can have a utility which works >on a Linux box to do the same thing... I would hope that pcsdl uses xmodem or some known error correcting xfer protocol. To be honest, i've never heard of pcsdl before this list! Is it a USR thing or actually a standard? And what advantage does it have over xmodem besides preventing you from uploading the wrong (right?) file.. Allen > >Kevin > >E-Mail: s1kevin@tims.net >Web: http://users.sota-oh.com/~s1kevin/ >Unsolicited advertisements processing fee: $50 subject to change without notice > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > >

Subject: (usr-tc) ADSL
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-21 12:41:34

This is a multi-part message in MIME format. ------=_NextPart_000_0015_01BDFCF0.233D1C40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does anyone know what the pin out is for the phone line that plugs into = the AxCell card? ------=_NextPart_000_0015_01BDFCF0.233D1C40 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 5.00.0518.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Does anyone know what the pin out is = for the=20 phone line that plugs into the AxCell card?</FONT></DIV> </BODY></HTML> ------=_NextPart_000_0015_01BDFCF0.233D1C40--

Subject: (usr-tc) Disabling pause prompt in netserver
From: Adam Snodgrass <support@atomic.net>
Date: 1998-10-21 12:51:26

Hello, Quick question...is there any undocumented command in the Netserver card for the Total Control chassis that will disable the "Press Return For More" prompt, or perhaps set the number of rows to some large number, and essentially accomplish the same feat? For the purposes of a short perl script I'm writing, this feature serves no purpose. Thanks in advance for any assistance. (: Regards, Adam Snodgrass

Subject: Re: (usr-tc) Dumb question: PRIs and analog calls
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-21 13:06:54

He's talking about TCS 2.5.1 -----Original Message----- > >Mike, > >Your e-mails a little confusing. When you say ver 2.5.1 your talking about >your Dual T1/PRI card. When you mention 3.8.1 your talking about your >Netserver card. Are you trying to upgrade your TC Hub to TCS 3.3 ( System >release 3.3) ? > > > > >Vito > > > > >"Mike Hamrich" <mhamrich@drfast.net> on 10/01/98 06:33:09 PM > >Please respond to usr-tc@lists.xmission.com > >To: usr-tc@lists.xmission.com >cc: (Vito Maselli/MW/US/3Com) >Subject: Re: (usr-tc) Dumb question: PRIs and analog calls > > > > >How do you install the V.90 3.8.1 release. > >Is there any magic order of cards that should be followed. > >Also is it OK to go from 2.5.1 to 3.8.1 my predecessor did not keep the >chassis to current :) > >Dave Winston >-----Original Message----- >From: Mike Andrews <mandrews@termfrost.org> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Thursday, October 01, 1998 11:37 AM >Subject: Re: (usr-tc) Dumb question: PRIs and analog calls > > >>On Wed, 30 Sep 1998, Mark R. Lindsey wrote: >> >>> Thanks for the help. >>> >>> Would I be right to guess that v.90 and X2 work on such lines, too. >> >>Yup. In theory it should work *better* with PRI than with CT1, because of >>the extra 8K of bandwidth per channel. (23 channels of 64K instead of 24 >>channels of 56K (b8zs) or 48K (ami)). We've never actually tried using >>CT1 here so I can't back that up with personal experience, but I can say >>that we have people getting 53333 connects with v.90 on our PRI's... >> >> >>[munch] >>> : >Thus spake Mark R. Lindsey >>> : >>Can a cht1 card, and the quad modems it talks to, or an HDM, be >configured >>> : >>to terminate a PRI that takes calls both from analog modems and ISDN >>> : >>users? >>> : > >>> : >>Excuse my ignorance, please; I've never worked with ISDN. I've been >under >>> : >>the impression that PRI == ISDN calls only, but our BellSouth >salespeople >>> : >>told us that they can send analog calls down the B channels. >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 1998-10-21 13:34:57

On Tue, 20 Oct 1998, David Bolen wrote: > Given the 2 100bT ports on the EdgeServer/PRO, 2 2GB disks, 2 > processors, one could imagine this to be a pretty useful (albeit > pricey) ISP machine - think 5 of them rack mounted in 8.75" of space. > While BSD/OS certainly works, I wonder if a case could be made for > releasing that info if thinking that the free Unixes would increase > popularity? I'd stand in line for 'em if they ran linux.

Subject: Re: (usr-tc) Hint Assigned on Netserver?
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-21 13:35:07

Makes no difference that I know of -----Original Message----- >Can someone refresh my brain about what Hint Assigned does? Should it be on >or off? > >Thanks, >Wayne Barber >Coastal Telco Services > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) per user filters on HiPerARC
From: Mark van Wouw <vanwouw@gol.com>
Date: 1998-10-21 13:59:25

Hi, I'm trying to setup a user filter (not interface) for a local (not radius) network user on a HiPerARC running version 4.1.11. I've been successful in attaching filters to the interface but not for a specific user. When I "show user" the filters are listed but they appear to be ignored when I dial in to test. This is what I tried: I've set up two filters test.in and test.out on the HARC. I added them as filters and they verified without any problems. I set filter_access for the interface to "on" (which, according to the documentation, enables user filters). I assigned the filters to the user. The filter I am using for the incoming filter is a simplified filter I am using for testing. I would expect this filter would block all packets, but it appears that the user retains full access. Has anybody successfully implemented a user filter? My filters and user: HiPer>> sh filter test.in RULES FOR FILTER /./test.in SHOW PROTOCOLS: ALL #filter IP: 005 REJECT src-addr=<IP ADDR>; 010 DENY; HiPer>> sh filter test.out RULES FOR FILTER /./test.out SHOW PROTOCOLS: ALL #filter IP: 005 REJECT src-addr=<IP ADDR>; 010 DENY; HiPer>> sh user <userid> INFORMATION FOR USER: <userid> Status: INACTIVE Type: NETWORK Expiration: NONE Message: (D) Phone Number: (D) Alternate Phone Number: (D) Input Filter: test.in Output Filter: test.out Modem Group: all (D) Session Timeout in seconds: 0 (D) Idle Timeout in seconds: 0 (D) Tap Status: DISABLED Tap Format: ASCII Tap Output: SYSLOG Tap Facility: INVALID Tap Loglevel: CRITICAL Tap Address: 0.0.0.0 (D) Chat Script Name: PARAMETERS FOR NETWORK USERS: Network Service PPP Header Compression: TCPIP (D) Spoofing: DISABLED (D) MTU: 1514 (D) IP Usage: ENABLED (D) Address Selection: ASSIGN (D) Remote IP Address: 0.0.0.0/H (D) IP Routing: NONE (D) IP RIP Routing Protocol: RIPV1 (D) IP RIP Routing Policies: IP RIP Authentication Key: Default Route Option: DISABLED (D) IGMP Query Interval: 0 seconds IGMP Max Response: 0 seconds IGMP Version: 0 IGMP Robustness: 0 IGMP Routing: INVALID Multicast Forwarding: INVALID Multicast Proxy: INVALID (D) IPX Usage: ENABLED (D) IPX Address: 00000000 (D) IPX Routing: SEND (D) IPX WAN Usage: DISABLED (D) IPX RIP Update: 0 seconds IPX RIP Age Multiplier: 0 IPX SAP Update: 0 seconds IPX SAP Age Multiplier: 0

Subject: RE: (usr-tc) Hint Assigned on Netserver?
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-21 14:02:49

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian K McIntire |Sent: Wednesday, October 21, 1998 1:35 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Hint Assigned on Netserver? | | |Makes no difference that I know of |-----Original Message----- |From: Wayne Barber <barberw@tidewater.net> |To: usr-tc <usr-tc@lists.xmission.com> |Date: Wednesday, October 21, 1998 1:14 PM |Subject: (usr-tc) Hint Assigned on Netserver? | | |>Can someone refresh my brain about what Hint Assigned does? Should it be on |>or off? |> Hint assigned causes the NAS to send the IP address it "will" assign in the RADIUS access request packet. This allows the RADIUS server to build dynamic filters and do "other" things based on the assigned address and place them into the access accept packet. If your RADIUS server doesn't use this then turn it off. -M

Subject: (usr-tc) Hint Assigned on Netserver?
From: Wayne Barber <barberw@tidewater.net>
Date: 1998-10-21 14:13:47

Can someone refresh my brain about what Hint Assigned does? Should it be on or off? Thanks, Wayne Barber Coastal Telco Services

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-10-21 14:50:22

On Wed, 21 Oct 1998, Kevin Benton wrote: > On Tue, 20 Oct 1998, Allen Marsalis wrote: > > > >But it's kind of a non-starter unless you first solve the problem of > > >how to download your proposed kernel to the flash/hardware to try to > > >run it :-) > > > > Is the pcsdl software on the netserver/harc side contained in or part > > of the flash? or does it reside in ROM somewhere?.. If it is part of > > the flash itself, then one does not necessarily have to adopt that > > exact same protocol do they? > > PCSDL will not send .DMF files which is what the HARC uses. I still want > to find out from 3Com how PCSDL works so I can have a utility which works > on a Linux box to do the same thing... I havent tried it, but it should be possible to run pcsdl.exe with the linux dos emulator.. really all it does is access the serial port. We can capture all the data sent/received through the serial port, perhaps by using a fifo and an application to shuffle data to/from it and the real /dev/ttySx serial port, or by using another computer all together with two serial ports to do the forwarding and capturing. Whats the most difficult thing about figuring out pcsdl, the CRC check? - lv

Subject: Re: (usr-tc) Radius auth problems with ARC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-21 15:02:01

Keep in mind _auth is only going to help you verifiy username and password and NAS secret. If your dial up fails it is a failure in user setup or negotiation of protocols. -----Original Message----- >Krish, > >Thanks for the response. > >An "_auth <username> <password>" returns "CLI - User: <username> is >Authenticated", but a login from the "login:" prompt if I dial with a >terminal emulator still gets rejected: > >Welcome to 3Com Total Control HiPer ARC (TM) >Networks That Go The Distance (TM) > >login: <username> >Password: <password> > >Login Incorrect > >I'm not even trying to use PAP or CHAP at this point, although I had already >configured the authentication_preference to PAP, and authentication accept >to ANY (one of the first things I did in configuring the arc). > >Here's my current PPP and authentication settings (the 'x' numbers are of >course real and correct numbers in my config) : > >PPP AUTHENTICATION >DIAL_IN Users Authenticate: ANY >PPP Authentication Preference: PAP >System Transmit Authentication Name: arc1 >PPP offloading: ENABLED >CCP will be attempted for call type(s): DIGITAL > UNCOMPRESSED_ANALOG >Primary NBNS Server address: 0.0.0.0 >Secondary NBNS Server address: 0.0.0.0 >DNS configuration Usage: PPP-DNS >Primary PPP DNS Server address: x.x.x.x >Secondary PPP DNS Server address: x.x.x.x >PPP session start message: PPP session from %server_ip to >%client_ip beginning.... > >RADIUS AUTHENTICATION SETTINGS >Local Authentication is: DISABLED >Remote Authentication is: ENABLED >Hint Assigned is: DISABLED >Primary Server is: x.x.x.x >Primary Destination Port is: x >Secondary Server is: x.x.x.x >Secondary Destination Port is: x >Tertiary Server is: 0.0.0.0 >Tertiary Destination Port is: x >Source Port is: x >Retransmission Timeout: 3 seconds >Max Retranmissions: 10 >Vendor Specific Attribute: DISABLED >Active Authentication Server: x.x.x.x > >Is there a higher level of debug for RADIUS? Could this possibly be a >problem with anything else besides RADIUS? (i.e. span line config, modem >settings, etc.?) > >Thanks for your help on this. >Peter D. Mayer >NetWalk System Administrator >dmayer@netwalk.com > >-----Original Message----- >From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> >To: Peter D. Mayer <dmayer@netwalk.com> >Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Wednesday, October 21, 1998 10:52 AM >Subject: Re: (usr-tc) Radius auth problems with ARC > > >On Tue, 20 Oct 1998, Peter D. Mayer wrote: > >> Ok, so I got my first HiPer box last week and I'm just now configuring it. >> Everything seems setup properly so I tried to dial in. I get a nice >> 48000/V.90 connect and hit the login prompt. Typed my username and >password >> and was denied. >> >The first thing that you need to make sure is if the secrets are >correct. Change the secret and try. You can do a _auth username >password to verify if the user gets authenticated from the hiper arc >console. > >> So to the syslogs I go. Quite simply "Unable to authenticate user". Then >I >> looked at my Radius error logs and found odd usernames and passwords that >> look almost like mine, but not quite. Radius secret problem right? Maybe >> not. >> >It may not entierly be secret problem - It could be a secret problem. >What you need to do is find out if you are using chap or pap. Typically >if the user is being authenticated using the system password then chap >will not work. so change your ppp > >set ppp auTHENTICATION_PREFERENCE pap > >and try it again. > > >Also on the arc you have radius monitor to see what you send and receive > >mon radius is the command. > >krish >> I switched my secret on the ARC and the radius server told me I had the >> wrong one. Then I reset it on both sides and restarted the radius server >> and the secrets don't match error dropped out. I've set up this box just >> like my other 8 (NETServers) in the radius server, and used the same >secret >> for all of them. I've tried darn near every authentication setting I can >> find, with the same results. Suffice it to say that A) the server is >> allowed to send packets to my radius server, and B) I've triple checked >that >> the secret is the same. I even broke down and tried the HARM (amazingly >> like the old NETServer manager isn't it?) to configure it, same results. >> >> Anybody else have these kind of problems on initial config of the ARC? >What >> might I be missing? I've even deleted the whole config and started from >> scratch. >> >> Any input is greatly appreciated. >> >> BTW: is there a "Migration Guide" of sorts to help us reasonably advanced >> NETServer users quickly learn our way around the Hiper equipment? I feel >> very out-of-sorts wandering around the ARC command line. (feels like >there >> might be 30 settings I'm missing, but they're buried under 10 layers of >> command structure). Probably not. Oh well. >> >> Thanks for any suggestions, >> 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. >> > >- >To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >with "unsubscribe usr-tc" in the body of the message. >For information on digests or retrieving files and old messages send >"help" to the same address. Do not use quotes in your message. > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-21 15:04:05

Laszlo Vecsey was heard to say: >I havent tried it, but it should be possible to run pcsdl.exe with the >linux dos emulator.. really all it does is access the serial port. No you can't... pcsdl needs hardware level access to the UART. --Ricky

Subject: Re: (usr-tc) ADSL
From: Charles Hill <chill@ionet.net>
Date: 1998-10-21 15:05:35

The middle two pins are the ADSL loop and polarity doesn't matter. -CH On Wed, 21 Oct 1998, Brian K McIntire wrote: > Does anyone know what the pin out is for the phone line that plugs into > the AxCell card? >

Subject: Re: (usr-tc) ADSL
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-21 15:12:00

Thanks again guys, 3COM had the foresight to either give all their ADSL people the week off with vacation or training. No back up plan. Oh well -----Original Message----- > >The middle two pins are the ADSL loop and polarity doesn't matter. -CH > >On Wed, 21 Oct 1998, Brian K McIntire wrote: > >> Does anyone know what the pin out is for the phone line that plugs into >> the AxCell card? >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Radius auth problems with ARC
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-21 15:21:17

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Peter D. Mayer |Sent: Wednesday, October 21, 1998 2:45 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Radius auth problems with ARC | |An "_auth <username> <password>" returns "CLI - User: <username> is |Authenticated", but a login from the "login:" prompt if I dial with a |terminal emulator still gets rejected: | |Welcome to 3Com Total Control HiPer ARC (TM) |Networks That Go The Distance (TM) | |login: <username> |Password: <password> | |Login Incorrect | What does the entry in the RADIUS user file look like? What attributes and values?? Also what does your RADIUS log show? If the log shows that the login was OK but the HARC shows login incorrect it could be because of something you are sending in the ACCEPT packet. -M

Subject: Re: (usr-tc) Radius auth problems with ARC
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-21 15:45:00

Krish, Thanks for the response. An "_auth <username> <password>" returns "CLI - User: <username> is Authenticated", but a login from the "login:" prompt if I dial with a terminal emulator still gets rejected: Welcome to 3Com Total Control HiPer ARC (TM) Networks That Go The Distance (TM) login: <username> Password: <password> Login Incorrect I'm not even trying to use PAP or CHAP at this point, although I had already configured the authentication_preference to PAP, and authentication accept to ANY (one of the first things I did in configuring the arc). Here's my current PPP and authentication settings (the 'x' numbers are of course real and correct numbers in my config) : PPP AUTHENTICATION DIAL_IN Users Authenticate: ANY PPP Authentication Preference: PAP System Transmit Authentication Name: arc1 PPP offloading: ENABLED CCP will be attempted for call type(s): DIGITAL UNCOMPRESSED_ANALOG Primary NBNS Server address: 0.0.0.0 Secondary NBNS Server address: 0.0.0.0 DNS configuration Usage: PPP-DNS Primary PPP DNS Server address: x.x.x.x Secondary PPP DNS Server address: x.x.x.x PPP session start message: PPP session from %server_ip to %client_ip beginning.... RADIUS AUTHENTICATION SETTINGS Local Authentication is: DISABLED Remote Authentication is: ENABLED Hint Assigned is: DISABLED Primary Server is: x.x.x.x Primary Destination Port is: x Secondary Server is: x.x.x.x Secondary Destination Port is: x Tertiary Server is: 0.0.0.0 Tertiary Destination Port is: x Source Port is: x Retransmission Timeout: 3 seconds Max Retranmissions: 10 Vendor Specific Attribute: DISABLED Active Authentication Server: x.x.x.x Is there a higher level of debug for RADIUS? Could this possibly be a problem with anything else besides RADIUS? (i.e. span line config, modem settings, etc.?) Thanks for your help on this. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> On Tue, 20 Oct 1998, Peter D. Mayer wrote: > Ok, so I got my first HiPer box last week and I'm just now configuring it. > Everything seems setup properly so I tried to dial in. I get a nice > 48000/V.90 connect and hit the login prompt. Typed my username and password > and was denied. > The first thing that you need to make sure is if the secrets are correct. Change the secret and try. You can do a _auth username password to verify if the user gets authenticated from the hiper arc console. > So to the syslogs I go. Quite simply "Unable to authenticate user". Then I > looked at my Radius error logs and found odd usernames and passwords that > look almost like mine, but not quite. Radius secret problem right? Maybe > not. > It may not entierly be secret problem - It could be a secret problem. What you need to do is find out if you are using chap or pap. Typically if the user is being authenticated using the system password then chap will not work. so change your ppp set ppp auTHENTICATION_PREFERENCE pap and try it again. Also on the arc you have radius monitor to see what you send and receive mon radius is the command. krish > I switched my secret on the ARC and the radius server told me I had the > wrong one. Then I reset it on both sides and restarted the radius server > and the secrets don't match error dropped out. I've set up this box just > like my other 8 (NETServers) in the radius server, and used the same secret > for all of them. I've tried darn near every authentication setting I can > find, with the same results. Suffice it to say that A) the server is > allowed to send packets to my radius server, and B) I've triple checked that > the secret is the same. I even broke down and tried the HARM (amazingly > like the old NETServer manager isn't it?) to configure it, same results. > > Anybody else have these kind of problems on initial config of the ARC? What > might I be missing? I've even deleted the whole config and started from > scratch. > > Any input is greatly appreciated. > > BTW: is there a "Migration Guide" of sorts to help us reasonably advanced > NETServer users quickly learn our way around the Hiper equipment? I feel > very out-of-sorts wandering around the ARC command line. (feels like there > might be 30 settings I'm missing, but they're buried under 10 layers of > command structure). Probably not. Oh well. > > Thanks for any suggestions, > 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. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: David Bolen <db3l@ans.net>
Date: 1998-10-21 15:54:23

Allen Marsalis <am@shreve.net> writes: > Is the pcsdl software on the netserver/harc side contained in or part > of the flash? or does it reside in ROM somewhere?.. If it is part of > the flash itself, then one does not necessarily have to adopt that > exact same protocol do they? Since it's the only way to transmit an arbitrary code image to the card (either via the NMC or console port), in normal circumstances, it's pretty much required at least at first. Of course, once you had your own code image on the card, it could then do anything it wanted, so I suppose a logical method would be to build a bootstrap that would then load a Linux image more normally. But dealing with SDL for the bootstrap or for the kernel carries the same issues. PCSDL is a DOS based utility that implements an SDL (software download) protocol USR uses for a variety of products, although the trend is to move to a more standard protocol like xmodem or zmodem. It's supported by all non-Hiper cards in the TC chassis and was also, I believe, originally used for the Courier upgrades. The utility used to be shipped in the archive with every new software release for any card. It's not necessary if you use the NMC for downloads, but it's always good to have as a backup path in a pinch (or if your NMC goes out and needs a download itself). It's not really my call to discuss too many details about the protocol itself/SDL format, but suffice it to say that it is a separate beast (e.g., definitely not something like x/zmodem - it might even predate them, I'm not sure). It clearly has legacy and historical roots and was actually pretty good for its purpose. For the image files used with the TC, the SDL file contains control instructions describing how to apply the actual image, which is in the NAC file. When you download through the NMC, the NMC contains code to interpret the SDL instructions and apply them to the NAC that gets transmitted. When you download with the PCSDL utility, the utility serves the same purpose as the NMC in interpreting the instructions in the SDL file and applying them to the NAC file. That's also why you drop off the SDL file when downloading to the NMC itself over the ethernet - the operational code in the NMC implicitly knows how to handle itself. Whereas, doing the same download to a dead NMC with the PCSDL utility needs the SDL file, since PCSDL is generic and doesn't know anything more about an NMC card than about a modem card. In terms of functionality, the NAC itself has the smarts to receive the code image and install it into the flash - either over a management bus connection to the NMC, or via the serial console port. This is either performed by the operational code currently on the card, or in a worst case by a modification to the on-card BIOS that is constantly watching the console port. That's why when, for example, an NMC blows up and just sits there slow blinking the green RN/FL LED, that you can still do a download to it with the PCSDL utility - even though there is no operational code image on the card, the BIOS has enough intelligence to accept the download request and image. It's also why sometimes if you are having trouble, rebooting the card while trying the download works better - instead of depending on the operational code to detect the download sequence in the midst of other command parsing, when the card is first booting, only the BIOS is looking at the serial console port and sometimes that makes for easier detection of the download request (I used to find this with the Dual-T1 cards in particular). On the newer Hiper cards, this BIOS functionality is taken over by the separate "boot" code (which is not really intended to ever be reflashed in the field, or a failure there could really result in a "brick") which contains the zmodem functionality and the initial SDL-2 download prompt. > If the first pcsdl session uploaded "your" code and save it and rebooted, > then the next pcsdl session doesn't have to be "pcsdl" at all, but anything > you choose to code into it right? Sure. The rub is constructing the initial image/control file suitable for use as an SDL file for that initial download. > The sign of a situation where the actual serial drivers are embedded in > the flash, is when a device can become "unflashable" due to an interruption > in a previous flash or something. If it's in ROM, the device should always > be able to receive a new flash.. Right - as described above. > Anyone ever crash/corrupt a netservers > or hiperarcs flash memory so bad, the card was kaput and wouldn't even > accept a download? It should be impossible - well, almost in the ARC case unless somehow you blow both the normal image flash as well as the low level boot image. > Related question. I heard early on that the hiperarc booted with a "kernel" > of sorts much like unix and was curious as to how unix like (internally) > is the hiperarc? (i.e. is it based on any familar kernels we might have > heard of? or are they just calling their bootstrap a kernel to be cool.) "Kernel" is hardly a term restricted to use by Unix, but rather a pretty generic software concept. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: David Bolen <db3l@ans.net>
Date: 1998-10-21 16:12:29

Allen Marsalis <am@shreve.net> writes: > I would hope that pcsdl uses xmodem or some known error correcting xfer > protocol. I'm not sure why it would have to be a "known" error correcting protocol - but it's definitely error checked. > To be honest, i've never heard of pcsdl before this list! Is > it a USR thing or actually a standard? USR thing. Their standard serial based download utility which used to be shipped in every ZIP file that contained a new code image. > And what advantage does it have > over xmodem besides preventing you from uploading the wrong (right?) file.. Hard to necessarily bucket it as an advantage or disadvantage, but the SDL stuff is more of a control protocol than xmodem - which is just a transfer protocol. In other words, with x/zmodem you transfer a file, but it's just a bulk transfer and the recipient better have all the knowledge necessary as to what to do with it. In a download process, there are a variety of activites that must take place. For example, erasing the old flash, downloading image blocks, burning those blocks into flash, etc.. Some of the older cards have small transfer buffers, and must burn their flash frequently rather than first downloading the entire image and burning it in one step. The SDL format contains instructions for sequencing a download, which is why there are different files for different types of cards. It's a two way communication at times (for example CRC checking) with the card. Now, you can either build all these instructions into an image and just dump the whole thing to a card, expecting the card to run through all of the stages, or you can handle the processing off-card. The latter is more of what PCSDL does (it's the download interpreter/controller, and the card just performs simple operations). This is easier on the card, and thus more efficient and suitable back when this was first being done to help save complexity on the cards. The bulk dump is the SDL-2 approach (and the new DMF format), which is more feasible with todays hardware/software setups. For anyone who has run PCSDL, you can sometimes see these stages when it may indicate multiple times (at various percentages through the download) that it is writing the flash, or near the end when it validates the CRC (it's getting the card to compute the CRC). -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) Radius auth problems with ARC
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-21 16:30:06

I understand that, but what I'm talking here is simply dialing in with a terminal emulator, at the login: prompt typing my username, and at the Password: prompt typing my password. My radius server is logging that attempt as a mildly garbled username and password, (meaning it doesn't even auth, much less try to negotiate protocols) but the "_auth <username> <password>" seems to authenticate fine. If I type the wrong password there my RADIUS server logs (in clear legible plain ungarbled text) the incorrect attempt. The only thing I can think of at this point is that some span line or modem setting is wrong, and that the arc is actually getting (straight from my dial up connection) the garbled text that's appearing in the radius logs, and then sending this off verbatim to the RADIUS server. Sound possible? If so what could I do to fix it? Thanks again, Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- >Keep in mind _auth is only going to help you verifiy username and password >and NAS secret. If your dial up fails it is a failure in user setup or >negotiation of protocols. > >-----Original Message----- >From: Peter D. Mayer <dmayer@netwalk.com> >To: <usr-tc@lists.xmission.com> >Date: Wednesday, October 21, 1998 2:45 PM >Subject: Re: (usr-tc) Radius auth problems with ARC >> >> >>Krish, >> >>Thanks for the response. >> >>An "_auth <username> <password>" returns "CLI - User: <username> is >>Authenticated", but a login from the "login:" prompt if I dial with a >>terminal emulator still gets rejected: >> >>Welcome to 3Com Total Control HiPer ARC (TM) >>Networks That Go The Distance (TM) >> >>login: <username> >>Password: <password> >> >>Login Incorrect

Subject: Re: (usr-tc) Radius auth problems with ARC
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-21 16:36:06

Mike, Check out my reply to Brian McIntire's earlier message with more info on my radius logs and such. It appears at this point that it's some corruption with my connection itself, as auths from the CLI with "_auth <username> <password>" authenticate fine, and incorrect username/password attempts log in ungarbled text in the radius log. If you have any ideas about what else might cause this I'd really appreciate it. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Peter D. Mayer |Sent: Wednesday, October 21, 1998 2:45 PM |To: usr-tc@lists.xmission.com |Subject: Re: (usr-tc) Radius auth problems with ARC | |An "_auth <username> <password>" returns "CLI - User: <username> is |Authenticated", but a login from the "login:" prompt if I dial with a |terminal emulator still gets rejected: | |Welcome to 3Com Total Control HiPer ARC (TM) |Networks That Go The Distance (TM) | |login: <username> |Password: <password> | |Login Incorrect | What does the entry in the RADIUS user file look like? What attributes and values?? Also what does your RADIUS log show? If the log shows that the login was OK but the HARC shows login incorrect it could be because of something you are sending in the ACCEPT packet. -M - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Laszlo Vecsey <master@internexus.net>
Date: 1998-10-21 18:27:39

On Wed, 21 Oct 1998, Ricky Beam wrote: > > Laszlo Vecsey was heard to say: > >I havent tried it, but it should be possible to run pcsdl.exe with the > >linux dos emulator.. really all it does is access the serial port. > > No you can't... pcsdl needs hardware level access to the UART. Here's an excerpt from the docs: -- This code aims to emulate a 16550A as accurately as possible, using just reasonably POSIX.2 compliant code. In some cases, this code does a better job than OS/2 serial emulation (in non-direct mode) done by its COM.SYS driver! There may be about 100 kilobytes of source code, but nearly 50% of this size are comments! This 16550A emulator never even touches the real serial ports, it merely traps port writes, and does the I/O via file functions on a device in /dev. Interrupts are also simulated as necessary. -- Programs like QModem are listed in the compatibility list, and even better, according to the above it should be straight forward to log a pcsdl session to disk. The source is at ftp.suse.com /pub/dosemu - lv

Subject: Re: (usr-tc) Radius auth problems with ARC
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-21 19:00:23

Boy do I feel like an idiot. The INITIAL problem actually WAS that the secrets were out of sync, but I actually had that corrected before I even posted to the list. After I started using my terminal emulator to test, (which I just found out was configured E-7-1 to interface with an old piece of equipment :( ) nothing would work. Imagine that. I really need to slap myself for not eliminating all possible points of failure before even posting to this list. Well, at least I found out about "_auth" (which I can't find documented anywhere) which I'm sure will come in handy in the future. I really appreciate all the people who responded, and I'm really sorry it turned out to be something so stupid. Thanks especially to Mike for the unassuming comment that pointed me in the right direction. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- > > >MY specialty is the HARC/Netserver and routing issues, but I would default the >DSPs (set the default configs) and see if that helps.. Also have you tried making >a PPP call or using a different terminal application? > >-M > >

Subject: (usr-tc) Linux, booting on netserver
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-21 20:27:46

Below is all referencing the Netserver card. Doesn't the flash come out? I seem to remember that you can take the flash out. It looks like a 72 pin simm with the word "FLASH" on it... I think... It is a standard form factor. Isn't it? With a standard flash you can program it with an external flash programmer. Isn't booting the code the least of the problem? 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, a full T1, 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 1998 Richard Stuplich, see http://dw.net/cr/

Subject: Re: (usr-tc) Linux, booting on netserver
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-21 21:42:01

: Below is all referencing the Netserver card. : : Doesn't the flash come out? Yeah, and that's one of the reasons I imagine that we could add flash. Mark's Postulate: The worst part of the TC system is the Netserver OS. I'll let y'all know when I prove that. Anyway, I'd bet cookies to doughnuts that you can add flash modules, and have more secondary storage. (Is anyone familiar with the read/write access speeds of flash storage? It doesn't matter much, but I'm curious.) : With a standard flash you can program it with an external flash programmer. : : Isn't booting the code the least of the problem? Well, the part that handles the bootstrap process probably expects a certain data format to be stored in a certain location in the flash. To find that precise information, we could either (a) attempt to reverse-engineer the various chips on the netserver, or (b) work with 3Com to get the information. I'm voting for (b). --- If you are interested in Linux on the Netserver, please subscribe to the list lon@datasys.net by saying `subscribe' in a message to to lon-request@datasys.net. --- Mark R. Lindsey, mark@datasys.net Internet Engineering, DSS Online LLC Voice: 912.241.0607x200, Fax: 912.241.0190 (US)

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-21 22:17:49

Thanks for the explaination of PCSDL.. I've always wondered about it but I was too embarrassed to ask fearing it was some major protocol that only the clueless would have never heard about.. :) I don't remember seeing it in any terminal programs and I just didn't know.. I think abandoning it with the hiper products in favor of xmodem or zmodem would have been a good move and made some unix folks happier. I'd rather flash a Netgear RT328 with xmodem over a P50/75 anyday with it's funky upload method.. But at least it doesn't require a special DOS utility. ;) Allen At 03:54 PM 10/21/98 EDT, David Bolen wrote: >Allen Marsalis <am@shreve.net> writes: > >> Is the pcsdl software on the netserver/harc side contained in or part >> of the flash? or does it reside in ROM somewhere?.. If it is part of >> the flash itself, then one does not necessarily have to adopt that >> exact same protocol do they? > >Since it's the only way to transmit an arbitrary code image to the >card (either via the NMC or console port), in normal circumstances, >it's pretty much required at least at first. > >Of course, once you had your own code image on the card, it could then >do anything it wanted, so I suppose a logical method would be to build >a bootstrap that would then load a Linux image more normally. But >dealing with SDL for the bootstrap or for the kernel carries the same >issues. > >PCSDL is a DOS based utility that implements an SDL (software >download) protocol USR uses for a variety of products, although the >trend is to move to a more standard protocol like xmodem or zmodem. >It's supported by all non-Hiper cards in the TC chassis and was also, >I believe, originally used for the Courier upgrades. The utility used >to be shipped in the archive with every new software release for any >card. It's not necessary if you use the NMC for downloads, but it's >always good to have as a backup path in a pinch (or if your NMC goes >out and needs a download itself). > >It's not really my call to discuss too many details about the protocol >itself/SDL format, but suffice it to say that it is a separate beast >(e.g., definitely not something like x/zmodem - it might even predate >them, I'm not sure). It clearly has legacy and historical roots and >was actually pretty good for its purpose. For the image files used >with the TC, the SDL file contains control instructions describing how >to apply the actual image, which is in the NAC file. When you >download through the NMC, the NMC contains code to interpret the SDL >instructions and apply them to the NAC that gets transmitted. When >you download with the PCSDL utility, the utility serves the same >purpose as the NMC in interpreting the instructions in the SDL file >and applying them to the NAC file. That's also why you drop off the >SDL file when downloading to the NMC itself over the ethernet - the >operational code in the NMC implicitly knows how to handle itself. >Whereas, doing the same download to a dead NMC with the PCSDL utility >needs the SDL file, since PCSDL is generic and doesn't know anything >more about an NMC card than about a modem card. > >In terms of functionality, the NAC itself has the smarts to receive >the code image and install it into the flash - either over a >management bus connection to the NMC, or via the serial console port. > >This is either performed by the operational code currently on the >card, or in a worst case by a modification to the on-card BIOS that is >constantly watching the console port. That's why when, for example, >an NMC blows up and just sits there slow blinking the green RN/FL LED, >that you can still do a download to it with the PCSDL utility - even >though there is no operational code image on the card, the BIOS has >enough intelligence to accept the download request and image. It's >also why sometimes if you are having trouble, rebooting the card while >trying the download works better - instead of depending on the >operational code to detect the download sequence in the midst of other >command parsing, when the card is first booting, only the BIOS is >looking at the serial console port and sometimes that makes for easier >detection of the download request (I used to find this with the >Dual-T1 cards in particular). > >On the newer Hiper cards, this BIOS functionality is taken over by the >separate "boot" code (which is not really intended to ever be >reflashed in the field, or a failure there could really result in a >"brick") which contains the zmodem functionality and the initial SDL-2 >download prompt. > >> If the first pcsdl session uploaded "your" code and save it and rebooted, >> then the next pcsdl session doesn't have to be "pcsdl" at all, but anything >> you choose to code into it right? > >Sure. The rub is constructing the initial image/control file suitable >for use as an SDL file for that initial download. > >> The sign of a situation where the actual serial drivers are embedded in >> the flash, is when a device can become "unflashable" due to an interruption >> in a previous flash or something. If it's in ROM, the device should always >> be able to receive a new flash.. > >Right - as described above. > >> Anyone ever crash/corrupt a netservers >> or hiperarcs flash memory so bad, the card was kaput and wouldn't even >> accept a download? > >It should be impossible - well, almost in the ARC case unless somehow >you blow both the normal image flash as well as the low level boot image. > >> Related question. I heard early on that the hiperarc booted with a "kernel" >> of sorts much like unix and was curious as to how unix like (internally) >> is the hiperarc? (i.e. is it based on any familar kernels we might have >> heard of? or are they just calling their bootstrap a kernel to be cool.) > >"Kernel" is hardly a term restricted to use by Unix, but rather a >pretty generic software concept. > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, 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. > >

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-21 22:47:59

At 04:12 PM 10/21/98 EDT, David Bolen wrote: >Allen Marsalis <am@shreve.net> writes: > >> I would hope that pcsdl uses xmodem or some known error correcting xfer >> protocol. > >I'm not sure why it would have to be a "known" error correcting >protocol - but it's definitely error checked. Well of course you are right. It's just that "known" gives me that 'warm fuzzy feeling' for having done it countless times before. Also if it were known, then one of countless com programs could be used per users preference. > >> To be honest, i've never heard of pcsdl before this list! Is >> it a USR thing or actually a standard? > >USR thing. Their standard serial based download utility which used to >be shipped in every ZIP file that contained a new code image. Great. I don't feel bad for never hearing of it. :) I've never owned a Courier BTW.. I figured I'd just pick up it's origins one day on this list.. (without divulging my cluelessness) oh well.. > >> And what advantage does it have >> over xmodem besides preventing you from uploading the wrong (right?) file.. > >Hard to necessarily bucket it as an advantage or disadvantage, but the >SDL stuff is more of a control protocol than xmodem - which is just a >transfer protocol. In other words, with x/zmodem you transfer a file, >but it's just a bulk transfer and the recipient better have all the >knowledge necessary as to what to do with it. Yep it looks like it's putting alot of the "smarts" regarding the process in the client over the recipient. I guess this has alot of advantages in an operation of this type (i.e. wiping out memory, etc.) > >In a download process, there are a variety of activites that must take >place. For example, erasing the old flash, downloading image blocks, >burning those blocks into flash, etc.. Some of the older cards have >small transfer buffers, and must burn their flash frequently rather >than first downloading the entire image and burning it in one step. I can see that these aren't just simple devices like a flashable modem or ISDN adapter.. They really are engineered to do more. I've seen modems that if the flash upgrade operation were interrupted in the right spot, a "brick" was resulting.. no BIOS or anything.. maybe flash devices that use xmodem are noted by their simplicity like small ISDN routers.. But couldn't all these functions be built into an xmodem (recepient) client that would just have to be smarter and deal with the details instead of relying on a second CPU somewhere? I guess this might have been found to be challenging to implement so they opted for a better/easier solution. Also it might make debugging of the flash code itself a little easier. Thinking about the "chicken and the egg" situation make my head swim.. :) > >The SDL format contains instructions for sequencing a download, which >is why there are different files for different types of cards. It's a >two way communication at times (for example CRC checking) with the >card. Well for many years I designed/wrote sequencing software for MIDI applications and I believe USR made the right choice if sequencing is necessary, and I guess it is with a more sophisticated process such as this. With a PC you've got all the timers, interrupts, cpu, and memory you could possibly want or need. > >Now, you can either build all these instructions into an image and >just dump the whole thing to a card, expecting the card to run through >all of the stages, or you can handle the processing off-card. The >latter is more of what PCSDL does (it's the download >interpreter/controller, and the card just performs simple >operations). This is easier on the card, and thus more efficient and >suitable back when this was first being done to help save complexity >on the cards. The bulk dump is the SDL-2 approach (and the new DMF >format), which is more feasible with todays hardware/software setups. gotcha. > >For anyone who has run PCSDL, you can sometimes see these stages when >it may indicate multiple times (at various percentages through the >download) that it is writing the flash, or near the end when it >validates the CRC (it's getting the card to compute the CRC). I think it's pretty nice how they designed things to blow up and yet be PCSDL recoverable. And also how you can flash and reboot later at a more convenient, etc.. The hardware seems well engineered.. Allen > >-- David > >/-----------------------------------------------------------------------\ > \ David Bolen \ Internet: db3l@ans.net / > | ANS Communications, 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. > >

Subject: Re: (usr-tc) Port number assignments on HyperARC
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-22 00:03:50

: How does the hiperARC assign port numbers given to RADIUS accounting? : I can sort of guess the first digit is (slot number -1) but the rest seems : random. From: Ricky Beam <jfbeam@Interpath.net> Alan D. Criado was heard to say: >Since doing so, the chassis now reports all >connections as coming in on NAS-Port = 1. > >It used be the first connection was on NAS-Port = >3845 and the next on 3846 and so on. However, now >it's assign 1 for every connection made. > >Does anyone know why this is and how it can be >correct to show individual port addresses for >each connection? It's a bug. The HARC reports an "Interface-Index" that uniquely ids the port (1000 + 256*<slot> + <channel>). --Ricky

Subject: (usr-tc) Interested in Linux on the Netserver?
From: Mark R. Lindsey <mark@vielle.datasys.net>
Date: 1998-10-22 00:09:10

We, collectively, may be very close to a breakthrough in telecommunications. With good cooperation and a little work, we could be uploading Linux to our Netservers very soon. I see this as a relatively important venture that's good for every Netserver user. And this venture is good for 3Com, too -- it will provide an extended lifetime to those of us who plan to stick with our Netservers, and will make 3Com the first vendor I know of with an open-source high-density telecom system. That, friends, is a radical step forward. We're talking about a fresh start for the TC Netserver. I'd like to get a show of hands, so to speak, for everyone interested in Linux on the Netserver. If you are interested, please send the message `subscribe' to LON-request@datasys.net --- Mark R. Lindsey, mark@datasys.net Internet Engineering, DSS Online LLC Voice: 912.241.0607x200, Fax: 912.241.0190 (US)

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-22 00:32:35

Courier SDL may be related in some way, but it is definitely considerably different than PCSDL. You will not likely garner much useful info from any Courier docs. JP Mike Andrews <mandrews@termfrost.org> on 10/22/98 12:18:40 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) Somewhere in my collection of useless crap, I think I have a (very old) text file that describes how the SDL procedure for Courier modems works. If anyone thinks it would help in deciphering how PCSDL works, holler and I'll see if I can find it... I remember it said the Courier SDL file format was kinda strange, it had checksums sprinkled throughout the file itself, and the whole SDL file was embedded in the USRSDL.EXE program. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound? - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-22 01:06:40

Allen Marsalis was heard to say: >I'd rather flash a Netgear >RT328 with xmodem over a P50/75 anyday with it's funky upload method.. Don't be dissin' Ascend! The P50/75 support (and always has?) xmodem. It also has tftp support! --Ricky

Subject: Re: (usr-tc) Port number assignments on HyperARC
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-22 01:09:51

Brett Murphy was heard to say: >Mark R. Lindsey wrote: >> : How does the hiperARC assign port numbers given to RADIUS accounting? >> : I can sort of guess the first digit is (slot number -1) but the rest seems >> : random. >> <snip> >> It's a bug. The HARC reports an "Interface-Index" >> that uniquely ids the port (1000 + 256*<slot> + <channel>). > >Thanks for that, not as random as it looked :) FWIW, that's the NMC (SNMP) "identity number" for that modem... i.e. you can use that number in SNMP queries literally. --Ricky

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-22 01:18:40

Somewhere in my collection of useless crap, I think I have a (very old) text file that describes how the SDL procedure for Courier modems works. If anyone thinks it would help in deciphering how PCSDL works, holler and I'll see if I can find it... I remember it said the Courier SDL file format was kinda strange, it had checksums sprinkled throughout the file itself, and the whole SDL file was embedded in the USRSDL.EXE program. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound?

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Allen Marsalis <am@shreve.net>
Date: 1998-10-22 01:26:29

At 01:06 AM 10/22/98 -0400, Ricky Beam wrote: >Allen Marsalis was heard to say: >>I'd rather flash a Netgear >>RT328 with xmodem over a P50/75 anyday with it's funky upload method.. > >Don't be dissin' Ascend! The P50/75 support (and always has?) xmodem. It >also has tftp support! really? I remember having to capture a binary dump to a text file or something.. maybe I was just thinking of capturing/saving configuration files. but of course those aren't binary represented data.. just text.. anyway, shouldn't be dissin Ascend.. this email is brought to you via a P75 sitting on my desk.. :) works like a champ and nailed up hard.. but I'm not ready for a TNT quite yet.. Allen > >--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. > >

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-22 01:29:37

On Thu, 22 Oct 1998, Ricky Beam wrote: > Allen Marsalis was heard to say: > >I'd rather flash a Netgear > >RT328 with xmodem over a P50/75 anyday with it's funky upload method.. > > Don't be dissin' Ascend! The P50/75 support (and always has?) xmodem. It > also has tftp support! Yup. Xmodem CRC is probably the *only* way to get code into an Ascend P25-fx. (That's the severely lobotomized bridging-only model. I have a pair running my link at home. Bleah.) The only thing "funky" about it is you have to hand-enter a bizarre key sequence to initiate the upload -- something involving escape, "-" and "=" I think. I can't remember now, since Ascend dropped the P25-fx and stopped releasing new firmware. You can dis Ascend for other things though. Their user interface, for one. Their bizarre ideas about SNMP and Radius, for another. (Ever try to get MRTG to monitor a Pipeline or a Max? The damn interface numbers keep changing every time the call drops and reconnects!!) But we're getting off topic here... :) Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound?

Subject: (usr-tc) HiPer "dead air" problem
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-22 02:41:14

We're starting to experience the "dead air" problem pretty severely here on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call rejection count on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. All four were rebooted less than 36 hours ago. All the interfaces show up/up right now. Per other people's recommendations here, I just fired an email off to Bellsouth to see if they can set their DMS100 to round-robin through the B channels instead of first-available. I'm also going to move some PRI's back to our spare Quads. The Quake players will just have to deal with it for a little while. :-) Once a card gets into this state, has anyone found any way to get those channels to behave themselves again, OTHER than busying out and then rebooting the whole DSP card? Also, when I went to reboot yesterday, the 4th DSP had several LEDs lit on its usage meter, despite the ARC showing no calls on that span. (I didn't check to see if the interfaces were up/up then, or what the reject count was.) Right now, it's showing 4 LED's, the reject count is 0, all interfaces are up, ATI6 on each modem shows several giving "current call" instead of "last call" times... yet the ARC shows only 1 active session. Hmm. Different problem? Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound?

Subject: Re: (usr-tc) HiPer "dead air" problem
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-22 03:06:25

On Thu, 22 Oct 1998, Mike Andrews wrote: > We're starting to experience the "dead air" problem pretty severely here > on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call rejection count > on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. > All four were rebooted less than 36 hours ago. All the interfaces show > up/up right now. > [munch] > > Also, when I went to reboot yesterday, the 4th DSP had several LEDs lit on > its usage meter, despite the ARC showing no calls on that span. (I didn't > check to see if the interfaces were up/up then, or what the reject count > was.) Right now, it's showing 4 LED's, the reject count is 0, all > interfaces are up, ATI6 on each modem shows several giving "current call" > instead of "last call" times... yet the ARC shows only 1 active session. > Hmm. Different problem? I hate following up to my own message, but: As it turns out, I've got my damn console cables wired backwards, and this one with 40% on the usage LEDs right now is the *same* DSP card (#1) with 3609 rejects on it. And ATI6 output is correct; it shows all modems but the one active session as "last call". So, no, probably not a different problem. :)

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-22 08:03:05

Thus spake Ricky Beam >Allen Marsalis was heard to say: >>I'd rather flash a Netgear >>RT328 with xmodem over a P50/75 anyday with it's funky upload method.. >Don't be dissin' Ascend! The P50/75 support (and always has?) xmodem. It >also has tftp support! Yeah, don't diss Ascend because of their flash upgrades. There are plenty of other legitimate reasons to diss Ascend...like that hideous, horrible menu system. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) QuadModem firmware version & connect tro
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-22 08:45:42

Ther's no such thing as 5.9.6 unless you have some kind of er code I've never heard of. It's probably 5.8.6; which is the last x2 code release. The latest code is the 5.9.9; which is the last v.90 code released. Please be more specific as to the strange tone you are hearing. I've taken several hundered calls at 3COM from customer's who said the same thing and found out what they were hearing was the v.90 bong. There are many problems with v.90 in general. Most of them do not relate to the cod on your Quads. Make sure all of your customer's are using the latest v.90 code available for their modems and the latest windows drivers. -----Original Message----- >Fellow TC users, > >we have two TC racks to receive orders from our >customers. They (the customers) have all kinds of >modems you could possibly imagine. > >Recently we have added QuadModem cards to our >racks to accommodate more traffic. The newer cards >have firmware release 5.9.9, the older ones have 5.9.6. > >Since then, a number of customers are reporting inter- >mittent connection problems and "unusual sounds" from >their modems when trying to connect with us. > >Are there known problems with 5.9.9 ? Is there information >available on which release fixes which problems ? > >I would like to have all Quads at the same firmware level, >but preferrably a good one ... ;-) > >TIA for sharing your experiences & best regards, >Walter > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Radius auth problems with ARC
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-22 08:57:54

On Wed, 21 Oct 1998, Peter D. Mayer wrote: > Krish, > > Thanks for the response. > > An "_auth <username> <password>" returns "CLI - User: <username> is > Authenticated", but a login from the "login:" prompt if I dial with a > terminal emulator still gets rejected: > > Welcome to 3Com Total Control HiPer ARC (TM) > Networks That Go The Distance (TM) > > login: <username> > Password: <password> > > Login Incorrect Port is setup wrong? or radius secrect mismatch? You can do a moni radius or mon ppp ( guess mon radius is only in 4.1.x ) At this point I will have to snoop the radius packet and see what it returns, may be your user is configured wrong. krish > > I'm not even trying to use PAP or CHAP at this point, although I had already > configured the authentication_preference to PAP, and authentication accept > to ANY (one of the first things I did in configuring the arc). > > Here's my current PPP and authentication settings (the 'x' numbers are of > course real and correct numbers in my config) : > > PPP AUTHENTICATION > DIAL_IN Users Authenticate: ANY > PPP Authentication Preference: PAP > System Transmit Authentication Name: arc1 > PPP offloading: ENABLED > CCP will be attempted for call type(s): DIGITAL > UNCOMPRESSED_ANALOG > Primary NBNS Server address: 0.0.0.0 > Secondary NBNS Server address: 0.0.0.0 > DNS configuration Usage: PPP-DNS > Primary PPP DNS Server address: x.x.x.x > Secondary PPP DNS Server address: x.x.x.x > PPP session start message: PPP session from %server_ip to > %client_ip beginning.... > > RADIUS AUTHENTICATION SETTINGS > Local Authentication is: DISABLED > Remote Authentication is: ENABLED > Hint Assigned is: DISABLED > Primary Server is: x.x.x.x > Primary Destination Port is: x > Secondary Server is: x.x.x.x > Secondary Destination Port is: x > Tertiary Server is: 0.0.0.0 > Tertiary Destination Port is: x > Source Port is: x > Retransmission Timeout: 3 seconds > Max Retranmissions: 10 > Vendor Specific Attribute: DISABLED > Active Authentication Server: x.x.x.x > > Is there a higher level of debug for RADIUS? Could this possibly be a > problem with anything else besides RADIUS? (i.e. span line config, modem > settings, etc.?) > > Thanks for your help on this. > Peter D. Mayer > NetWalk System Administrator > dmayer@netwalk.com > > -----Original Message----- > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com> > To: Peter D. Mayer <dmayer@netwalk.com> > Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > Date: Wednesday, October 21, 1998 10:52 AM > Subject: Re: (usr-tc) Radius auth problems with ARC > > > On Tue, 20 Oct 1998, Peter D. Mayer wrote: > > > Ok, so I got my first HiPer box last week and I'm just now configuring it. > > Everything seems setup properly so I tried to dial in. I get a nice > > 48000/V.90 connect and hit the login prompt. Typed my username and > password > > and was denied. > > > The first thing that you need to make sure is if the secrets are > correct. Change the secret and try. You can do a _auth username > password to verify if the user gets authenticated from the hiper arc > console. > > > So to the syslogs I go. Quite simply "Unable to authenticate user". Then > I > > looked at my Radius error logs and found odd usernames and passwords that > > look almost like mine, but not quite. Radius secret problem right? Maybe > > not. > > > It may not entierly be secret problem - It could be a secret problem. > What you need to do is find out if you are using chap or pap. Typically > if the user is being authenticated using the system password then chap > will not work. so change your ppp > > set ppp auTHENTICATION_PREFERENCE pap > > and try it again. > > > Also on the arc you have radius monitor to see what you send and receive > > mon radius is the command. > > krish > > I switched my secret on the ARC and the radius server told me I had the > > wrong one. Then I reset it on both sides and restarted the radius server > > and the secrets don't match error dropped out. I've set up this box just > > like my other 8 (NETServers) in the radius server, and used the same > secret > > for all of them. I've tried darn near every authentication setting I can > > find, with the same results. Suffice it to say that A) the server is > > allowed to send packets to my radius server, and B) I've triple checked > that > > the secret is the same. I even broke down and tried the HARM (amazingly > > like the old NETServer manager isn't it?) to configure it, same results. > > > > Anybody else have these kind of problems on initial config of the ARC? > What > > might I be missing? I've even deleted the whole config and started from > > scratch. > > > > Any input is greatly appreciated. > > > > BTW: is there a "Migration Guide" of sorts to help us reasonably advanced > > NETServer users quickly learn our way around the Hiper equipment? I feel > > very out-of-sorts wandering around the ARC command line. (feels like > there > > might be 30 settings I'm missing, but they're buried under 10 layers of > > command structure). Probably not. Oh well. > > > > Thanks for any suggestions, > > 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. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) QuadModem firmware version & connect tro
From: Stauffer Walter <stauffer@galenica.ch>
Date: 1998-10-22 09:30:34

Fellow TC users, we have two TC racks to receive orders from our customers. They (the customers) have all kinds of modems you could possibly imagine. Recently we have added QuadModem cards to our racks to accommodate more traffic. The newer cards have firmware release 5.9.9, the older ones have 5.9.6. Since then, a number of customers are reporting inter- mittent connection problems and "unusual sounds" from their modems when trying to connect with us. Are there known problems with 5.9.9 ? Is there information available on which release fixes which problems ? I would like to have all Quads at the same firmware level, but preferrably a good one ... ;-) TIA for sharing your experiences & best regards, Walter

Subject: (usr-tc) Number of retries to dial to a location?
From: Martin Oberle <moberle@gmx.de>
Date: 1998-10-22 10:28:49

Hi. How can I set how often a netserver trys to dial to a location? I want to set the netserver to dial only once. If the connection does not succed, the netserver should not try it again and clear its routing table to that locaction immediately. Thanks Martin

Subject: (usr-tc) Arc Problems
From: Dale Hege <fhege@sover.net>
Date: 1998-10-22 10:30:19

Hi, I'm running 4.1.11 and have been having troubles with MLPPP connections. It will run fine for about a week and then it will stop working. I'll reboot the arc and everything will be fine again. I was looking for info on why and found this. Facility "Telnet", Level "UNUSUAL":: tel_portal_xmit(): icb_queue() returned error : 0xfffffc08 Facility "Telnet", Level "UNUSUAL":: tel_update_flow_state(): Unknown flow state received : 0x0 I know it probably has nothing to do with the MLPPP problem but I was wondering what this does mean? Thanks, -Dale

Subject: RE: (usr-tc) Assigning IP's to different ports
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-22 11:00:18

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brett Murphy |Sent: Wednesday, October 21, 1998 10:48 PM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Assigning IP's to different ports | | | | |Hi All, | |I am trying to assign difefrent IP Pools for difefrent HyperDSP cards |in my chassis, and have set two pools for this purpose. They are |mainpool |secondpool |I need to assign mainpool to slots 3-11 and secondpool to slots 1 and 2 | |I cant see ANY way of doing this from the GUI or CLI, and have |been told my 3COM tech support to use vendor specific attributes in RADIUS | |I use Cistron Radiusd version 1.5.4.3 that supports VSA and have the following: | This can't be done from the HARC. The only possible way I can think of is that your RADIUS does the assignment based on the port information it gets in an access request or DNIS/ANI digits if you have different phone numbers for each DSP. Also as a note: You should create those pools as private for use with the RADIUS ip pool attribute. That way they don't get assigned unless explicitly specified by RADIUS. Please respond privately with who told you this was possible using VSA's? -M

Subject: RE: (usr-tc) Arc Problems
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-22 11:00:19

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dale Hege |Sent: Thursday, October 22, 1998 9:30 AM |To: usr-tc@lists.xmission.com |Subject: (usr-tc) Arc Problems | | | |Facility "Telnet", Level "UNUSUAL":: tel_portal_xmit(): icb_queue() |returned error : 0xfffffc08 |Facility "Telnet", Level "UNUSUAL":: tel_update_flow_state(): Unknown |flow state received : 0x0 | The answer is that these messages are set at the wrong log level. They should appear as COMMON or DEBUG. The first one is a indication that the driver is getting flow controlled. And the second one is FLOW_ON indication. They can be ignored. -M

Subject: Re: (usr-tc) Port number assignments on HyperARC
From: David Bolen <db3l@ans.net>
Date: 1998-10-22 11:29:33

Ricky Beam <jfbeam@Interpath.net> writes: >> It's a bug. The HARC reports an "Interface-Index" >> that uniquely ids the port (1000 + 256*<slot> + <channel>). > > FWIW, that's the NMC (SNMP) "identity number" for that > modem... i.e. you can use that number in SNMP queries literally. Close, but not quite. Entity numbering in the NMC managed MIBs is "slot*1000 + entity number". If the ARC uses "1000 + 256*slot + channel" then they don't match. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: (usr-tc) Hiper NAS-Port
From: Randy Cosby <dcosby@infowest.com>
Date: 1998-10-22 12:42:49

Can anyone explain what the NAS-Port radius attribute means for the hiper arc? Is there a way to translate it to slot:x/port:y? I know I can use the Chassis-Call-Slot and Chassis-Call-Channel, just wondering. Randy Cosby <dcosby@infowest.com> Vice President InfoWest Global Internet Services, Inc. (435)674-0165 http://www.infowest.com

Subject: (usr-tc) Assigning IP's to different ports
From: Brett Murphy <sysadmin@alphalink.com.au>
Date: 1998-10-22 13:48:09

Hi All, I am trying to assign difefrent IP Pools for difefrent HyperDSP cards in my chassis, and have set two pools for this purpose. They are mainpool secondpool I need to assign mainpool to slots 3-11 and secondpool to slots 1 and 2 I cant see ANY way of doing this from the GUI or CLI, and have been told my 3COM tech support to use vendor specific attributes in RADIUS I use Cistron Radiusd version 1.5.4.3 that supports VSA and have the following: Dictionary file: VENDOR USR 429 ATTRIBUTE Framed_IP_Address_Pool_Name 0x9024 string USR user file: DEFAULT Framed-Protocol = PPP Framed_IP_Address_Pool_Name = "mainpool", Framed-Compression = Van-Jacobson-TCP-IP This does NOT show up in a "monitor radius" from CLI when a user auths ok. Has anyone successfully done this? Even if I could STATIC IP the ports I'd be happy...... -- 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.

Subject: (usr-tc) Port number assignments on HyperARC
From: Brett Murphy <sysadmin@alphalink.com.au>
Date: 1998-10-22 13:55:04

Hi All, How does the hiperARC assign port numbers given to RADIUS accounting? I can sort of guess the first digit is (slot number -1) but the rest seems random. I use an expect script to reset ports remotely and need a solid way of converting the port number into a slot:n/mod:m forrmat that the CLI uses. eg #radlast test test 4123:as0 202.100.200.101 Thu Oct 22 13:36 - 13:52 (00:16) "4123" definitely means slot 3 but what modem?! -- 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.

Subject: Re: (usr-tc) Mime-Version: 1.0
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-22 13:56:34

-----Original Message----- > >> Ther's no such thing as 5.9.6 unless you have some kind of er code I've >> never heard of. It's probably 5.8.6; which is the last x2 code >release. >> The latest code is the 5.9.9; which is the last v.90 code released. > >Very likely I have misread and you are correct. It's all too easy to mix >up >version numbers these days ... > >> Please be more specific as to the strange tone you are hearing. I've >taken >> several hundered calls at 3COM from customer's who said the same thing >and >> found out what they were hearing was the v.90 bong. > >I will have to investigate first. Is this "v.90 bong" heard when the >modems >actually agree to do v.90 or always ? When I call my modems by the >phone, they all sound the same ... It'ss heard only when the client and the server are going to attempt negotiation of v.90 > >> There are many problems with v.90 in general. Most of them do not >relate to >> the cod on your Quads. Make sure all of your customer's are using the >> latest v.90 code available for their modems and the latest windows >drivers. > >I am thinking about disabling v.90 and x2 altogether, since our customers >are not transferring large amounts of data (we're not an Internet >provider). >Rather, I'd like to push ISDN for its faster connection setup. > >Thanks for your comment ! >Walter > > > -----Original Message----- >From: Stauffer Walter <stauffer@galenica.ch> >To: <usr-tc@xmission.com> >Date: Thursday, October 22, 1998 2:30 AM >Subject: (usr-tc) QuadModem firmware version & connect tro > > >>Fellow TC users, >> >>we have two TC racks to receive orders from our >>customers. They (the customers) have all kinds of >>modems you could possibly imagine. >> >>Recently we have added QuadModem cards to our >>racks to accommodate more traffic. The newer cards >>have firmware release 5.9.9, the older ones have 5.9.6. >> >>Since then, a number of customers are reporting inter- >>mittent connection problems and "unusual sounds" from >>their modems when trying to connect with us. >> >>Are there known problems with 5.9.9 ? Is there information >>available on which release fixes which problems ? >> >>I would like to have all Quads at the same firmware level, >>but preferrably a good one ... ;-) >> >>TIA for sharing your experiences & best regards, >>Walter >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Assigning IP's to different ports
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-22 13:59:28

Mike, I have heard this request many times before. Can we put in a feature request to add the capability to specify which ip pool to use in modem group settings. i.e. add modem_group mainpool set modem_group slot3to11 ip pool mainpool Should be easy to make work -----Original Message----- >|-----Original Message----- >|From: owner-usr-tc@lists.xmission.com >|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brett Murphy >|Sent: Wednesday, October 21, 1998 10:48 PM >|To: usr-tc@lists.xmission.com >|Subject: (usr-tc) Assigning IP's to different ports >| >| >| >| >|Hi All, >| >|I am trying to assign difefrent IP Pools for difefrent HyperDSP cards >|in my chassis, and have set two pools for this purpose. They are >|mainpool >|secondpool >|I need to assign mainpool to slots 3-11 and secondpool to slots 1 and 2 >| >|I cant see ANY way of doing this from the GUI or CLI, and have >|been told my 3COM tech support to use vendor specific attributes in RADIUS >| >|I use Cistron Radiusd version 1.5.4.3 that supports VSA and have the following: >| > >This can't be done from the HARC. The only possible way I can think of is that >your RADIUS does the assignment based on the port information it gets in an >access request or DNIS/ANI digits if you have different phone numbers for each >DSP. > >Also as a note: You should create those pools as private for use with the RADIUS >ip pool attribute. That way they don't get assigned unless explicitly specified >by RADIUS. > >Please respond privately with who told you this was possible using VSA's? > >-M > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) list sessions
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-22 14:03:42

This is a multi-part message in MIME format. ------=_NextPart_000_00B3_01BDFDC4.C697DAE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Has anyone seen the following user list sessions on HiPer ARC 4.0.30? SESSIONS Name Conn_Type Prot_Type =20 administrator LAN UNKNOWN administrator LAN UNKNOWN administrator LAN UNKNOWN administrator LAN UNKNOWN administrator LAN UNKNOWN administrator LAN UNKNOWN administrator LAN UNKNOWN administrator LAN UNKNOWN administrator LAN UNKNOWN HiPer>> =20 I know for a fact I'm the only one logged into it and I'm not logged in = as administrator Is there a HiPer ARC equivalent to the old netserver command reset = <netconns name> ------=_NextPart_000_00B3_01BDFDC4.C697DAE0 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 5.00.0518.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Has anyone seen the following user = list sessions=20 on HiPer ARC 4.0.30?</FONT></DIV> <DIV><FONT color=3D#000000=20 size=3D2>SESSIONS<BR>Name        =             &= nbsp;       =20 Conn_Type Prot_Type       </FONT></DIV> <DIV><FONT color=3D#000000=20 size=3D2>administrator        &nb= sp;          =20 LAN      =20 UNKNOWN<BR>administrator        &= nbsp;          =20 LAN      =20 UNKNOWN<BR>administrator        &= nbsp;          =20 LAN      =20 UNKNOWN<BR>administrator        &= nbsp;          =20 LAN      =20 UNKNOWN<BR>administrator        &= nbsp;          =20 LAN      =20 UNKNOWN<BR>administrator        &= nbsp;          =20 LAN      =20 UNKNOWN<BR>administrator        &= nbsp;          =20 LAN      =20 UNKNOWN<BR>administrator        &= nbsp;          =20 LAN      =20 UNKNOWN<BR>administrator        &= nbsp;          =20 LAN      =20 UNKNOWN<BR>HiPer>>        &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;     =20 </FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT color=3D#000000 size=3D2>I know for a fact I'm the only one = logged into=20 it and I'm not logged in as administrator</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Is there a HiPer ARC equivalent to the old netserver = command=20 reset <netconns name></FONT></DIV> </BODY></HTML> ------=_NextPart_000_00B3_01BDFDC4.C697DAE0--

Subject: Re: (usr-tc) Port number assignments on HyperARC
From: Brett Murphy <sysadmin@alphalink.com.au>
Date: 1998-10-22 14:07:27

Mark R. Lindsey wrote: > : How does the hiperARC assign port numbers given to RADIUS accounting? > : I can sort of guess the first digit is (slot number -1) but the rest seems > : random. > <snip> > It's a bug. The HARC reports an "Interface-Index" > that uniquely ids the port (1000 + 256*<slot> + <channel>). Thanks for that, not as random as it looked :) -- 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.

Subject: Re: (usr-tc) Hiper NAS-Port
From: Jason W <jwatkins@iland.net>
Date: 1998-10-22 14:08:31

I believe, if I understood the question correctly that you see odd port numbers instead of 's2' etc... Basically with the latest HiPer ARC code that attribute changed. I'm not sure why. But the formula is 256 * slot + port = port# =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Jason Watkins jwatkins@iland.net I-Land NOC Tech http://www.iland.net =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -----Original Message----- >Can anyone explain what the NAS-Port radius attribute means for the hiper >arc? Is there a way to translate it to slot:x/port:y? I know I can use the >Chassis-Call-Slot and Chassis-Call-Channel, just wondering. > >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. >

Subject: (usr-tc) Change Date/Time for Total Control NMC PRI Card
From: Budi Wiyono <budiw@idola.net.id>
Date: 1998-10-22 14:20:13

Dear All, I'm using Total Control Manager version 4.3.6, If we want to see Date and Time of our NMC Card, we can do as bellow: View | LED Polling information 1. I need to change date/time of USR Network Management Card. How can we do that ? 2. Does anyone have Y2K test plan for Total Control NMC card and Netserver Card ? Pls hlp. Thanks, Budiw

Subject: Re: (usr-tc) Port number assignments on HyperARC
From: Brett Murphy <sysadmin@alphalink.com.au>
Date: 1998-10-22 14:44:39

Mark R. Lindsey wrote: > : How does the hiperARC assign port numbers given to RADIUS accounting? > : I can sort of guess the first digit is (slot number -1) but the rest seems > : random. > > It's a bug. The HARC reports an "Interface-Index" > that uniquely ids the port (1000 + 256*<slot> + <channel>). > > --Ricky > > What am I doing wrong?! I have a port number 7187 reported for slot slot:8/mod:20 Thats 1000+256*8+20 = 3068 ??! -- 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.

Subject: (usr-tc) On demand analog dialout
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-22 15:04:52

This is a multi-part message in MIME format. ------=_NextPart_000_00D7_01BDFDCD.520F4F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm working with a customer who has 7 pop sites. Their frame provider = is Sprint. Sprint seems to be either incompetent or under some kind of = a constant attack because their frame continually goes down. I had an idea to work around part of this issue: On demand dialout (from remote sites that may be cut off from the main = site) to the main site. =20 Since the main site also has several chassis with HiPer ARC's and HiPer = DSP's I thought we could bundle channels together and initiate more = outbound calls as bandwidth requirements increase. I have seen this done with ISDN between two Hiper ARC's running 4.0.19. = In fact when we played around with it at 3COM we bundled 6 to a channels = together. The book says HiPer DSP's and ARC's are capable of bundling = 16 channels. I have 3 questions: 1. Can we set something up on the HiPer ARC so that an outbound call is = initiated only when the default route in the ip route table points to a = gateway that is no longer reachable? If so, then I'm sure we can use the set deafult_route user command to = add a new default route to the on demand user. 2. If the above can be done then my next question is "Can I bundle more = than one analog lines together between two sets of HiPer ARC's and = DSP's? End result being I do not want the users to be aware of a = throughput difference. 3. Finally, can we drop the on demand connection when the original = default gateway is once again reachable through ethernet? The above questions are probably more for our Network Engineering folks = at 3COM, but I would love to hear from anyone who may have some insight = or a different approach for our problems. Another frame provider is not = a option in the area the equipment is located. I'm fairly certain the HiPer ARC does not have some of these abilities. = If it does not, can someone at 3COM respond with a plausible solution or = submit a feature request. Thank you ------=_NextPart_000_00D7_01BDFDCD.520F4F60 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 5.00.0518.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>I'm working with a customer who has = 7 pop=20 sites.  Their frame provider is Sprint.  Sprint seems to be = either=20 incompetent or under some kind of a constant attack because their frame=20 continually goes down.</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> <DIV><FONT size=3D2>I had an idea to work around part of this = issue:</FONT></DIV> <DIV><FONT size=3D2>On demand dialout (from remote sites that may be cut = off from=20 the main site) to the main site.  </FONT></DIV> <DIV><FONT size=3D2>Since the main site also has several chassis with = HiPer ARC's=20 and HiPer DSP's I thought we could bundle channels together and initiate = more=20 outbound calls as bandwidth requirements increase.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>I have seen this done with ISDN between two Hiper = ARC's=20 running 4.0.19.  In fact when we played around with it at 3COM we = bundled 6=20 to a channels together.  The book says HiPer DSP's and ARC's are = capable of=20 bundling 16 channels.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>I have 3 questions:</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>1.  Can we set something up on the HiPer ARC so = that an=20 outbound call is initiated only when the default route in the ip route = table=20 points to a gateway that is no longer reachable?</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>If so, then I'm sure we can use the set = deafult_route user=20 command to add a new default route to the on demand user.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>2.  If the above can be done then my next = question is=20 "Can I bundle more than one analog lines together between two sets = of HiPer=20 ARC's and DSP's?  End result being I do not want the users to be = aware of a=20 throughput difference.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>3.  Finally, can we drop the on demand = connection when=20 the original default gateway is once again reachable through=20 ethernet?</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>The above questions are probably more for our = Network=20 Engineering folks at 3COM, but I would love to hear from anyone who may = have=20 some insight or a different approach for our problems.  Another = frame=20 provider is not a option in the area the equipment is = located.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>I'm fairly certain the HiPer ARC does not have some = of these=20 abilities.  </FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>If it does not, can someone at 3COM respond with a = plausible=20 solution or submit a feature request.</FONT></DIV> <DIV><FONT size=3D2></FONT> </DIV> <DIV><FONT size=3D2>Thank you</FONT></DIV> </BODY></HTML> ------=_NextPart_000_00D7_01BDFDCD.520F4F60--

Subject: (usr-tc) Upgraded 5.0.7 to 6.0.8 - no CALLS
From: David Swearingin <david@carolnet.com>
Date: 1998-10-22 15:13:51

I upgraded from 5.0.7 to 6.0.8 and imported the databases, but now no new entries are being made in the CALLS table, but entries are being made to the EVENTS table. The security report in Access called "Logged In Users" comes up empty. Users appear to be connecting OK. Any help would be appreciated. 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

Subject: Re: (usr-tc) On demand analog dialout
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-22 15:39:40

Thanks Jeff Now, if 3COM will comment maybe we can get it fine tuned -----Original Message----- >Thus spake Brian K McIntire >>I'm working with a customer who has 7 pop sites. Their frame provider = >>is Sprint. Sprint seems to be either incompetent or under some kind of = >>a constant attack because their frame continually goes down. > >Personally, I would guess the former, but that's not really important >here. :) > >>I have seen this done with ISDN between two Hiper ARC's running 4.0.19. = >>In fact when we played around with it at 3COM we bundled 6 to a channels = >>together. The book says HiPer DSP's and ARC's are capable of bundling = >>16 channels. > >Whoa...put that PPC to the test man...MP bundling is quite processor >intensive...I can only imagine what 16 channels would do to it :) > >>1. Can we set something up on the HiPer ARC so that an outbound call is = >>initiated only when the default route in the ip route table points to a = >>gateway that is no longer reachable? > >Might look at picking up your default route from RIPv2, that way, if the >link goes down, so does the RIPv2 advertisements and therefore your >default route. The question then is, how do you get the HARC to >dial-on-demand when there's no default route in place. That might be >easier to work out. > >>If so, then I'm sure we can use the set deafult_route user command to = >>add a new default route to the on demand user. > >Yup, just a trick of getting the thing to dial first. :) > >>2. If the above can be done then my next question is "Can I bundle more = >>than one analog lines together between two sets of HiPer ARC's and = >>DSP's? End result being I do not want the users to be aware of a = >>throughput difference. > >Should be no problem with this...MP is MP, whether its used on an analog >line or ISDN, or T1, or whatever really doesn't change the process...or >at least there's no *reason* that it should change the process. We do >analog link bundling on NETServer's all the time...no difference from >ISDN bundling...I would assume the HARC would do the same. > >>3. Finally, can we drop the on demand connection when the original = >>default gateway is once again reachable through ethernet? > >Well...if you're picking up your default route through RIPv2 (which >would eliminate the need for default_route user setting), then when the >frame link came back, it should be trivial to make it more >attractive...this would mean that most of the bundled links could be >pared down just by letting it go idle for a bit and as the traffic level >on the link falls, channels would be removed...now, getting the last one >to get dropped would be tricky since it wouldn't really be totally idle >since you're getting RIPv2 updates on it still (if that's the way you >choose to implement it). That would be the last hurdle I could think of >to make this work right, and I can't think of an easy solution off the >top of my head with current code. > >>The above questions are probably more for our Network Engineering folks = >>at 3COM, but I would love to hear from anyone who may have some insight = >>or a different approach for our problems. Another frame provider is not = >>a option in the area the equipment is located. > >Well...I've thrown my thoughts out for it...for what they're >worth...hope they help. > >>If it does not, can someone at 3COM respond with a plausible solution or = >>submit a feature request. > >I *will* repeat my oft-requested feature of an idle-time >filter...meaning a filter that doesn't block packets from going over the >wire, but that instead specifies what types of packets reset the >idle-timer for idle-timeout settings. This would be *extremely* >useful...not only in this situation (just filter RIP adverts from >resetting the idle timer and let the idle timeout drop the last link of >the bundle) but also for those of us dealing with abusive users that set >Eudora to check their POP mail every 2 minutes to defeat idle timeouts. >-- >Jeff McAdams Email: jeffm@iglou.com >Head Network Administrator Voice: (502) 966-3848 >IgLou Internet Services (800) 436-4456 > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Hiper NAS-Port
From: Randy Cosby <dcosby@infowest.com>
Date: 1998-10-22 15:57:40

That appears to be correct, but I'm on an older version of hiperARC (ain't broke, won't fix it). Wonder if that's been changed? Thanks. > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Marcelo Souza > Sent: Thursday, October 22, 1998 3:25 PM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) Hiper NAS-Port > > > On Thu, 22 Oct 1998, Jason W wrote: > > |I believe, if I understood the question correctly that you see odd port > |numbers instead of 's2' etc... Basically with the latest HiPer ARC code > |that attribute changed. I'm not sure why. But the formula is > |256 * slot + port = port# > > I think the correct is: > > 256 * (slot-1) + port = port# > > - Marcelo > > |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > |Jason Watkins jwatkins@iland.net > |I-Land NOC Tech http://www.iland.net > |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > |-----Original Message----- > |From: Randy Cosby <dcosby@infowest.com> > |To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> > |Date: Thursday, October 22, 1998 2:00 PM > |Subject: (usr-tc) Hiper NAS-Port > | > | > |>Can anyone explain what the NAS-Port radius attribute means for > the hiper > |>arc? Is there a way to translate it to slot:x/port:y? I know I can use > |the > |>Chassis-Call-Slot and Chassis-Call-Channel, just wondering. > |> > |>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. > | > > - 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. >

Subject: Re: (usr-tc) On demand analog dialout
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-22 16:21:36

Thus spake Brian K McIntire >I'm working with a customer who has 7 pop sites. Their frame provider = >is Sprint. Sprint seems to be either incompetent or under some kind of = >a constant attack because their frame continually goes down. Personally, I would guess the former, but that's not really important here. :) >I have seen this done with ISDN between two Hiper ARC's running 4.0.19. = >In fact when we played around with it at 3COM we bundled 6 to a channels = >together. The book says HiPer DSP's and ARC's are capable of bundling = >16 channels. Whoa...put that PPC to the test man...MP bundling is quite processor intensive...I can only imagine what 16 channels would do to it :) >1. Can we set something up on the HiPer ARC so that an outbound call is = >initiated only when the default route in the ip route table points to a = >gateway that is no longer reachable? Might look at picking up your default route from RIPv2, that way, if the link goes down, so does the RIPv2 advertisements and therefore your default route. The question then is, how do you get the HARC to dial-on-demand when there's no default route in place. That might be easier to work out. >If so, then I'm sure we can use the set deafult_route user command to = >add a new default route to the on demand user. Yup, just a trick of getting the thing to dial first. :) >2. If the above can be done then my next question is "Can I bundle more = >than one analog lines together between two sets of HiPer ARC's and = >DSP's? End result being I do not want the users to be aware of a = >throughput difference. Should be no problem with this...MP is MP, whether its used on an analog line or ISDN, or T1, or whatever really doesn't change the process...or at least there's no *reason* that it should change the process. We do analog link bundling on NETServer's all the time...no difference from ISDN bundling...I would assume the HARC would do the same. >3. Finally, can we drop the on demand connection when the original = >default gateway is once again reachable through ethernet? Well...if you're picking up your default route through RIPv2 (which would eliminate the need for default_route user setting), then when the frame link came back, it should be trivial to make it more attractive...this would mean that most of the bundled links could be pared down just by letting it go idle for a bit and as the traffic level on the link falls, channels would be removed...now, getting the last one to get dropped would be tricky since it wouldn't really be totally idle since you're getting RIPv2 updates on it still (if that's the way you choose to implement it). That would be the last hurdle I could think of to make this work right, and I can't think of an easy solution off the top of my head with current code. >The above questions are probably more for our Network Engineering folks = >at 3COM, but I would love to hear from anyone who may have some insight = >or a different approach for our problems. Another frame provider is not = >a option in the area the equipment is located. Well...I've thrown my thoughts out for it...for what they're worth...hope they help. >If it does not, can someone at 3COM respond with a plausible solution or = >submit a feature request. I *will* repeat my oft-requested feature of an idle-time filter...meaning a filter that doesn't block packets from going over the wire, but that instead specifies what types of packets reset the idle-timer for idle-timeout settings. This would be *extremely* useful...not only in this situation (just filter RIP adverts from resetting the idle timer and let the idle timeout drop the last link of the bundle) but also for those of us dealing with abusive users that set Eudora to check their POP mail every 2 minutes to defeat idle timeouts. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) reporting connect speed in radius request VSA's?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-10-22 16:22:55

How do i get a hiperarc to send the user's connect speed in the radius request packet? Right now, all I get is: User-Name = "someluser" Password = "[somecrap]" Client-Id = hiperarc.ip.address NAS-Port = 8 USR-Interface-Index = 1264 User-Service-Type = 2 Framed-Protocol = PPP USR-Chassis-Call-Slot = 1 USR-Chassis-Call-Span = 1 USR-Chassis-Call-Channel = 8 Client-Port-DNIS = "luser's-dnis" Caller-ID = "luser's-ani" NAS-Port-Type = Async It would be nice at the very least to get the Modulation-Type (v90, x2, etc), so I can reject x2/v90 users who havent paid for that service. -Dan

Subject: Re: (usr-tc) Interested in Linux on the Netserver?
From: John T. Farmer <jfarmer@goldsword.com>
Date: 1998-10-22 16:27:45

While the thought of Linux or FreeBSD,e tc. on the TC box is interesting, what I would raither see is the effort put into adapting open-source solutions to the computer based telephony tools that can/would take the place of the TC, HIper, etc. Take a look at some of the componments available either for the ISA or the PCI bus, all interconnected with the MVIP or SCSA bus. Literally, you can get a card with 24 or 48 DSP-based modems, other cards that accept 1, 2 or a dozen POTS, ISDN BRIs, or PRIs, or channelized T-1's. With drivers available, you could mix & match your own rack mount PC-based RAS. However, most vendors are only offering NT drivers, or if they support Unix, it's SCO, Unixware, or sometimes Solaris. Another possiblity in terms of "clustering" is the use of the PICMG standard Compact PCI bus. Hot swappable cards, standard PCI chip sets used, segmented backplane boxes available, and CPU's can range from 486 through any of the Pentium class (K6 & Pentium II), PowerPC, Sparc, or Alpha series. The big win in these cases is the fact that Linux, FreeBSD, NetBSD, etc. are already functioning with equipment (booting, running, etc.). What would be needed is to create the drivers to control the MVIP bus cards, load DSP code in the modem cards, and create the tools to "roll your own RAS box." John <Lots of fun hardware projects, so little time...> John T. Farmer Proprietor, GoldSword Systems jfarmer@goldsword.com Public Internet Access in East Tennessee Office: (423)691-6498 for info, e-mail to info@goldsword.com Network Design, Internet Services & Servers, Consulting

Subject: (usr-tc) Modem settings
From: Tony Loosle <tony@tcsourceone.com>
Date: 1998-10-22 17:13:15

Could someone that is using the Netserver 16I's share their modem settings with me. I would like to see some better speeds out of the box. Tony

Subject: (usr-tc) pmwho?
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-22 17:32:20

Hi, I'm starting to set up radiator, but I'm running into a problem with pmwho. I grabbed the most current version I could find (not sure why it's not bundled with Radiator...) but it doesn't talk to some of our netservers. Version is 1.6. I'm testing from one machine, and pmwho times out on some of the netservers, and not others. They are all running 3.7.73, and are all reachable by "manually" telnet-ing to each of them. The default pw is the same on all, as is the telnet port. What might be wrong? Thanks, Charles =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: (usr-tc) Mime-Version: 1.0
From: Stauffer Walter <stauffer@galenica.ch>
Date: 1998-10-22 19:15:07

> Ther's no such thing as 5.9.6 unless you have some kind of er code I've > never heard of. It's probably 5.8.6; which is the last x2 code release. > The latest code is the 5.9.9; which is the last v.90 code released. Very likely I have misread and you are correct. It's all too easy to mix up version numbers these days ... > Please be more specific as to the strange tone you are hearing. I've taken > several hundered calls at 3COM from customer's who said the same thing and > found out what they were hearing was the v.90 bong. I will have to investigate first. Is this "v.90 bong" heard when the modems actually agree to do v.90 or always ? When I call my modems by the phone, they all sound the same ... > There are many problems with v.90 in general. Most of them do not relate to > the cod on your Quads. Make sure all of your customer's are using the > latest v.90 code available for their modems and the latest windows drivers. I am thinking about disabling v.90 and x2 altogether, since our customers are not transferring large amounts of data (we're not an Internet provider). Rather, I'd like to push ISDN for its faster connection setup. Thanks for your comment ! Walter -----Original Message----- >Fellow TC users, > >we have two TC racks to receive orders from our >customers. They (the customers) have all kinds of >modems you could possibly imagine. > >Recently we have added QuadModem cards to our >racks to accommodate more traffic. The newer cards >have firmware release 5.9.9, the older ones have 5.9.6. > >Since then, a number of customers are reporting inter- >mittent connection problems and "unusual sounds" from >their modems when trying to connect with us. > >Are there known problems with 5.9.9 ? Is there information >available on which release fixes which problems ? > >I would like to have all Quads at the same firmware level, >but preferrably a good one ... ;-) > >TIA for sharing your experiences & best regards, >Walter > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Hiper NAS-Port
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-10-22 19:24:42

On Thu, 22 Oct 1998, Jason W wrote: |I believe, if I understood the question correctly that you see odd port |numbers instead of 's2' etc... Basically with the latest HiPer ARC code |that attribute changed. I'm not sure why. But the formula is |256 * slot + port = port# I think the correct is: 256 * (slot-1) + port = port# - Marcelo |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |Jason Watkins jwatkins@iland.net |I-Land NOC Tech http://www.iland.net |=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= |-----Original Message----- |From: Randy Cosby <dcosby@infowest.com> |To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> |Date: Thursday, October 22, 1998 2:00 PM |Subject: (usr-tc) Hiper NAS-Port | | |>Can anyone explain what the NAS-Port radius attribute means for the hiper |>arc? Is there a way to translate it to slot:x/port:y? I know I can use |the |>Chassis-Call-Slot and Chassis-Call-Channel, just wondering. |> |>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. | - Marcelo

Subject: Re: (usr-tc) Dumb question: PRIs and analog calls
From: Vito Maselli <vito_maselli@mw.3com.com>
Date: 1998-10-22 19:57:37

Dave, If you want to upgrade you Netserver to 3.8.1, then yes you have to upgrade the Netserver to 16 Meg. If your updating all of your hardware to TCS 3.3, then I would do the following. You might want to run and print out a copy of an inventory on the chassis before doing the upgrade to TCS 3.3. Just do an inventory with Total Control Manager . 1) Download and install Total Control Manager for TCS 3.3. 2) Upgrade your NMC card with the appropriate version. ( 5.4.1for 4meg NMC, 5.5.5 for a 16meg NMC ) 3) Make sure your Quad cards have at least versions 5.5.7 ( Double sided) and 5.6.7 ( single sided), before upgrading to 5.9.9 or 5.10.9. 4) Just upgrade your T1/PRI card to the latest version. 5) Upgrade your Netserver to 16meg and then upgrade it to 3.8.1 Vito "Dave Winston" <mhamrich@drfast.net> on 10/22/98 07:10:27 PM Please respond to usr-tc@lists.xmission.com cc: (Vito Maselli/MW/US/3Com) System release 3.3. I just gained access to the chart. My predecessor downloaded many of the releases, but he never installed any of them. Do I have to put all the ones he missed on in order (ee-gadds hours of work) or just the last code for the Netserver, Netmanager, T1/PRI and the Quads. Also have 4meg Netserver. Should we buy the 16meg upgrade. Thanks Dave Winston I have to subscribe to this list, using old sys admin. account for now -----Original Message----- >He's talking about TCS 2.5.1 >-----Original Message----- >From: Vito Maselli <Vito_Maselli@mw.3com.com> >To: <usr-tc@lists.xmission.com> >Date: Tuesday, October 20, 1998 7:03 PM >Subject: Re: (usr-tc) Dumb question: PRIs and analog calls > > >> >>Mike, >> >>Your e-mails a little confusing. When you say ver 2.5.1 your talking about >>your Dual T1/PRI card. When you mention 3.8.1 your talking about your >>Netserver card. Are you trying to upgrade your TC Hub to TCS 3.3 ( System >>release 3.3) ? >> >> >> >> >>Vito >> >> >> >> >>"Mike Hamrich" <mhamrich@drfast.net> on 10/01/98 06:33:09 PM >> >>Please respond to usr-tc@lists.xmission.com >> >>To: usr-tc@lists.xmission.com >>cc: (Vito Maselli/MW/US/3Com) >>Subject: Re: (usr-tc) Dumb question: PRIs and analog calls >> >> >> >> >>How do you install the V.90 3.8.1 release. >> >>Is there any magic order of cards that should be followed. >> >>Also is it OK to go from 2.5.1 to 3.8.1 my predecessor did not keep the >>chassis to current :) >> >>Dave Winston >>-----Original Message----- >>From: Mike Andrews <mandrews@termfrost.org> >>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>Date: Thursday, October 01, 1998 11:37 AM >>Subject: Re: (usr-tc) Dumb question: PRIs and analog calls >> >> >>>On Wed, 30 Sep 1998, Mark R. Lindsey wrote: >>> >>>> Thanks for the help. >>>> >>>> Would I be right to guess that v.90 and X2 work on such lines, too. >>> >>>Yup. In theory it should work *better* with PRI than with CT1, because of >>>the extra 8K of bandwidth per channel. (23 channels of 64K instead of 24 >>>channels of 56K (b8zs) or 48K (ami)). We've never actually tried using >>>CT1 here so I can't back that up with personal experience, but I can say >>>that we have people getting 53333 connects with v.90 on our PRI's... >>> >>> >>>[munch] >>>> : >Thus spake Mark R. Lindsey >>>> : >>Can a cht1 card, and the quad modems it talks to, or an HDM, be >>configured >>>> : >>to terminate a PRI that takes calls both from analog modems and ISDN >>>> : >>users? >>>> : > >>>> : >>Excuse my ignorance, please; I've never worked with ISDN. I've been >>under >>>> : >>the impression that PRI == ISDN calls only, but our BellSouth >>salespeople >>>> : >>told us that they can send analog calls down the B channels. >>> >>> >>>- >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> >> >> >> >> >> >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Dumb question: PRIs and analog calls
From: Dave Winston <mhamrich@drfast.net>
Date: 1998-10-22 20:10:27

System release 3.3. I just gained access to the chart. My predecessor downloaded many of the releases, but he never installed any of them. Do I have to put all the ones he missed on in order (ee-gadds hours of work) or just the last code for the Netserver, Netmanager, T1/PRI and the Quads. Also have 4meg Netserver. Should we buy the 16meg upgrade. Thanks Dave Winston I have to subscribe to this list, using old sys admin. account for now -----Original Message----- >He's talking about TCS 2.5.1 >-----Original Message----- >From: Vito Maselli <Vito_Maselli@mw.3com.com> >To: <usr-tc@lists.xmission.com> >Date: Tuesday, October 20, 1998 7:03 PM >Subject: Re: (usr-tc) Dumb question: PRIs and analog calls > > >> >>Mike, >> >>Your e-mails a little confusing. When you say ver 2.5.1 your talking about >>your Dual T1/PRI card. When you mention 3.8.1 your talking about your >>Netserver card. Are you trying to upgrade your TC Hub to TCS 3.3 ( System >>release 3.3) ? >> >> >> >> >>Vito >> >> >> >> >>"Mike Hamrich" <mhamrich@drfast.net> on 10/01/98 06:33:09 PM >> >>Please respond to usr-tc@lists.xmission.com >> >>To: usr-tc@lists.xmission.com >>cc: (Vito Maselli/MW/US/3Com) >>Subject: Re: (usr-tc) Dumb question: PRIs and analog calls >> >> >> >> >>How do you install the V.90 3.8.1 release. >> >>Is there any magic order of cards that should be followed. >> >>Also is it OK to go from 2.5.1 to 3.8.1 my predecessor did not keep the >>chassis to current :) >> >>Dave Winston >>-----Original Message----- >>From: Mike Andrews <mandrews@termfrost.org> >>To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >>Date: Thursday, October 01, 1998 11:37 AM >>Subject: Re: (usr-tc) Dumb question: PRIs and analog calls >> >> >>>On Wed, 30 Sep 1998, Mark R. Lindsey wrote: >>> >>>> Thanks for the help. >>>> >>>> Would I be right to guess that v.90 and X2 work on such lines, too. >>> >>>Yup. In theory it should work *better* with PRI than with CT1, because of >>>the extra 8K of bandwidth per channel. (23 channels of 64K instead of 24 >>>channels of 56K (b8zs) or 48K (ami)). We've never actually tried using >>>CT1 here so I can't back that up with personal experience, but I can say >>>that we have people getting 53333 connects with v.90 on our PRI's... >>> >>> >>>[munch] >>>> : >Thus spake Mark R. Lindsey >>>> : >>Can a cht1 card, and the quad modems it talks to, or an HDM, be >>configured >>>> : >>to terminate a PRI that takes calls both from analog modems and ISDN >>>> : >>users? >>>> : > >>>> : >>Excuse my ignorance, please; I've never worked with ISDN. I've been >>under >>>> : >>the impression that PRI == ISDN calls only, but our BellSouth >>salespeople >>>> : >>told us that they can send analog calls down the B channels. >>> >>> >>>- >>> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >>> with "unsubscribe usr-tc" in the body of the message. >>> For information on digests or retrieving files and old messages send >>> "help" to the same address. Do not use quotes in your message. >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> >> >> >> >> >> >> >> >>- >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Hint Assigned on Netserver?
From: Brian <signal@shreve.net>
Date: 1998-10-22 20:57:27

On Wed, 21 Oct 1998, Brian K McIntire wrote: > Makes no difference that I know of hint assigned causes the NAS to send an address hint in the access-request packet. This allows radius servers to use that address when building dynamic filters which are sent in the access-reply packet. > -----Original Message----- > From: Wayne Barber <barberw@tidewater.net> > To: usr-tc <usr-tc@lists.xmission.com> > Date: Wednesday, October 21, 1998 1:14 PM > Subject: (usr-tc) Hint Assigned on Netserver? > > > >Can someone refresh my brain about what Hint Assigned does? Should it be on > >or off? > > > >Thanks, > >Wayne Barber > >Coastal Telco Services > > > > > >- > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) per user filters on HiPerARC
From: Mark van Wouw <vanwouw@gol.com>
Date: 1998-10-22 21:16:41

At 09:55 AM 10/21/98 -0400, Kevin Benton wrote: >On Wed, 21 Oct 1998, Mark van Wouw wrote: > >> INFORMATION FOR USER: <userid> >> Status: INACTIVE > >Is your RADIUS server overriding the user info since the user is inactive? >Have you tried setting up the filter in RADIUS? Thanks for your reply Kevin. The "Status: INACTIVE" just means that the user isn't currently connected. Since the user is local to the HiPerARC, the user is locally authenticated and the radius server is not queried at all. I haven't tried to set this up through radius, and it might well work, but it should be *easier* to bind a filter on the HARC to the local user (at least this is what I thought). I've set this up on netservers in the past and it wasn't too much of a problem. Has anyone been successful with filters on a HARC user? Mark.

Subject: Re: (usr-tc) Assigning IP's to different ports
From: MegaZone <megazone@megazone.org>
Date: 1998-10-22 23:15:30

Once upon a time Brett Murphy shaped the electrons to say... >I cant see ANY way of doing this from the GUI or CLI, and have >been told my 3COM tech support to use vendor specific attributes in RADIUS > >I use Cistron Radiusd version 1.5.4.3 that supports VSA and have the following: > >Dictionary file: >VENDOR USR 429 >ATTRIBUTE Framed_IP_Address_Pool_Name 0x9024 string USR Note that 3Com/USR did NOT use the RFC recommended formats for VSA - and Cistron at this time only supports the RFC format. There are user contributed patches that appear to support 3Com VSAs ok. See the Cistron RADIUS user mailing list for more info on getting this. Note that this is ok - it is a SHOULD in the RFC, not a MUST. So 3Com, while odd man out, didn't violate anything lest someone thing I'm implying such. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) Number of retries to dial to a location?
From: MegaZone <megazone@megazone.org>
Date: 1998-10-22 23:17:32

Once upon a time Martin Oberle shaped the electrons to say... >How can I set how often a netserver trys to dial to a location? >I want to set the netserver to dial only once. If the connection >does not succed, the netserver should not try it again and >clear its routing table to that locaction immediately. Well, the only way to do this is to make it a manually dialed entry. You can't do this with dial on demand, or continuous dial locations. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: (usr-tc) Can someone help? HARC Crash
From: Dale Hege <fhege@sover.net>
Date: 1998-10-23 07:07:00

I've been working with support on case 111621 and they wanted me to load 4.1.78-4. I went to do this via tftp and it would not let me. It would not write the file to memory. I rebooted the arc to try again and in the process got this. You have requested to Reboot the system Please confirm the request.(No/Yes):yes Rebooting.... At 10:04:53, Facility "Configurator", Level "INFORMATION":: Received a CFG_SERVICE_CLOSED_MSG message. Administrator Network Service telnetd has been disabled. EXCEPTION 1400 CRASH DUMP: GPRs: R0: 0x00003930 R1: 0x03FFF450 R2: 0x000B5010 R3: 0x00000000 R4: 0x00000000 R5: 0x00000000 R6: 0x00000000 R7: 0x00000000 R8: 0x00003930 R9: 0x03E04CF0 R10: 0x000B7F9C R11: 0x00000000 R12: 0x0006B59C R13: 0x000BD214 R14: 0x00000000 R15: 0x00000000 R16: 0x00000000 R17: 0x00000000 R18: 0x00000000 R19: 0x00000000 R20: 0x00000000 R21: 0x00000000 R22: 0x00000000 R23: 0x00000000 R24: 0x00000000 R25: 0x00000000 R26: 0x00000000 R27: 0x00000000 R28: 0x00000000 R29: 0x00000000 R30: 0x00000000 R31: 0x00000000 SPRs: CR: 0x00000000 XER: 0x00000000 LR: 0xDEADDEAD CTR: 0x00000000 SRR0: 0x0006B6BC SRR1: 0x0000B930 DSISR: 0x00000000 DAR: 0x00000000 DMISS: 0xFF000000 DCMP: 0x8000003C HASH1: 0x00010000 HASH2: 0x0001FFC0 IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 82660 Registers: Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607A0 Call Stack: 0x0006B6BC (Exception return address - SRR0) 0xDEADDEAD EXCEPTION 0700 CRASH DUMP: GPRs: R0: 0x00003930 R1: 0x03DFF768 R2: 0x0007B508 R3: 0x00008000 R4: 0x03DFF930 R5: 0x00010000 R6: 0x03E04CF0 R7: 0x00000002 R8: 0x0000B930 R9: 0x03DFF860 R10: 0x000B7F9C R11: 0x000030E0 R12: 0x03DFF980 R13: 0x03E07800 R14: 0x03DFF920 R15: 0x03DFF920 R16: 0x03DFF928 R17: 0x03DFF928 R18: 0x03DFF930 R19: 0x03DFF930 R20: 0x03DFF938 R21: 0x03DFF938 R22: 0x03DFF940 R23: 0x03DFF940 R24: 0x03DFF948 R25: 0x03DFF948 R26: 0x03DFF950 R27: 0x03DFF950 R28: 0x03DFF958 R29: 0x00000000 R30: 0x00000000 R31: 0x00000000 SPRs: CR: 0x20000000 XER: 0x00000000 LR: 0x03DFF8E0 CTR: 0x00000000 SRR0: 0x03DFF8E0 SRR1: 0x00083930 DSISR: 0x00000000 DAR: 0x00000000 DMISS: 0xFF000000 DCMP: 0x8000003C HASH1: 0x00010000 HASH2: 0x0001FFC0 IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 82660 Registers: Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607A0 Call Stack: 0x03DFF8E0 (Exception return address - SRR0) 0x03DFF8E0 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 0x03DFF8D8 BOOT PROM Version 1.15 (Built on August 23rd, 1997 at 12:24:24) Loading kernel ... OK Initializing timer ... OK After it rebooted I tried upgrading the arc with tcm and when it hit 88% I got these on the console. HiPer>> At 10:29:57, Facility "SBUS", Level "CRITICAL":: BAD-exec_freemsg Double -Free v1=0x019cb858 v2=0x00000104 v3=0x52455f61 Call Stack: 0X0021AFBC 0X0058593C 0X0058B37C 0X004A2D98 0X0058A5E4 0X0058A77C 0X00200964 0X00200228 0X00200078 Thanks -Dale

Subject: (usr-tc) [isp-services] ISP FS:USR Total Control Units revised (fwd)
From: Brian <signal@shreve.net>
Date: 1998-10-23 07:39:18

some here may want this. Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 ---------- Forwarded message ---------- -REVISED- Prices listed below: For Sale: Perfect for Startup and exisiting ISP'S....They are going fast! US Robotics Total Control Units Analog/Digital modem with 60 ports Each Rack includes the chassis and fan Tray. Qty Description USR Part number 1 Net Server Card 001369-00 1 Network Mgmt Card 000978-00 15 Quad V.34 Analog/Digital 000793-04 2 AC PSU 45A Card 15 NIC CARD (Token Ring) 000385-00 1-2 UNITS $3,800 each 2-4 UNITS $3,500 each 5 OR MORE $3,200 each *These chassis do NOT have PRI or PRI T1 cards in them. However we have (3) available for sale separately if you are interested. The above components are in EACH rack. We have 20 complete racks for sale and all components are available separately. Just e-mail your offers in to me. WE WILL CONSIDER AND REPLY TO ALL OFFERS Please e-mail me or call me with any questions you may have regarding this. Thanks, Andrew Andrew Shlensky **************************** PC Global, Incorporated 7010 SW 63rd Avenue South Miami, Florida 33143 USA (305) 667-2111 TEL (305) 667-3636 FAX URL: www.pcglobal.net E-MAIL: pcglobal@gate.net ICQ: 21219089 To unsubscribe, e-mail: isp-services-unsubscribe@ispc.org For additional commands, e-mail: isp-services-help@ispc.org

Subject: Re: (usr-tc) Can someone help? HARC Crash
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-23 08:12:27

It sounds like you need to start over from scratch. I'm going to recommend the same thing I recommended for Jeff with one exception. 1. Flip dips 1&2 on and connect to the console at 115200 using HyPer Terminal. 2. Reseat the card 3. When the card comes up type delete config. Answer yes and let it reboot. When you see "BOOT PROM Version 1.15 (Built on August 23rd, 1997 at 12:24:24)" quickly typ AT{ZF} This will format the flash and prepare your terminal for zmodem transfer protocol. 4. Now go to the top of your terminal and click transfer/send a file browse and click on the file you wish to flash it with. Hopefully this will work for you -----Original Message----- > >I've been working with support on case 111621 and they wanted me to load >4.1.78-4. I went to do this via tftp and it would not let me. It would not >write the file to memory. I rebooted the arc to try again and in the >process got this. > >You have requested to Reboot the system >Please confirm the request.(No/Yes):yes > >Rebooting.... >At 10:04:53, Facility "Configurator", Level "INFORMATION":: Received a >CFG_SERVICE_CLOSED_MSG message. Administrator Network Service telnetd has >been disabled. > > >EXCEPTION 1400 CRASH DUMP: > >GPRs: >R0: 0x00003930 R1: 0x03FFF450 R2: 0x000B5010 R3: 0x00000000 >R4: 0x00000000 R5: 0x00000000 R6: 0x00000000 R7: 0x00000000 >R8: 0x00003930 R9: 0x03E04CF0 R10: 0x000B7F9C R11: 0x00000000 >R12: 0x0006B59C R13: 0x000BD214 R14: 0x00000000 R15: 0x00000000 >R16: 0x00000000 R17: 0x00000000 R18: 0x00000000 R19: 0x00000000 >R20: 0x00000000 R21: 0x00000000 R22: 0x00000000 R23: 0x00000000 >R24: 0x00000000 R25: 0x00000000 R26: 0x00000000 R27: 0x00000000 >R28: 0x00000000 R29: 0x00000000 R30: 0x00000000 R31: 0x00000000 > >SPRs: >CR: 0x00000000 XER: 0x00000000 LR: 0xDEADDEAD CTR: 0x00000000 >SRR0: 0x0006B6BC SRR1: 0x0000B930 DSISR: 0x00000000 DAR: 0x00000000 >DMISS: 0xFF000000 DCMP: 0x8000003C HASH1: 0x00010000 HASH2: 0x0001FFC0 >IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 > >82660 Registers: >Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 >CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607A0 > >Call Stack: > 0x0006B6BC (Exception return address - SRR0) > 0xDEADDEAD > > >EXCEPTION 0700 CRASH DUMP: > >GPRs: >R0: 0x00003930 R1: 0x03DFF768 R2: 0x0007B508 R3: 0x00008000 >R4: 0x03DFF930 R5: 0x00010000 R6: 0x03E04CF0 R7: 0x00000002 >R8: 0x0000B930 R9: 0x03DFF860 R10: 0x000B7F9C R11: 0x000030E0 >R12: 0x03DFF980 R13: 0x03E07800 R14: 0x03DFF920 R15: 0x03DFF920 >R16: 0x03DFF928 R17: 0x03DFF928 R18: 0x03DFF930 R19: 0x03DFF930 >R20: 0x03DFF938 R21: 0x03DFF938 R22: 0x03DFF940 R23: 0x03DFF940 >R24: 0x03DFF948 R25: 0x03DFF948 R26: 0x03DFF950 R27: 0x03DFF950 >R28: 0x03DFF958 R29: 0x00000000 R30: 0x00000000 R31: 0x00000000 > >SPRs: >CR: 0x20000000 XER: 0x00000000 LR: 0x03DFF8E0 CTR: 0x00000000 >SRR0: 0x03DFF8E0 SRR1: 0x00083930 DSISR: 0x00000000 DAR: 0x00000000 >DMISS: 0xFF000000 DCMP: 0x8000003C HASH1: 0x00010000 HASH2: 0x0001FFC0 >IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 > >82660 Registers: >Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 >CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607A0 > >Call Stack: > 0x03DFF8E0 (Exception return address - SRR0) > 0x03DFF8E0 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > >BOOT PROM Version 1.15 (Built on August 23rd, 1997 at 12:24:24) >Loading kernel ... OK >Initializing timer ... OK > > >After it rebooted I tried upgrading the arc with tcm and when it hit 88% I >got these on the console. > > >HiPer>> At 10:29:57, Facility "SBUS", Level "CRITICAL":: BAD-exec_freemsg >Double >-Free v1=0x019cb858 v2=0x00000104 v3=0x52455f61 >Call Stack: >0X0021AFBC >0X0058593C >0X0058B37C >0X004A2D98 >0X0058A5E4 >0X0058A77C >0X00200964 >0X00200228 >0X00200078 > > >Thanks > >-Dale > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiPer "dead air" problem
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-23 08:14:11

I keep seeing this myself. Is there a MR to fix it. -----Original Message----- >I think I got a similar (or the same) problem here. First everything >works fine. After some time there are more LEDs on that are actually >connections on the HiPer DSP. > >How it looks like >- The HiPer ARC shows connection wich are on for days (although the >users > have disconnected long time ago) >- The session monitor shows the same connections on the HiPER DSP > as onlineAnswer(8). But the call duration for those connections > doesn't move, even if you wait for one hours. >- A hangup of those connections in the HiPer ARC just clears the > connections from the "list connections" on the HiPer ARC. But on > the HiPer DSP they still are indicated as active. >- The only thing so far to get rid of the problem is to > reboot the HiPer DSP. >- We are working with HiPer DSP 1.2.5 and HiPer Arc 4.0.30 > >Any ideas ? > > >Mike Andrews wrote: >> >> We're starting to experience the "dead air" problem pretty severely here >> on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call rejection count >> on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. >> All four were rebooted less than 36 hours ago. All the interfaces show >> up/up right now. >> >> Per other people's recommendations here, I just fired an email off to >> Bellsouth to see if they can set their DMS100 to round-robin through the B >> channels instead of first-available. I'm also going to move some PRI's >> back to our spare Quads. The Quake players will just have to deal with >> it for a little while. :-) >> >> Once a card gets into this state, has anyone found any way to get those >> channels to behave themselves again, OTHER than busying out and then >> rebooting the whole DSP card? >> >> Also, when I went to reboot yesterday, the 4th DSP had several LEDs lit on >> its usage meter, despite the ARC showing no calls on that span. (I didn't >> check to see if the interfaces were up/up then, or what the reject count >> was.) Right now, it's showing 4 LED's, the reject count is 0, all >> interfaces are up, ATI6 on each modem shows several giving "current call" >> instead of "last call" times... yet the ARC shows only 1 active session. >> Hmm. Different problem? >> >> Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org >> VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net >> Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ >> If Milli Vanilli fell in the forest, would someone else make the sound? >> >> - >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >> with "unsubscribe usr-tc" in the body of the message. >> For information on digests or retrieving files and old messages send >> "help" to the same address. Do not use quotes in your message. > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) On demand analog dialout
From: Andres Kroonmaa <andre@ml.ee>
Date: 1998-10-23 08:53:53

On 22 Oct 98, at 16:21, Jeff Mcadams <usr-tc@lists.xmission.com> wrote: > >1. Can we set something up on the HiPer ARC so that an outbound call is = > >initiated only when the default route in the ip route table points to a = > >gateway that is no longer reachable? > > Might look at picking up your default route from RIPv2, that way, if the > link goes down, so does the RIPv2 advertisements and therefore your > default route. The question then is, how do you get the HARC to > dial-on-demand when there's no default route in place. That might be > easier to work out. How about using static defaulroute with an owful metric? Then local RIPv2 should override it when available. And dialback should become the best path when rip stops advertising ethernet default. (not tested myself and wouldn't be surprised if it doesn't work as expected) ---------------------------------------------------------------------- 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 ----------------------------------------------------------------------

Subject: RE: (usr-tc) HiPer "dead air" problem
From: Terry Kennedy <terry@olypen.com>
Date: 1998-10-23 09:19:44

John, I would like to get a hold of 1.2.68 please let me know where I can pick it up. Terry terry@olypen.com > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dale Hege > Sent: Friday, October 23, 1998 9:14 AM > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HiPer "dead air" problem > > > Is this comming out soon? > > -Dale > > On Fri, 23 Oct 1998, John Powell wrote: > > > Date: Fri, 23 Oct 1998 10:42:27 -0500 > > From: John Powell <John_Powell@mw.3com.com> > > Reply-To: usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > > Subject: Re: (usr-tc) HiPer "dead air" problem > > > > > > This is somewhat of a rare problem, but we do have a fix for > it. We will > > be wrapping that into a Service Release along with any V.90 > problems that > > we can resolve on our end. If you want the specific > Engineering Release to > > resolve the dead-air (or occasionally 'wierd tones' being transmitted on > > answer), drop me an email and I will send it to you. ER is 1.2.68. > > > > JP > > > > > > > > > > > > Ralph Helfenberger <rhelfenberger@comlight.ch> on 10/23/98 05:02:54 AM > > > > Please respond to usr-tc@lists.xmission.com > > > > To: usr-tc@lists.xmission.com > > cc: (John Powell/MW/US/3Com) > > Subject: Re: (usr-tc) HiPer "dead air" problem > > > > > > > > > > I think I got a similar (or the same) problem here. First everything > > works fine. After some time there are more LEDs on that are actually > > connections on the HiPer DSP. > > > > How it looks like > > - The HiPer ARC shows connection wich are on for days (although the > > users > > have disconnected long time ago) > > - The session monitor shows the same connections on the HiPER DSP > > as onlineAnswer(8). But the call duration for those connections > > doesn't move, even if you wait for one hours. > > - A hangup of those connections in the HiPer ARC just clears the > > connections from the "list connections" on the HiPer ARC. But on > > the HiPer DSP they still are indicated as active. > > - The only thing so far to get rid of the problem is to > > reboot the HiPer DSP. > > - We are working with HiPer DSP 1.2.5 and HiPer Arc 4.0.30 > > > > Any ideas ? > > > > > > Mike Andrews wrote: > > > > > > We're starting to experience the "dead air" problem pretty > severely here > > > on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call > rejection count > > > on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. > > > All four were rebooted less than 36 hours ago. All the > interfaces show > > > up/up right now. > > > > > > Per other people's recommendations here, I just fired an email off to > > > Bellsouth to see if they can set their DMS100 to round-robin > through the > > B > > > channels instead of first-available. I'm also going to move > some PRI's > > > back to our spare Quads. The Quake players will just have to > deal with > > > it for a little while. :-) > > > > > > Once a card gets into this state, has anyone found any way to > get those > > > channels to behave themselves again, OTHER than busying out and then > > > rebooting the whole DSP card? > > > > > > Also, when I went to reboot yesterday, the 4th DSP had > several LEDs lit > > on > > > its usage meter, despite the ARC showing no calls on that span. (I > > didn't > > > check to see if the interfaces were up/up then, or what the > reject count > > > was.) Right now, it's showing 4 LED's, the reject count is 0, all > > > interfaces are up, ATI6 on each modem shows several giving > "current call" > > > instead of "last call" times... yet the ARC shows only 1 > active session. > > > Hmm. Different problem? > > > > > > Mike Andrews (MA12) icq 6602506 -------------- > mandrews@termfrost.org > > > VP 'n' Systems/Network Administrator --------------- > mandrews@dcr.net > > > Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ > > If Milli Vanilli fell in the forest, would someone else make the sound? > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-23 09:29:55

You will get this in the accounting packet. 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, 22 Oct 1998, Dan Hollis wrote: > How do i get a hiperarc to send the user's connect speed in the radius > request packet? > > Right now, all I get is: > > User-Name = "someluser" > Password = "[somecrap]" > Client-Id = hiperarc.ip.address > NAS-Port = 8 > USR-Interface-Index = 1264 > User-Service-Type = 2 > Framed-Protocol = PPP > USR-Chassis-Call-Slot = 1 > USR-Chassis-Call-Span = 1 > USR-Chassis-Call-Channel = 8 > Client-Port-DNIS = "luser's-dnis" > Caller-ID = "luser's-ani" > NAS-Port-Type = Async > > It would be nice at the very least to get the Modulation-Type (v90, x2, > etc), so I can reject x2/v90 users who havent paid for that service. > > -Dan > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Can someone help? HARC Crash
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-23 10:09:40

Dale, What is your phone number? I will need to talk to you and have someone work this issue. regards krish > ---------- Forwarded message ---------- > Date: Fri, 23 Oct 1998 07:07:00 -0400 (EDT) > From: Dale Hege <fhege@sover.net> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Can someone help? HARC Crash > > > I've been working with support on case 111621 and they wanted me to load > 4.1.78-4. I went to do this via tftp and it would not let me. It would not > write the file to memory. I rebooted the arc to try again and in the > process got this. > > You have requested to Reboot the system > Please confirm the request.(No/Yes):yes > > Rebooting.... > At 10:04:53, Facility "Configurator", Level "INFORMATION":: Received a > CFG_SERVICE_CLOSED_MSG message. Administrator Network Service telnetd has > been disabled. > > > EXCEPTION 1400 CRASH DUMP: > > GPRs: > R0: 0x00003930 R1: 0x03FFF450 R2: 0x000B5010 R3: 0x00000000 > R4: 0x00000000 R5: 0x00000000 R6: 0x00000000 R7: 0x00000000 > R8: 0x00003930 R9: 0x03E04CF0 R10: 0x000B7F9C R11: 0x00000000 > R12: 0x0006B59C R13: 0x000BD214 R14: 0x00000000 R15: 0x00000000 > R16: 0x00000000 R17: 0x00000000 R18: 0x00000000 R19: 0x00000000 > R20: 0x00000000 R21: 0x00000000 R22: 0x00000000 R23: 0x00000000 > R24: 0x00000000 R25: 0x00000000 R26: 0x00000000 R27: 0x00000000 > R28: 0x00000000 R29: 0x00000000 R30: 0x00000000 R31: 0x00000000 > > SPRs: > CR: 0x00000000 XER: 0x00000000 LR: 0xDEADDEAD CTR: 0x00000000 > SRR0: 0x0006B6BC SRR1: 0x0000B930 DSISR: 0x00000000 DAR: 0x00000000 > DMISS: 0xFF000000 DCMP: 0x8000003C HASH1: 0x00010000 HASH2: 0x0001FFC0 > IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 > > 82660 Registers: > Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 > CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607A0 > > Call Stack: > 0x0006B6BC (Exception return address - SRR0) > 0xDEADDEAD > > > EXCEPTION 0700 CRASH DUMP: > > GPRs: > R0: 0x00003930 R1: 0x03DFF768 R2: 0x0007B508 R3: 0x00008000 > R4: 0x03DFF930 R5: 0x00010000 R6: 0x03E04CF0 R7: 0x00000002 > R8: 0x0000B930 R9: 0x03DFF860 R10: 0x000B7F9C R11: 0x000030E0 > R12: 0x03DFF980 R13: 0x03E07800 R14: 0x03DFF920 R15: 0x03DFF920 > R16: 0x03DFF928 R17: 0x03DFF928 R18: 0x03DFF930 R19: 0x03DFF930 > R20: 0x03DFF938 R21: 0x03DFF938 R22: 0x03DFF940 R23: 0x03DFF940 > R24: 0x03DFF948 R25: 0x03DFF948 R26: 0x03DFF950 R27: 0x03DFF950 > R28: 0x03DFF958 R29: 0x00000000 R30: 0x00000000 R31: 0x00000000 > > SPRs: > CR: 0x20000000 XER: 0x00000000 LR: 0x03DFF8E0 CTR: 0x00000000 > SRR0: 0x03DFF8E0 SRR1: 0x00083930 DSISR: 0x00000000 DAR: 0x00000000 > DMISS: 0xFF000000 DCMP: 0x8000003C HASH1: 0x00010000 HASH2: 0x0001FFC0 > IMISS: 0x00000000 ICMP: 0x00000000 RPA: 0x00000000 IABR: 0x00000000 > > 82660 Registers: > Err Status 1: 0x00, Err Status 2: 0x00, CPU Err: 0x14, PCI Err: 0x06 > CPU/PCI Addr: 0x00050CC0, Sys Error Addr: 0x000607A0 > > Call Stack: > 0x03DFF8E0 (Exception return address - SRR0) > 0x03DFF8E0 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > 0x03DFF8D8 > > BOOT PROM Version 1.15 (Built on August 23rd, 1997 at 12:24:24) > Loading kernel ... OK > Initializing timer ... OK > > > After it rebooted I tried upgrading the arc with tcm and when it hit 88% I > got these on the console. > > > HiPer>> At 10:29:57, Facility "SBUS", Level "CRITICAL":: BAD-exec_freemsg > Double > -Free v1=0x019cb858 v2=0x00000104 v3=0x52455f61 > Call Stack: > 0X0021AFBC > 0X0058593C > 0X0058B37C > 0X004A2D98 > 0X0058A5E4 > 0X0058A77C > 0X00200964 > 0X00200228 > 0X00200078 > > > Thanks > > -Dale > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Dead Process
From: Terry Kennedy <terry@olypen.com>
Date: 1998-10-23 10:22:47

"li ses" shows: root LAN UNKNOWN root LAN UNKNOWN I assume these are telnet sesions that closed improperly. I can get the process ( I assuming these to be one and the same ) numbers using "li proc" 272001 CLI 272001 Application Inactive 282070 CLI 282070 Application Inactive 29200f CLI 29200f Application Inactive 2a206f CLI 2a206f Application Inactive Assuming again that the "kill" command would the way to rid the sesion list of these what's the proper syntax. Made a lot ASSUMTIONS - How many are wrong? Any idea.. Thanks Terry Kennedy OlyPen, Inc.

Subject: Re: (usr-tc) HiPer "dead air" problem
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-23 10:42:27

This is somewhat of a rare problem, but we do have a fix for it. We will be wrapping that into a Service Release along with any V.90 problems that we can resolve on our end. If you want the specific Engineering Release to resolve the dead-air (or occasionally 'wierd tones' being transmitted on answer), drop me an email and I will send it to you. ER is 1.2.68. JP Ralph Helfenberger <rhelfenberger@comlight.ch> on 10/23/98 05:02:54 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) I think I got a similar (or the same) problem here. First everything works fine. After some time there are more LEDs on that are actually connections on the HiPer DSP. How it looks like - The HiPer ARC shows connection wich are on for days (although the users have disconnected long time ago) - The session monitor shows the same connections on the HiPER DSP as onlineAnswer(8). But the call duration for those connections doesn't move, even if you wait for one hours. - A hangup of those connections in the HiPer ARC just clears the connections from the "list connections" on the HiPer ARC. But on the HiPer DSP they still are indicated as active. - The only thing so far to get rid of the problem is to reboot the HiPer DSP. - We are working with HiPer DSP 1.2.5 and HiPer Arc 4.0.30 Any ideas ? Mike Andrews wrote: > > We're starting to experience the "dead air" problem pretty severely here > on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call rejection count > on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. > All four were rebooted less than 36 hours ago. All the interfaces show > up/up right now. > > Per other people's recommendations here, I just fired an email off to > Bellsouth to see if they can set their DMS100 to round-robin through the B > channels instead of first-available. I'm also going to move some PRI's > back to our spare Quads. The Quake players will just have to deal with > it for a little while. :-) > > Once a card gets into this state, has anyone found any way to get those > channels to behave themselves again, OTHER than busying out and then > rebooting the whole DSP card? > > Also, when I went to reboot yesterday, the 4th DSP had several LEDs lit on > its usage meter, despite the ARC showing no calls on that span. (I didn't > check to see if the interfaces were up/up then, or what the reject count > was.) Right now, it's showing 4 LED's, the reject count is 0, all > interfaces are up, ATI6 on each modem shows several giving "current call" > instead of "last call" times... yet the ARC shows only 1 active session. > Hmm. Different problem? > > Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org > VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net > Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ > If Milli Vanilli fell in the forest, would someone else make the sound? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-10-23 11:08:44

Why isnt it in the authentication request packet? Do you see why having it in the accounting packet is not useful for rejecting calls? This means im going to have to modify our radius server to do SNMP queries for every authentication request, which is going to suck bad. :-/ -Dan On Fri, 23 Oct 1998, Tatai SV Krishnan wrote: > You will get this in the accounting packet. > > 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, 22 Oct 1998, Dan Hollis wrote: > > > How do i get a hiperarc to send the user's connect speed in the radius > > request packet? > > > > Right now, all I get is: > > > > User-Name = "someluser" > > Password = "[somecrap]" > > Client-Id = hiperarc.ip.address > > NAS-Port = 8 > > USR-Interface-Index = 1264 > > User-Service-Type = 2 > > Framed-Protocol = PPP > > USR-Chassis-Call-Slot = 1 > > USR-Chassis-Call-Span = 1 > > USR-Chassis-Call-Channel = 8 > > Client-Port-DNIS = "luser's-dnis" > > Caller-ID = "luser's-ani" > > NAS-Port-Type = Async > > > > It would be nice at the very least to get the Modulation-Type (v90, x2, > > etc), so I can reject x2/v90 users who havent paid for that service. > > > > -Dan > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > >

Subject: Re: (usr-tc) 3COM Unknown NAC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-23 11:11:48

You may have a management bus issue. You could replace the chassis out right or call 3COM tech support and request them to run debug on the management bus. Krish or Mike may have a better suggestion. -----Original Message----- >All, > >We have a chassis containing three high density modems, a HiperARC, >and an NMC. > >This chassis has been plagued with problems but there has been one >consistant anomaly: The 10th slot believes there is a ``3COM >Unknown NAC'' inserted into it. Of course there isn't anything in >that slot at all (at least nothing I can see). I was wondering if >this is indicative of a problem with the chassis and if such a >problem could cause others. For example, the NMC doesn't consistanly >``see'' all of the other devices in the chassis. Thats just one >problem I've seen among a many. The main question is can this >phantom NAC be the cause of the other problems. > > >Ayan George >Internet Engineer @ DSS Online >http://www.datasys.net/ > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) 3COM Unknown NAC
From: Ayan George <ayan@kiwi.datasys.net>
Date: 1998-10-23 11:54:29

All, We have a chassis containing three high density modems, a HiperARC, and an NMC. This chassis has been plagued with problems but there has been one consistant anomaly: The 10th slot believes there is a ``3COM Unknown NAC'' inserted into it. Of course there isn't anything in that slot at all (at least nothing I can see). I was wondering if this is indicative of a problem with the chassis and if such a problem could cause others. For example, the NMC doesn't consistanly ``see'' all of the other devices in the chassis. Thats just one problem I've seen among a many. The main question is can this phantom NAC be the cause of the other problems. Ayan George Internet Engineer @ DSS Online http://www.datasys.net/

Subject: Re: (usr-tc) 3COM Unknown NAC
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-23 11:59:29

-----Original Message----- >Also, at times, one of the HDMs do not appear when I issue a ``list >modem_groups'' command to the HiperARC. It will appear after I >perform a hardware reset on that slot. > ><shurg> > >In other words, it looks like it might be more than the management >bus that is effected. I guess I should try moving the HDMs to >another chassis just to be sure. Incorrect. Unless you have NMC chassis awareness disabled. The NMC, with information obtained from it's management bus, tells the HiPer ARC what interfaces should be set up and if they are up or down If this is the cause you could do the following to try to work around the problem: telnet to your hiper ARC disable nmc CHASSIS_AWARENESS save all reboot telnet back to the hiper arc and do something like the following: set chassIS SLOT 14 card_type hdm ports 23 owner yes for pri or set chassIS SLOT 14 card_type hdm ports 24 owner yes for t1 save all and of course, if in doubt, reboot The nmc will no longer be responsible for interface mapping > >-Ayan > >On Fri, Oct 23, 1998, "Brian K McIntire" wrote: > >> You may have a management bus issue. You could replace the chassis out >> right or call 3COM tech support and request them to run debug on the >> management bus. Krish or Mike may have a better suggestion. >[snip!] > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiPer "dead air" problem
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-10-23 12:02:54

I think I got a similar (or the same) problem here. First everything works fine. After some time there are more LEDs on that are actually connections on the HiPer DSP. How it looks like - The HiPer ARC shows connection wich are on for days (although the users have disconnected long time ago) - The session monitor shows the same connections on the HiPER DSP as onlineAnswer(8). But the call duration for those connections doesn't move, even if you wait for one hours. - A hangup of those connections in the HiPer ARC just clears the connections from the "list connections" on the HiPer ARC. But on the HiPer DSP they still are indicated as active. - The only thing so far to get rid of the problem is to reboot the HiPer DSP. - We are working with HiPer DSP 1.2.5 and HiPer Arc 4.0.30 Any ideas ? Mike Andrews wrote: > > We're starting to experience the "dead air" problem pretty severely here > on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call rejection count > on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. > All four were rebooted less than 36 hours ago. All the interfaces show > up/up right now. > > Per other people's recommendations here, I just fired an email off to > Bellsouth to see if they can set their DMS100 to round-robin through the B > channels instead of first-available. I'm also going to move some PRI's > back to our spare Quads. The Quake players will just have to deal with > it for a little while. :-) > > Once a card gets into this state, has anyone found any way to get those > channels to behave themselves again, OTHER than busying out and then > rebooting the whole DSP card? > > Also, when I went to reboot yesterday, the 4th DSP had several LEDs lit on > its usage meter, despite the ARC showing no calls on that span. (I didn't > check to see if the interfaces were up/up then, or what the reject count > was.) Right now, it's showing 4 LED's, the reject count is 0, all > interfaces are up, ATI6 on each modem shows several giving "current call" > instead of "last call" times... yet the ARC shows only 1 active session. > Hmm. Different problem? > > Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org > VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net > Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ > If Milli Vanilli fell in the forest, would someone else make the sound? > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) HiPer "dead air" problem
From: Dale Hege <fhege@sover.net>
Date: 1998-10-23 12:14:25

Is this comming out soon? -Dale On Fri, 23 Oct 1998, John Powell wrote: > Date: Fri, 23 Oct 1998 10:42:27 -0500 > From: John Powell <John_Powell@mw.3com.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HiPer "dead air" problem > > > This is somewhat of a rare problem, but we do have a fix for it. We will > be wrapping that into a Service Release along with any V.90 problems that > we can resolve on our end. If you want the specific Engineering Release to > resolve the dead-air (or occasionally 'wierd tones' being transmitted on > answer), drop me an email and I will send it to you. ER is 1.2.68. > > JP > > > > > > Ralph Helfenberger <rhelfenberger@comlight.ch> on 10/23/98 05:02:54 AM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (John Powell/MW/US/3Com) > Subject: Re: (usr-tc) HiPer "dead air" problem > > > > > I think I got a similar (or the same) problem here. First everything > works fine. After some time there are more LEDs on that are actually > connections on the HiPer DSP. > > How it looks like > - The HiPer ARC shows connection wich are on for days (although the > users > have disconnected long time ago) > - The session monitor shows the same connections on the HiPER DSP > as onlineAnswer(8). But the call duration for those connections > doesn't move, even if you wait for one hours. > - A hangup of those connections in the HiPer ARC just clears the > connections from the "list connections" on the HiPer ARC. But on > the HiPer DSP they still are indicated as active. > - The only thing so far to get rid of the problem is to > reboot the HiPer DSP. > - We are working with HiPer DSP 1.2.5 and HiPer Arc 4.0.30 > > Any ideas ? > > > Mike Andrews wrote: > > > > We're starting to experience the "dead air" problem pretty severely here > > on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call rejection count > > on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. > > All four were rebooted less than 36 hours ago. All the interfaces show > > up/up right now. > > > > Per other people's recommendations here, I just fired an email off to > > Bellsouth to see if they can set their DMS100 to round-robin through the > B > > channels instead of first-available. I'm also going to move some PRI's > > back to our spare Quads. The Quake players will just have to deal with > > it for a little while. :-) > > > > Once a card gets into this state, has anyone found any way to get those > > channels to behave themselves again, OTHER than busying out and then > > rebooting the whole DSP card? > > > > Also, when I went to reboot yesterday, the 4th DSP had several LEDs lit > on > > its usage meter, despite the ARC showing no calls on that span. (I > didn't > > check to see if the interfaces were up/up then, or what the reject count > > was.) Right now, it's showing 4 LED's, the reject count is 0, all > > interfaces are up, ATI6 on each modem shows several giving "current call" > > instead of "last call" times... yet the ARC shows only 1 active session. > > Hmm. Different problem? > > > > Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org > > VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net > > Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ > > If Milli Vanilli fell in the forest, would someone else make the sound? > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) HiPer "dead air" problem
From: John Powell <john_powell@mw.3com.com>
Date: 1998-10-23 12:21:50

Sure hope so. We are testing some of the fixes now, and hope to get a build out to at least our beta sites in the next week or two to see how well we have done. I might note that the most improvements we have seen are with the latest V.90 on the client side. The latest Lucent and Rockwell codes have had a huge impact (they fixed alot of their own problems). We have one problem on our side, and some patches to try to workaround some of the client problems that we want to get in this Service release, along with dead-air/wierdtone problems and some others that have been fixed in previous ERs. JP ---------------------- Forwarded by John Powell/MW/US/3Com on 10/23/98 12:12 PM --------------------------- Dale Hege <fhege@sover.net> on 10/23/98 11:14:25 AM Please respond to usr-tc@lists.xmission.com cc: (John Powell/MW/US/3Com) Is this comming out soon? -Dale On Fri, 23 Oct 1998, John Powell wrote: > Date: Fri, 23 Oct 1998 10:42:27 -0500 > From: John Powell <John_Powell@mw.3com.com> > Reply-To: usr-tc@lists.xmission.com > To: usr-tc@lists.xmission.com > Subject: Re: (usr-tc) HiPer "dead air" problem > > > This is somewhat of a rare problem, but we do have a fix for it. We will > be wrapping that into a Service Release along with any V.90 problems that > we can resolve on our end. If you want the specific Engineering Release to > resolve the dead-air (or occasionally 'wierd tones' being transmitted on > answer), drop me an email and I will send it to you. ER is 1.2.68. > > JP > > > > > > Ralph Helfenberger <rhelfenberger@comlight.ch> on 10/23/98 05:02:54 AM > > Please respond to usr-tc@lists.xmission.com > > To: usr-tc@lists.xmission.com > cc: (John Powell/MW/US/3Com) > Subject: Re: (usr-tc) HiPer "dead air" problem > > > > > I think I got a similar (or the same) problem here. First everything > works fine. After some time there are more LEDs on that are actually > connections on the HiPer DSP. > > How it looks like > - The HiPer ARC shows connection wich are on for days (although the > users > have disconnected long time ago) > - The session monitor shows the same connections on the HiPER DSP > as onlineAnswer(8). But the call duration for those connections > doesn't move, even if you wait for one hours. > - A hangup of those connections in the HiPer ARC just clears the > connections from the "list connections" on the HiPer ARC. But on > the HiPer DSP they still are indicated as active. > - The only thing so far to get rid of the problem is to > reboot the HiPer DSP. > - We are working with HiPer DSP 1.2.5 and HiPer Arc 4.0.30 > > Any ideas ? > > > Mike Andrews wrote: > > > > We're starting to experience the "dead air" problem pretty severely here > > on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call rejection count > > on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. > > All four were rebooted less than 36 hours ago. All the interfaces show > > up/up right now. > > > > Per other people's recommendations here, I just fired an email off to > > Bellsouth to see if they can set their DMS100 to round-robin through the > B > > channels instead of first-available. I'm also going to move some PRI's > > back to our spare Quads. The Quake players will just have to deal with > > it for a little while. :-) > > > > Once a card gets into this state, has anyone found any way to get those > > channels to behave themselves again, OTHER than busying out and then > > rebooting the whole DSP card? > > > > Also, when I went to reboot yesterday, the 4th DSP had several LEDs lit > on > > its usage meter, despite the ARC showing no calls on that span. (I > didn't > > check to see if the interfaces were up/up then, or what the reject count > > was.) Right now, it's showing 4 LED's, the reject count is 0, all > > interfaces are up, ATI6 on each modem shows several giving "current call" > > instead of "last call" times... yet the ARC shows only 1 active session. > > Hmm. Different problem? > > > > Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org > > VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net > > Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ > > If Milli Vanilli fell in the forest, would someone else make the sound? > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) 3COM Unknown NAC
From: Ayan George <ayan@kiwi.datasys.net>
Date: 1998-10-23 12:27:40

Also, at times, one of the HDMs do not appear when I issue a ``list modem_groups'' command to the HiperARC. It will appear after I perform a hardware reset on that slot. <shurg> In other words, it looks like it might be more than the management bus that is effected. I guess I should try moving the HDMs to another chassis just to be sure. -Ayan On Fri, Oct 23, 1998, "Brian K McIntire" wrote: > You may have a management bus issue. You could replace the chassis out > right or call 3COM tech support and request them to run debug on the > management bus. Krish or Mike may have a better suggestion. [snip!]

Subject: RE: (usr-tc) pmwho?
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-10-23 12:59:35

On Thursday, October 22, 1998 6:32 PM, Charles Sprickman [SMTP:spork@inch.com] wrote: > I'm testing from one machine, and pmwho times out on some of the > netservers, and not others. They are all running 3.7.73, and are all > reachable by "manually" telnet-ing to each of them. The default pw is the > same on all, as is the telnet port. When debugging this on some of my own boxes it was useful to run strace on the process so I could see exactly what was going on behind the scenes. You should have strace available if you're running pmwho on a linux box. If it's a solaris box, the truss program acomplishes the same feat. if you're using csh: strace pmwho host |& less or sh: strace pmwho host 2>&1 |less Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 A quart of wheat for a day's wages, and three quarts of barley for a day's wages, and do not damage the oil and the wine! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-10-23 13:03:46

On Fri, 23 Oct 1998, Tatai SV Krishnan wrote: > On Fri, 23 Oct 1998, Dan Hollis wrote: > > Why isnt it in the authentication request packet? > What are you going to do? Are you going to run your radius in debug mode > to see the connect speed? No, im going to modify radius to reject eg v90 calls *at login* for customers who havent paid for v90. Eg. Radius authentication packet with v90 VSA arrives at the radius server. Radius server determines whether user is allowed v90 dialup. If yes, send radius ACK. If no, send radius NAK. Right now, the HiperARC doesnt send enough information in the authentication packet to determine what kind of call is coming in _before_ its been authenticated and logged in. > > Do you see why having it in the accounting packet is not useful for > > rejecting calls? > Do you know that we also send a packet with username unauthenticated if > the user drops after connecting to the accounting server with the speed > in it? Eh? > > This means im going to have to modify our radius server to do SNMP queries > > for every authentication request, which is going to suck bad. :-/ > No this means you have authentication packets also sent to your radius > server. But I want to **reject** certain v90 calls *before* theyre authenticated, not *after* theyre logged in. -Dan

Subject: Re: (usr-tc) 3COM Unknown NAC (and more)
From: Ayan George <ayan@kiwi.datasys.net>
Date: 1998-10-23 13:08:35

Thanks. I'll give that a try. One more thing: There are a couple of HDMs that do not free a channel as soon as the call is terminated. The call could be another modem that completed a handshake and PPP session or I could just call, wait for the modem to answer, and hang up -- either way, the modem will stay in use for about a minute. Any ideas? On Fri, Oct 23, 1998, "Brian K McIntire" wrote: > Incorrect. Unless you have NMC chassis awareness disabled. The NMC, with > information obtained from it's management bus, tells the HiPer ARC what > interfaces should be set up and if they are up or down > > If this is the cause you could do the following to try to work around the > problem: > telnet to your hiper ARC > disable nmc CHASSIS_AWARENESS > save all > reboot > telnet back to the hiper arc and do something like the following: > set chassIS SLOT 14 card_type hdm ports 23 owner yes for pri > or > set chassIS SLOT 14 card_type hdm ports 24 owner yes for t1 > save all > and of course, if in doubt, reboot > The nmc will no longer be responsible for interface mapping >

Subject: (usr-tc) Hiper ARC RADIUS question
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-23 14:15:35

This is a multi-part message in MIME format. ------=_NextPart_000_00B9_01BDFE8F.9A56CC40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have a customer who wants to be able to setup a HiPer ARC to = authenticate users to two different RADIUS servers. Not a primary & = secondary setup but an either/or setup. In other words if the name is = not found on one RADIUS he wants the HiPer ARC to direct the = authentication request to the other. Is this possible? I know it = sounds like a strange thing to want to do but trust me there is a reason = for it. Any help is appreciated. ------=_NextPart_000_00B9_01BDFE8F.9A56CC40 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 5.00.0518.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT size=3D2>I have a customer who wants to be able to setup a = HiPer ARC to=20 authenticate users to two different RADIUS servers.  Not a primary = &=20 secondary setup but an either/or setup.  In other words if the name = is not=20 found on one RADIUS he wants the HiPer ARC to direct the authentication = request=20 to the other.  Is this possible?  I know it sounds like a = strange=20 thing to want to do but trust me there is a reason for it.</FONT></DIV> <DIV><FONT size=3D2>Any help is appreciated.</FONT></DIV> </BODY></HTML> ------=_NextPart_000_00B9_01BDFE8F.9A56CC40--

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-23 14:53:45

On Fri, 23 Oct 1998, Dan Hollis wrote: > Why isnt it in the authentication request packet? What are you going to do? Are you going to run your radius in debug mode to see the connect speed? > > Do you see why having it in the accounting packet is not useful for > rejecting calls? > Do you know that we also send a packet with username unauthenticated if the user drops after connecting to the accounting server with the speed in it? > This means im going to have to modify our radius server to do SNMP queries > for every authentication request, which is going to suck bad. :-/ > No this means you have authentication packets also sent to your radius server. krish > -Dan > > On Fri, 23 Oct 1998, Tatai SV Krishnan wrote: > > You will get this in the accounting packet. > > > > 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, 22 Oct 1998, Dan Hollis wrote: > > > > > How do i get a hiperarc to send the user's connect speed in the radius > > > request packet? > > > > > > Right now, all I get is: > > > > > > User-Name = "someluser" > > > Password = "[somecrap]" > > > Client-Id = hiperarc.ip.address > > > NAS-Port = 8 > > > USR-Interface-Index = 1264 > > > User-Service-Type = 2 > > > Framed-Protocol = PPP > > > USR-Chassis-Call-Slot = 1 > > > USR-Chassis-Call-Span = 1 > > > USR-Chassis-Call-Channel = 8 > > > Client-Port-DNIS = "luser's-dnis" > > > Caller-ID = "luser's-ani" > > > NAS-Port-Type = Async > > > > > > It would be nice at the very least to get the Modulation-Type (v90, x2, > > > etc), so I can reject x2/v90 users who havent paid for that service. > > > > > > -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. > > > > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Hiper ARC RADIUS question
From: John T. Farmer <jfarmer@goldsword.com>
Date: 1998-10-23 15:57:49

First, *Please* turn off the html & mime to the list. Thank You. Now, to do what _I think_ you want done, your client should be looking at setting up one of the Radius servers (the primary) as a "proxy" radius server with the second server behind it. This of course, means that the primary server will be queried first, then if not found, the query is sent to the next server. You can get quite creative with it, look at the various Radius oriented mailing lists for more info (one is at isp-radius.com) John John T. Farmer Proprietor, GoldSword Systems jfarmer@goldsword.com Public Internet Access in East Tennessee Office: (423)691-6498 for info, e-mail to info@goldsword.com Network Design, Internet Services & Servers, Consulting

Subject: (usr-tc) modem connect issue
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-23 16:09:40

This is a multi-part message in MIME format. ------=_NextPart_000_00FB_01BDFE9F.8A54A460 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Anyone ever heard of a desktop modem with the following model # mdp7800 I'm dealing with an issue with a customer that has no idea who made the = modem so I can't go out and look to see if there are any known issues=20 ------=_NextPart_000_00FB_01BDFE9F.8A54A460 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 5.00.0518.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Anyone ever heard of a desktop modem = with the=20 following model # mdp7800</FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT><FONT color=3D#000000 = size=3D2>I'm dealing=20 with an issue with a customer that has no idea who made the modem so I = can't go=20 out and look to see if there are any known issues</FONT><FONT = color=3D#000000=20 size=3D2> </FONT></DIV> <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV> </BODY></HTML> ------=_NextPart_000_00FB_01BDFE9F.8A54A460--

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-23 16:37:25

On Fri, 23 Oct 1998, Dan Hollis wrote: > On Fri, 23 Oct 1998, Tatai SV Krishnan wrote: > > On Fri, 23 Oct 1998, Dan Hollis wrote: > > > Why isnt it in the authentication request packet? > > What are you going to do? Are you going to run your radius in debug mode > > to see the connect speed? > > No, im going to modify radius to reject eg v90 calls *at login* for > customers who havent paid for v90. > > Eg. > > Radius authentication packet with v90 VSA arrives at the radius server. > Radius server determines whether user is allowed v90 dialup. > If yes, send radius ACK. > If no, send radius NAK. After a call connects the modem sends the connect rate and other info to the HiPer arc and the Hiper arc sends this information on the in the accounting packet. This is how it is implemented. If you want this changed we can have a CRA created and a feature request put in. > > Right now, the HiperARC doesnt send enough information in the > authentication packet to determine what kind of call is coming in _before_ > its been authenticated and logged in. > > > > Do you see why having it in the accounting packet is not useful for > > > rejecting calls? > > Do you know that we also send a packet with username unauthenticated if > > the user drops after connecting to the accounting server with the speed > > in it? > > Eh? > > > > This means im going to have to modify our radius server to do SNMP queries > > > for every authentication request, which is going to suck bad. :-/ > > No this means you have authentication packets also sent to your radius > > server. > > But I want to **reject** certain v90 calls *before* theyre authenticated, > not *after* theyre logged in. Certainly we can included it - There is nothing in the rfc or anywhere that says we should not send it. Again this would be a feature request and you can certainly have it - for the HiPer arc knows that speed when it sent the request. I would suggest that you get your sales rep on line and ask him for a CRA - Feature request. krish > > -Dan >

Subject: RE: (usr-tc) pmwho?
From: Brian Uechi <brianu@lava.net>
Date: 1998-10-23 16:57:26

pmwho looks for a '>' to indicate the netserver is at a command prompt. When there are multi-link PPP connections on the netserver the "show sess" command will include the '>' character which confuses pmwho. It's an easy fix in the source. On Fri, 23 Oct 1998, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: > On Thursday, October 22, 1998 6:32 PM, Charles Sprickman > [SMTP:spork@inch.com] wrote: > > > I'm testing from one machine, and pmwho times out on some of the > > netservers, and not others. They are all running 3.7.73, and are all > > reachable by "manually" telnet-ing to each of them. The default pw is the > > same on all, as is the telnet port. > > When debugging this on some of my own boxes it was useful to run strace on > the process so I could see exactly what was going on behind the scenes. You > should have strace available if you're running pmwho on a linux box. If > it's a solaris box, the truss program acomplishes the same feat. > > if you're using csh: > strace pmwho host |& less > > or sh: > strace pmwho host 2>&1 |less > > Be Seeing You...

Subject: (usr-tc) Login Message
From: Brian Biggs <bb@sonic.net>
Date: 1998-10-23 17:00:22

Hello, How do I get rid of this message via CLI (offending message prefaced with '>' marks): CONNECT 64000/ARQ/DIGITAL/V120 >Welcome to 3Com Total Control HiPer ARC (TM) >Networks That Go The Distance (TM) sonic (nas21) login: Thanks! -Brian -- # Brian Biggs | Sonic / Sonoma Interconnect # # Sys Admin / Programmer | v707.522.1000 fax707.547.2199 d707.522.1001 # # mailto:bb@sonic.net | http://www.sonic.net mailto:support@sonic.net #

Subject: Re: (usr-tc) modem connect issue
From: Kingsley S. Grant <ksg@recorder.ca>
Date: 1998-10-23 17:26:46

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML> <BODY BGCOLOR="#FFFFFF"> Brian, <BR> This is the modem that comes in the new packad bell 800c series computers. <BR>it is supposed to be a sound4 modem  wich emulates a usr winmodem but it has the LT (lucent technology) chipset ver 5.14 it will not connect to the usr chassis unless you add <BR> -v90=0 to the init string. <BR> the update on Packard bells site does not update the modem at least the current one does not. <BR> I think it is actually a LT winmodem but the normal 5.20/5.23 update does not work . this is most likely a PCI modem. <BR> for now just add the -v90=0 to the additional init strings under modem/properties/connection/advanced/extra settings.  this will get them online so they can download an update when available. <BR>                King. <BR> (Aztech is the maker of the modem) <P>Brian K McIntire wrote: <BLOCKQUOTE TYPE=CITE> <FONT COLOR="#000000"><FONT SIZE=-1>Anyone ever heard of a desktop modem with the following model # mdp7800</FONT></FONT><FONT COLOR="#000000"><FONT SIZE=-1>I'm dealing with an issue with a customer that has no idea who made the modem so I can't go out and look to see if there are any known issues</FONT></FONT> </BLOCKQUOTE> </BODY> </HTML>

Subject: Re: (usr-tc) modem connect issue
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-23 17:35:06

This is a multi-part message in MIME format. ------=_NextPart_000_0134_01BDFEAB.79965540 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you for your response. It was very helpful. -----Original Message----- From: Kingsley S. Grant <ksg@recorder.ca> To: <usr-tc@lists.xmission.com> Date: Friday, October 23, 1998 4:25 PM Subject: Re: (usr-tc) modem connect issue =20 =20 Brian,=20 This is the modem that comes in the new packad bell 800c series = computers.=20 it is supposed to be a sound4 modem wich emulates a usr winmodem but = it has the LT (lucent technology) chipset ver 5.14 it will not connect = to the usr chassis unless you add=20 -v90=3D0 to the init string.=20 the update on Packard bells site does not update the modem at least = the current one does not.=20 I think it is actually a LT winmodem but the normal 5.20/5.23 update = does not work . this is most likely a PCI modem.=20 for now just add the -v90=3D0 to the additional init strings under = modem/properties/connection/advanced/extra settings. this will get them = online so they can download an update when available.=20 King.=20 (Aztech is the maker of the modem)=20 Brian K McIntire wrote:=20 Anyone ever heard of a desktop modem with the following model # = mdp7800I'm dealing with an issue with a customer that has no idea who = made the modem so I can't go out and look to see if there are any known = issues=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 ------=_NextPart_000_0134_01BDFEAB.79965540 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 HTML 4.0 = Transitional//EN"><HTML> <META content=3D'"MSHTML 5.00.0518.7"' name=3DGENERATOR> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT color=3D#000000 size=3D2>Thank you for your response.  = It was very=20 helpful.</FONT></DIV> <BLOCKQUOTE=20 style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: = 5px"> <DIV><FONT face=3DArial size=3D2><B>-----Original = Message-----</B><BR><B>From:=20 </B>Kingsley S. Grant <<A=20 href=3D"mailto:ksg@recorder.ca">ksg@recorder.ca</A>><BR><B>To: = </B><<A=20 = href=3D"mailto:usr-tc@lists.xmission.com">usr-tc@lists.xmission.com</A>&g= t;<BR><B>Date:=20 </B>Friday, October 23, 1998 4:25 PM<BR><B>Subject: </B>Re: (usr-tc) = modem=20 connect issue<BR><BR></DIV> </FONT>Brian, <BR> This is the modem that comes in the new packad = bell=20 800c series computers. <BR>it is supposed to be a sound4 modem  = wich=20 emulates a usr winmodem but it has the LT (lucent technology) chipset = ver 5.14=20 it will not connect to the usr chassis unless you add = <BR> -v90=3D0 to the=20 init string. <BR> the update on Packard bells site does not = update the=20 modem at least the current one does not. <BR> I think it is = actually a LT=20 winmodem but the normal 5.20/5.23 update does not work . this is most = likely a=20 PCI modem. <BR> for now just add the -v90=3D0 to the additional = init=20 strings under modem/properties/connection/advanced/extra = settings.  this=20 will get them online so they can download an update when available.=20 = <BR>           &nb= sp;   =20 King. <BR> (Aztech is the maker of the modem)=20 <P>Brian K McIntire wrote:=20 <BLOCKQUOTE TYPE =3D CITE> <FONT color=3D#000000><FONT = size=3D-1>Anyone ever=20 heard of a desktop modem with the following model #=20 mdp7800</FONT></FONT><FONT color=3D#000000><FONT size=3D-1>I'm = dealing with an=20 issue with a customer that has no idea who made the modem so I can't = go out=20 and look to see if there are any known = issues</FONT></FONT> </BLOCKQUOTE> - To unsubscribe to usr-tc, send an email to=20 "majordomo@xmission.com" with "unsubscribe usr-tc" = in the=20 body of the message. For information on digests or retrieving files = and old=20 messages send "help" to the same address. Do not use quotes = in your=20 message. </BLOCKQUOTE> </BODY></HTML> ------=_NextPart_000_0134_01BDFEAB.79965540--

Subject: Re: (usr-tc) modem connect issue
From: Peter D. Mayer <dmayer@netwalk.com>
Date: 1998-10-23 17:57:11

Brian, I think the modem you're dealing with there is the Aztech MDP7800. We've had a couple of calls about the MDP3858 here (same company). Go to http://www.aztech.com.sg/c&t/drv_v_90.htm and you'll find the latest drivers. These are coming shipped with Micro Center PowerSpec machines in our area, and a lot of people around here get their machines there. Really a pain. I wish the manufacturers would just get a clue and put a decent modem in these machines. It would probably only cost $20 more. Peter D. Mayer NetWalk System Administrator dmayer@netwalk.com -----Original Message----- Anyone ever heard of a desktop modem with the following model # mdp7800 I'm dealing with an issue with a customer that has no idea who made the modem so I can't go out and look to see if there are any known issues

Subject: Re: (usr-tc) Hiper ARC RADIUS question
From: Mike Wronski <mwronski@coredump.ae.usr.com>
Date: 1998-10-23 19:23:46

On Fri, 23 Oct 1998, Brian K McIntire wrote: > I have a customer who wants to be able to setup a HiPer ARC to authenticate users to two different RADIUS servers. Not a primary & secondary setup but an either/or setup. In other words if the name is not found on one RADIUS he wants the HiPer ARC to direct the authentication request to the other. Is this possible? I know it sounds like a strange thing to want to do but trust me there is a reason for it. > Any help is appreciated. > No. This should be implemented on the RADIUS server. -M

Subject: Re: (usr-tc) Hiper ARC RADIUS question
From: MegaZone <megazone@megazone.org>
Date: 1998-10-23 20:36:17

Once upon a time Brian K McIntire shaped the electrons to say... >I have a customer who wants to be able to setup a HiPer ARC to authenticate users to two different RADIUS servers. Not a primary & secondary setup but an either/or setup. In other words if the name is not found on one RADIUS he wants the HiPer ARC to direct the authentication request to the other. Is this possible? I know it sounds like a strange thing to want to do but trust me there is a reason for it. Not possible - the RADIUS server will return a Reject. How could the NAS know it was a reject because the user was not found, or for some other reason. The best way to handle this is on the RADIUS server - if it can't find it locally it can try proxying to another server. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: MegaZone <megazone@megazone.org>
Date: 1998-10-23 20:38:41

Once upon a time Tatai SV Krishnan shaped the electrons to say... >On Fri, 23 Oct 1998, Dan Hollis wrote: >> Why isnt it in the authentication request packet? >What are you going to do? Are you going to run your radius in debug mode >to see the connect speed? Lucent RADIUS can parse Connect-Info and use the speed as a check item. PortMaster's have supported Connect-Info in the Auth-Req for a long time. Both their free RADIUS and RADIUS ABM (which was released today). I believe Cistron also supports this, and others may. -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) Login Message
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-23 22:22:18

set modem_group all message " " 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, 23 Oct 1998, Brian Biggs wrote: > Hello, > > How do I get rid of this message via CLI (offending message > prefaced with '>' marks): > > CONNECT 64000/ARQ/DIGITAL/V120 > > >Welcome to 3Com Total Control HiPer ARC (TM) > >Networks That Go The Distance (TM) > sonic (nas21) login: > > > Thanks! > -Brian > -- > # Brian Biggs | Sonic / Sonoma Interconnect # > # Sys Admin / Programmer | v707.522.1000 fax707.547.2199 d707.522.1001 # > # mailto:bb@sonic.net | http://www.sonic.net mailto:support@sonic.net # > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Hiper ARC RADIUS question
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-24 10:24:44

Makes perfect sense. I didn't think it through. Thanks to everyone who replied. -----Original Message----- >Once upon a time Brian K McIntire shaped the electrons to say... >>I have a customer who wants to be able to setup a HiPer ARC to authenticate users to two different RADIUS servers. Not a primary & secondary setup but an either/or setup. In other words if the name is not found on one RADIUS he wants the HiPer ARC to direct the authentication request to the other. Is this possible? I know it sounds like a strange thing to want to do but trust me there is a reason for it. > >Not possible - the RADIUS server will return a Reject. How could the NAS >know it was a reject because the user was not found, or for some other >reason. > >The best way to handle this is on the RADIUS server - if it can't find it >locally it can try proxying to another server. > >-MZ >-- ><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! > ==================================================================== > ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. > Three days of clues, news, and views from the industry's best and > brightest. http://www.ispf.com/ for information and registration. > ==================================================================== > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Login Message
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-24 10:30:18

set modem_group all message "Welcome to My net\n" "Now get out\n" or set modem_group all message "" -----Original Message----- >Hello, > > How do I get rid of this message via CLI (offending message >prefaced with '>' marks): > >CONNECT 64000/ARQ/DIGITAL/V120 > >>Welcome to 3Com Total Control HiPer ARC (TM) >>Networks That Go The Distance (TM) >sonic (nas21) login: > > > Thanks! > -Brian >-- > # Brian Biggs | Sonic / Sonoma Interconnect # > # Sys Admin / Programmer | v707.522.1000 fax707.547.2199 d707.522.1001 # > # mailto:bb@sonic.net | http://www.sonic.net mailto:support@sonic.net # > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) pmwho?
From: Richard Stuplich <dick@dwave.net>
Date: 1998-10-24 10:33:18

This is an ARC issue. I went around for a few hours with that creating the arc versions of pmwho and pmcom. The arc uses \n in some places and \r in others. Leave it to 3com. You can get these at http://www.dwave.net/arctools/ hawho and hacom also deals with ">>" on the arc. It may be worth looking at if you want to fix pmwho to work with the multi-link PPP sessions logged in. At 11:02 AM 10/24/98 -0400, you wrote: >That's one of the gotchas, yeah. I also remember that at one point, pmcom >was sending the wrong end-of-line character (a \r vs \n issue)... this >might have been when I was trying to get pmcom to talk to an ARC though. >But it might be worth looking at. > > >Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org >VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net >Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ >If Milli Vanilli fell in the forest, would someone else make the sound? > >On Fri, 23 Oct 1998, Brian Uechi wrote: > >> pmwho looks for a '>' to indicate the netserver is at a command >> prompt. When there are multi-link PPP connections on the netserver >> the "show sess" command will include the '>' character which confuses >> pmwho. It's an easy fix in the source. >> >> On Fri, 23 Oct 1998, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: >> >> > On Thursday, October 22, 1998 6:32 PM, Charles Sprickman >> > [SMTP:spork@inch.com] wrote: >> > >> > > I'm testing from one machine, and pmwho times out on some of the >> > > netservers, and not others. They are all running 3.7.73, and are all >> > > reachable by "manually" telnet-ing to each of them. The default pw is the >> > > same on all, as is the telnet port. >> > >> > When debugging this on some of my own boxes it was useful to run strace on >> > the process so I could see exactly what was going on behind the scenes. You >> > should have strace available if you're running pmwho on a linux box. If >> > it's a solaris box, the truss program acomplishes the same feat. >> > >> > if you're using csh: >> > strace pmwho host |& less >> > >> > or sh: >> > strace pmwho host 2>&1 |less >> > >> > Be Seeing 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. >> > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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, a full T1, 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 1998 Richard Stuplich, see http://dw.net/cr/

Subject: RE: (usr-tc) pmwho?
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-24 11:02:26

That's one of the gotchas, yeah. I also remember that at one point, pmcom was sending the wrong end-of-line character (a \r vs \n issue)... this might have been when I was trying to get pmcom to talk to an ARC though. But it might be worth looking at. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ If Milli Vanilli fell in the forest, would someone else make the sound? On Fri, 23 Oct 1998, Brian Uechi wrote: > pmwho looks for a '>' to indicate the netserver is at a command > prompt. When there are multi-link PPP connections on the netserver > the "show sess" command will include the '>' character which confuses > pmwho. It's an easy fix in the source. > > On Fri, 23 Oct 1998, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: > > > On Thursday, October 22, 1998 6:32 PM, Charles Sprickman > > [SMTP:spork@inch.com] wrote: > > > > > I'm testing from one machine, and pmwho times out on some of the > > > netservers, and not others. They are all running 3.7.73, and are all > > > reachable by "manually" telnet-ing to each of them. The default pw is the > > > same on all, as is the telnet port. > > > > When debugging this on some of my own boxes it was useful to run strace on > > the process so I could see exactly what was going on behind the scenes. You > > should have strace available if you're running pmwho on a linux box. If > > it's a solaris box, the truss program acomplishes the same feat. > > > > if you're using csh: > > strace pmwho host |& less > > > > or sh: > > strace pmwho host 2>&1 |less > > > > Be Seeing 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. >

Subject: RE: (usr-tc) pmwho?
From: Charles Sprickman <spork@inch.com>
Date: 1998-10-24 12:14:41

On Sat, 24 Oct 1998, Mike Andrews wrote: > That's one of the gotchas, yeah. I also remember that at one point, pmcom > was sending the wrong end-of-line character (a \r vs \n issue)... this > might have been when I was trying to get pmcom to talk to an ARC though. > But it might be worth looking at. Actually bob@southcom helped me with this one. In my case it was because of a weird prompt difference on some of my NetServers. Changing the string that pmwho looks for to something more unique fixed it all up... Thanks all! Charles > > > Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org > VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net > Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ > If Milli Vanilli fell in the forest, would someone else make the sound? > > On Fri, 23 Oct 1998, Brian Uechi wrote: > > > pmwho looks for a '>' to indicate the netserver is at a command > > prompt. When there are multi-link PPP connections on the netserver > > the "show sess" command will include the '>' character which confuses > > pmwho. It's an easy fix in the source. > > > > On Fri, 23 Oct 1998, Stainforth, Matthew (Sys Mgr - BrunNet) wrote: > > > > > On Thursday, October 22, 1998 6:32 PM, Charles Sprickman > > > [SMTP:spork@inch.com] wrote: > > > > > > > I'm testing from one machine, and pmwho times out on some of the > > > > netservers, and not others. They are all running 3.7.73, and are all > > > > reachable by "manually" telnet-ing to each of them. The default pw is the > > > > same on all, as is the telnet port. > > > > > > When debugging this on some of my own boxes it was useful to run strace on > > > the process so I could see exactly what was going on behind the scenes. You > > > should have strace available if you're running pmwho on a linux box. If > > > it's a solaris box, the truss program acomplishes the same feat. > > > > > > if you're using csh: > > > strace pmwho host |& less > > > > > > or sh: > > > strace pmwho host 2>&1 |less > > > > > > Be Seeing 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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the 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 Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork@inch.com access@inch.com | = =----------------=

Subject: Re: (usr-tc) Strange Occurrence
From: Russ Miescke <russm@powerweb.net>
Date: 1998-10-25 00:29:07

I had a similar problem. What seems to have happened in my case was that the quads defaulted the ports back to login instead of network dialin. I set all to network dialin and I was back in business. Russ Miescke Power Web Connect russm@powerweb.net http://www.powerweb.net -----Original Message----- I have a chassis that after a power outage this afternoon, all of the sudden will only answer 1 call off of the first Span on a Dual-T1 card. I have checked the settings on the quads, and all looks correct. I don't think that it is the T1 card since I can go in and change the DS0 states to busy out and it generates a busy on that circuit. I am as I type on hold with support but wanted to see if anyone else has come across this problem before. This is actually the second time that I have had a card do this to me, only it was in a different chassis before and it still has not been figured out. On the other chassis the blame was pointed to the circuit itself, yet if I swap the circuits around the failing circuit behaves correctly and the previous functioning circuit goes haywire. The only solve so far to the other chassis, after replacing the chassis, the T1 card, the Netserver and the NMC, is to put in a HiPER DSP card into the chassis and the circuit worked fine. So far the tech that I am talking to is dumbfounded and doesn't know what the problem is. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) (USR-TC) MODEM CONNECT ISSUE
From: Jeff Binkley <jeff.binkley@asacomp.com>
Date: 1998-10-25 05:28:00

I've got the exact same problem with a customer here with our TC racks. They connect but at the point where PPP should start, they disconnect. I never see a userid or password being sent. Doing a monitor PPP in the HiPerArc doesn't help. However if they start their AOL software, let it initialize the modem, then go bqck to DUN under 95, all is well. Jeff Binkley ASA Network Computing -> Anyone ever heard of a desktop modem with the following model # mdp7800 I'm -> dealing with an issue with a customer that has no idea who made the = modem -> so I can't go out and look to see if there are any known issues=20

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Mike Wronski <mwronski@coredump.ae.usr.com>
Date: 1998-10-25 08:31:42

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-10-25 15:16:51

On Sun, 25 Oct 1998, Mike Wronski wrote: > On Fri, 23 Oct 1998, Dan Hollis wrote: > > On Fri, 23 Oct 1998, Tatai SV Krishnan wrote: > > > On Fri, 23 Oct 1998, Dan Hollis wrote: > > > > Why isnt it in the authentication request packet? > > > What are you going to do? Are you going to run your radius in debug mode > > > to see the connect speed? > > No, im going to modify radius to reject eg v90 calls *at login* for > > customers who havent paid for v90. > Why charge for a service that does not use any extra resources? > Its not like ISDN or MLPPP that would require a larger investment on the > part of the ISP. So you dont call more bandwidth extra resources? How cute. Well since bandwidth obviously doesnt require investment on the part of the ISP, how about giving us some of yours for free. -Dan

Subject: Re: (usr-tc) TC Netserver discussion...observation
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-10-25 15:34:15

>It does not matter if the NETServer software or the >hardware is the problem. We have HiPer arc and we shall >concentrate on making this better and add feature that >are requested. > > >krish > We purchased our TC equipment 14 months ago. I find it astonishing that a piece of equipment priced the same as your average automobile can be so quickly written off by its manufacturer. Steve

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Dan Hollis <goemon@sasami.anime.net>
Date: 1998-10-25 16:00:44

On Sun, 25 Oct 1998, Kirk Mitchell wrote: > I'd imagine the comment was precipitated by the fact that very few ISPs > charge extra for 56k connections as opposed to a v34 connection. Well Mike threw in ISDN and MLPPP as "no extra resources" too. How many ISPs dont charge extra for ISDN, or dual channel? From what I can tell, very *few* ISPs charge the same for 56k as for 28.8k. -Dan

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Kirk Mitchell <mitch@keyconn.net>
Date: 1998-10-25 18:44:40

At 03:16 PM 10/25/98 -0800, Dan Hollis wrote: >On Sun, 25 Oct 1998, Mike Wronski wrote: >> > No, im going to modify radius to reject eg v90 calls *at login* for >> > customers who havent paid for v90. >> Why charge for a service that does not use any extra resources? > >So you dont call more bandwidth extra resources? How cute. > >Well since bandwidth obviously doesnt require investment on the part of >the ISP, how about giving us some of yours for free. Having a faster modem doesn't inherently mean that a user will consume more bandwidth. It's just as likely that they'll be able to do what they want faster, then log-off. This will actually save your resources as the bandwidth used is the same yet your modem was available for the next customer sooner. I'm sure that by "extra resources" he meant that the modem would be in use regardless of whether the user connected at 9600 or 52k. I'd imagine the comment was precipitated by the fact that very few ISPs charge extra for 56k connections as opposed to a v34 connection. just my $.02 Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-25 19:14:04

Kirk Mitchell was heard to say: >Having a faster modem doesn't inherently mean that a user will consume more >bandwidth. It's just as likely that they'll be able to do what they want >faster, then log-off. This will actually save your resources as the >bandwidth used is the same yet your modem was available for the next >customer sooner. I'm sure that by "extra resources" he meant that the modem >would be in use regardless of whether the user connected at 9600 or 52k. >I'd imagine the comment was precipitated by the fact that very few ISPs >charge extra for 56k connections as opposed to a v34 connection. Well, it has long been my stance to make no distinction between connections. From 75 baud to 64k ISDN... it's all the same phone line. The telco isn't going to charge us any differently for that line. However, the higher the speed of the connection, the more traffic is generally generated. That means the POP will require more bandwidth to support all the higher speed connections. --Ricky

Subject: Re: (usr-tc) (USR-TC) MODEM CONNECT ISSUE
From: Dave Winston <mhamrich@drfast.net>
Date: 1998-10-25 19:30:24

DOV on a Total Controll with Quadmodems and ISDN currently terminating on the Munich board. Was listed as feature in documentation. Does it work, if so where can I find info how to do it. Thanks Dave Winston -----Original Message----- >I've got the exact same problem with a customer here with our TC racks. >They connect but at the point where PPP should start, they disconnect. >I never see a userid or password being sent. Doing a monitor PPP in >the HiPerArc doesn't help. However if they start their AOL software, >let it initialize the modem, then go bqck to DUN under 95, all is well. > >Jeff Binkley >ASA Network Computing > > >-> Anyone ever heard of a desktop modem with the following model # mdp7800 I'm >-> dealing with an issue with a customer that has no idea who made the = modem >-> so I can't go out and look to see if there are any known issues=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.

Subject: (usr-tc) Strange Occurrence
From: Eric C Forcey <eric@psnw.com>
Date: 1998-10-25 20:43:49

I have a chassis that after a power outage this afternoon, all of the sudden will only answer 1 call off of the first Span on a Dual-T1 card. I have checked the settings on the quads, and all looks correct. I don't think that it is the T1 card since I can go in and change the DS0 states to busy out and it generates a busy on that circuit. I am as I type on hold with support but wanted to see if anyone else has come across this problem before. This is actually the second time that I have had a card do this to me, only it was in a different chassis before and it still has not been figured out. On the other chassis the blame was pointed to the circuit itself, yet if I swap the circuits around the failing circuit behaves correctly and the previous functioning circuit goes haywire. The only solve so far to the other chassis, after replacing the chassis, the T1 card, the Netserver and the NMC, is to put in a HiPER DSP card into the chassis and the circuit worked fine. So far the tech that I am talking to is dumbfounded and doesn't know what the problem is.

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-25 22:00:13

Thus spake Dan Hollis >On Sun, 25 Oct 1998, Kirk Mitchell wrote: >> I'd imagine the comment was precipitated by the fact that very few ISPs >> charge extra for 56k connections as opposed to a v34 connection. >Well Mike threw in ISDN and MLPPP as "no extra resources" too. How many >ISPs dont charge extra for ISDN, or dual channel? We don't charge extra for ISDN...multi-channel we do (not MP strictly, but that's the implication). >From what I can tell, very *few* ISPs charge the same for 56k as for >28.8k. None around here (that I'm aware of) charge extra for 56k...just a data point. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-25 22:01:26

Thus spake Kirk Mitchell >Having a faster modem doesn't inherently mean that a user will consume more >bandwidth. It's just as likely that they'll be able to do what they want >faster, then log-off. This will actually save your resources as the >bandwidth used is the same yet your modem was available for the next >customer sooner. Go back, reread what you posted, and tell me why you came to the wrong conclusion. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: Re: (usr-tc) Strange Occurrence
From: Eric C Forcey <eric@psnw.com>
Date: 1998-10-25 22:57:31

Having them set to login woudln't prevent a call from completing, only a call once connected being able to log into the system. It isn't that since I as well as the tech that I was working with mapped the DS0's from the second span to use the modems that were originally set to the first span and they connected just fine. The final outcome from the call to tech support was to reseat the netserver card, which I am going to do in the am. At 12:29 AM 10/25/98 -0500, you wrote: >I had a similar problem. What seems to have happened in my case was that >the quads defaulted the ports back to login instead of network dialin. I >set all to network dialin and I was back in business. > > >Russ Miescke >Power Web Connect >russm@powerweb.net >http://www.powerweb.net > >-----Original Message----- >From: Eric C Forcey <eric@psnw.com> >To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com> >Date: Monday, October 26, 1998 12:12 AM >Subject: (usr-tc) Strange Occurrence > > > > >I have a chassis that after a power outage this afternoon, all of the >sudden will only answer 1 call off of the first Span on a Dual-T1 card. > >I have checked the settings on the quads, and all looks correct. I don't >think that it is the T1 card since I can go in and change the DS0 states to >busy out and it generates a busy on that circuit. I am as I type on hold >with support but wanted to see if anyone else has come across this problem >before. > >This is actually the second time that I have had a card do this to me, only >it was in a different chassis before and it still has not been figured out. >On the other chassis the blame was pointed to the circuit itself, yet if I >swap the circuits around the failing circuit behaves correctly and the >previous functioning circuit goes haywire. The only solve so far to the >other chassis, after replacing the chassis, the T1 card, the Netserver and >the NMC, is to put in a HiPER DSP card into the chassis and the circuit >worked fine. > >So far the tech that I am talking to is dumbfounded and doesn't know what >the problem is. > >- >To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" >with "unsubscribe usr-tc" in the body of the message. >For information on digests or retrieving files and old messages send >"help" to the same address. Do not use quotes in your message. > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-26 08:18:08

On Sun, 25 Oct 1998, Jeff Mcadams wrote: > >From what I can tell, very *few* ISPs charge the same for 56k as for > >28.8k. > > None around here (that I'm aware of) charge extra for 56k...just a data > point. I can second that. I only know of one ISP around here that charges extra for 56K modems access. Because of CLECs that recently moved into this area, it is actually cheaper to use digital equipment and lines. As long as all the digital equipment supports 56k, we might as well offer it. Brian

Subject: Re: (usr-tc) Porting Linux to the Netserver
From: Suncoast Networking USR Mailbox <usrtcmail@flasuncoast.net>
Date: 1998-10-26 08:59:59

>>I've a question: just what would it take to port Linux to the Netserver? >>I understand that it's using a 486 CPU; most have 16 meg of RAM and >>a 2 meg flash device is plenty for a small system. > >1) 4meg of flash or more -- 8M would probably be plenty. Eh? You can boot Linux from 2 meg images that includes full support for everything including the kitchen sink. Once you remove kernel support for everything you don't need, you can get a robust Linux kernel image into less than 1 meg of flash/nvram. >2) board level information pertaining to its "PC"ness >3) information for programming the midplane packet bus/TDM bus logic >4) information on the management bus protocols (if you want the NMC to > still work with it.) >5) information on the packet bus protocol used to communicate with the > modem cards. > Looks like that should be just 2) Interfacing the card to the chassis. The packet buses are probably just modified Serial or parallel I/O ports to the system. You could write a test kernel that would act like a Sniffer on all the ports to capture bus data on a netserver running next to a working netserver. >>If we could port Linux to the Netserver, we'd have an open-source system >>that *we* could adapt to our needs, with the nice features provided by >>the TCs' call-termination hardware. >> >It would not be a totally open-source system. There are parts of the source >that would have to be protected as trade-secrets -- ie. the bus protocols and >logic interface protocols. What you would have is an embedded Linux system. > Thats if they gave us the information..... :) Since USR/3com has abandoned Netserver, the only one that might take exception is Livingston. And if they're calling you every two weeks like they call us, they probably wouldn't do anything either. USR/3Com has clearly abandoned Netserver and wants to focus their energies on arc. (when I hear the name Arc I always think of an electrical short....) So they should support such an effort. The real issue would be finding Linux programming gurus that could take on such a project. A Linux port to Netserver would have to be sponsored by ISP's. Steve

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Mike Wronski <mwronski@coredump.ae.usr.com>
Date: 1998-10-26 09:19:28

On Sun, 25 Oct 1998, Dan Hollis wrote: > On Sun, 25 Oct 1998, Kirk Mitchell wrote: > > I'd imagine the comment was precipitated by the fact that very few ISPs > > charge extra for 56k connections as opposed to a v34 connection. > > Well Mike threw in ISDN and MLPPP as "no extra resources" too. How many > ISPs dont charge extra for ISDN, or dual channel? Very few.. Thats why I said its NOT like MLPPP ot ISDN.. I would expect an ISP to charge someone fro using two channels as opposed to one.. I did not include them I EXCLUDED them.

Subject: Re: (usr-tc) Problems with brackets in session_start_message
From: Mike Wronski <mwronski@coredump.ae.usr.com>
Date: 1998-10-26 09:26:27

On Mon, 26 Oct 1998, Ricky Beam wrote: > Paul Curnock was heard to say: > >I have encountered the following problem and was wondering if anyone has > >seen it before? > > > >set slip session_start_message "SL/IP session from (%server_ip) to > >%client_ip beginning..." > > > >However, when I connect I get: > > > >SL/IP session from ( 194.42.231.3 to 255.96.0.0 beginning...A > > Yes, I've seen and reported this. Somehow I think 3Com either missed the > report or ignored it. I've heard nothing about a fix for it. > Have you tried escaping the '(' with back slashes?? set slip session_start_message "SL/IP session from $%server_ip$ to %client_ip beginning..." -M

Subject: Re: (usr-tc) Problems with brackets in session_start_message
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-26 10:15:14

Paul Curnock was heard to say: >I have encountered the following problem and was wondering if anyone has >seen it before? > >set slip session_start_message "SL/IP session from (%server_ip) to >%client_ip beginning..." > >However, when I connect I get: > >SL/IP session from ( 194.42.231.3 to 255.96.0.0 beginning...A Yes, I've seen and reported this. Somehow I think 3Com either missed the report or ignored it. I've heard nothing about a fix for it. --Ricky

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-26 10:56:23

> Having a faster modem doesn't inherently mean that a user will consume > more bandwidth. It's just as likely that they'll be able to do what > they want faster, then log-off. This will actually save your resources > as the bandwidth used is the same yet your modem was available for the > next customer sooner. That argument works in the US, but not here in Australia. Bandwidth is charged per megabyte and accounts are typically metered. The longer someone stays online, the more you make from them. Therefore, if they get on, do what they want quicker and use the same amount of bandwidth, we lose :-( Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: (usr-tc) Having a bad time with ripv2
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1998-10-26 11:05:18

Does the HiperARC suffer from the same stupid problem as the Netserver with respect to Ripv2 broadcasts/multicasts? I'm trying to get an ARC (4.0.30) talking to my main Cisco host, and I *cannot* get it to send any rip updates to the router. This is the current config (that I can find) Does *anything else* need to be turned on in order to run ripv2 on an ARC? All my other hosts are sending updates to my cisco box fine. IP Routing Protocol: RIPV2 IP RIP Routing Policies: SEND_ROUTES SEND_SUBNETS SPLIT_HORIZON POISON_REVERSE FLASH_UPDATE -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 - "Computationally expensive" is a computer term for "slow"

Subject: (usr-tc) Stable solid DSP/ARC code
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1998-10-26 11:42:37

Heya folks. Since I've added a 4th DSP to the lone ARC chassis I have here, it seems as though hangup problems have increased tenfold. I will be trying the 1.2.68 DSP release to see if I can make the problem go away. The only other issue is that I still have 4.0.30 running on my ARC. Is there newer code that does not suffer from all these reported new problems? (ie: webtv issues) Is 4.1.x that different from the 4.0 tree? -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 - "Computationally expensive" is a computer term for "slow"

Subject: (usr-tc) Radius List's
From: Terry Kennedy <terry@olypen.com>
Date: 1998-10-26 11:51:00

I saw a post the other day here about a Radius mailing list. I was hoping to here more about without posting, but alas it didn't happen. If some doesn't mind and knows about other list's that might help us here, I would appeciate someone posting the address's here or mailing me privately. Point and I shall follow... Thanks Terry Kennedy terry@olypen.com

Subject: RE: (usr-tc) Having a bad time with ripv2
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-26 12:42:08

when you show ip network ip does it say reconfigure needed (true) > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Gilles Melanson > Sent: Monday, October 26, 1998 10:05 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Having a bad time with ripv2 > > > Does the HiperARC suffer from the same stupid problem as the Netserver > with respect to Ripv2 broadcasts/multicasts? > > I'm trying to get an ARC (4.0.30) talking to my main Cisco host, and I > *cannot* get it to send any rip updates to the router. > > This is the current config (that I can find) > Does *anything else* need to be turned on in order to run ripv2 on an ARC? > All my other hosts are sending updates to my cisco box fine. > > IP Routing Protocol: RIPV2 > IP RIP Routing Policies: > SEND_ROUTES > SEND_SUBNETS > SPLIT_HORIZON > POISON_REVERSE > FLASH_UPDATE > > -- > Gilles Melanson ViaNet Internet Solutions > System Administrator 128 Larch St. Suite 301 > gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > - "Computationally expensive" is a computer term for "slow" > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: Re: (usr-tc) Problems with brackets in session_start_message
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-26 12:51:13

Mike Wronski was heard to say: >Have you tried escaping the '(' with back slashes?? > >set slip session_start_message "SL/IP session from $%server_ip$ to >%client_ip beginning..." I think I did, but it's been awhile. --Ricky

Subject: RE: (usr-tc) Having a bad time with ripv2
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1998-10-26 13:12:11

> when you show ip network ip does it say reconfigure needed (true) Reconfigure Needed: FALSE One thing I did change this morning was on the Cisco box. I didn't have: neighbor x.x.x.x in place for the ARC (I renumbered it a while back). It was working, once upon a time. The Cisco box is sending updates back to the 3com - is there any way of debugging ripv2 on the 3com side? I'm tempted to power cycle at some point in time, but that's a rather irritating way to try to resolve a problem. > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Gilles Melanson > > Sent: Monday, October 26, 1998 10:05 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Having a bad time with ripv2 > > > > > > Does the HiperARC suffer from the same stupid problem as the Netserver > > with respect to Ripv2 broadcasts/multicasts? > > > > I'm trying to get an ARC (4.0.30) talking to my main Cisco host, and I > > *cannot* get it to send any rip updates to the router. > > > > This is the current config (that I can find) > > Does *anything else* need to be turned on in order to run ripv2 on an ARC? > > All my other hosts are sending updates to my cisco box fine. > > > > IP Routing Protocol: RIPV2 > > IP RIP Routing Policies: > > SEND_ROUTES > > SEND_SUBNETS > > SPLIT_HORIZON > > POISON_REVERSE > > FLASH_UPDATE > > > > -- > > Gilles Melanson ViaNet Internet Solutions > > System Administrator 128 Larch St. Suite 301 > > gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 > > > > - "Computationally expensive" is a computer term for "slow" > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages send > > "help" to the same address. Do not use quotes in your message. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 - "Computationally expensive" is a computer term for "slow"

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-26 13:58:19

> One thing you can do is this - > > setup DNIS based Authentication.. (upto a max. of 4 numbers) > > Once you've done that, Auth users based on the Dialled number. > > Then, in the Quad/HDSP setup, setup an init string in the DNIS Access to > lock the modem to 56K/x2, 33.6K, 28.8K and 9600. > > This would allow you 4 access numbers, but without the problems associated > with port grouping! (Hence, no oversubscription in your access ports). Does 3COM have any plans to implement some form of partitioning, similar to what I believe the ACC Tigris has? Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: (usr-tc) Problems with brackets in session_start_message
From: Paul Curnock <paul_curnock@pervasive.co.uk>
Date: 1998-10-26 14:15:56

I have encountered the following problem and was wondering if anyone has seen it before? set slip session_start_message "SL/IP session from (%server_ip) to %client_ip beginning..." However, when I connect I get: SL/IP session from ( 194.42.231.3 to 255.96.0.0 beginning... I require the brackets as our older sogtware which is still in circulation looks for the brackets surrounding the server ip. Has anyone seen this? or am I just being rather silly and missing something? Any comments would be helpful Thanks Paul

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: David Bolen <db3l@ans.net>
Date: 1998-10-26 14:35:30

Mike Wronski <mwronski@coredump.ae.usr.com> writes: > Why charge for a service that does not use any extra resources? > Its not like ISDN or MLPPP that would require a larger investment on the > part of the ISP. While pricing is largely a market driven issue, why would you assume that it doesn't cost any more to provide 56k on dialup? It seems to me that you're making assumptions about what constitutes a "resource" (I'm assuming you're thinking just of the telco access lines). In many cases, the faster dialup results in users creating a real, true higher demand for data, and achieving higher throughput. Often, call durations increasing as the responsiveness of access improve, which in turn can affect your modem to user ratio. These sorts of changes have many ramifications for the infrastructure behind those modems, any trunking to other providers and/or to the rest of the network, and can result in real cost increases on the back-end. Then again, there's the question of support, which shouldn't be forgotten. Many modem problems are generic to modems as a whole, but the 56K protocols bring a variety of interesting sorts of problems, failures, and support issues that can increase support overhead (particularly early in the period of acceptance of a protocol such as now). Now of course, competition may require that such changes be absorbed as part of competing as an ISP in an area, and it certainly seems that the trend is to consider the 56k protocols as just another analog access (which I personally agree with). But I wouldn't say that the fact that the market is driving things this way implies that there aren't or can't be additional costs due to supporting the protocols. It just might be that the typical ISP business model requires that any such costs be factored into the entire equation, and 56k not be treated separately as a surcharged item. And of course, whether or not it really costs more, trying to determine how one might be able to support such a modem (if one desired to do so) is still a useful discussion, IMO. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) HiPer "dead air" problem
From: Marcelo Souza <mpsouza@centroin.com.br>
Date: 1998-10-26 15:20:50

I'm with the same problem here, but with DSP code 1.1.91 (for E1R2 lines) and HARC V4.0.29. - Marcelo On Fri, 23 Oct 1998, Ralph Helfenberger wrote: |I think I got a similar (or the same) problem here. First everything |works fine. After some time there are more LEDs on that are actually |connections on the HiPer DSP. | |How it looks like |- The HiPer ARC shows connection wich are on for days (although the |users | have disconnected long time ago) |- The session monitor shows the same connections on the HiPER DSP | as onlineAnswer(8). But the call duration for those connections | doesn't move, even if you wait for one hours. |- A hangup of those connections in the HiPer ARC just clears the | connections from the "list connections" on the HiPer ARC. But on | the HiPer DSP they still are indicated as active. |- The only thing so far to get rid of the problem is to | reboot the HiPer DSP. |- We are working with HiPer DSP 1.2.5 and HiPer Arc 4.0.30 | |Any ideas ? | | |Mike Andrews wrote: |> |> We're starting to experience the "dead air" problem pretty severely here |> on our DSP/ARC rack. (DSP 1.2.5, ARC 4.11.78.) The call rejection count |> on my first DSP is at 3609 already. The other 3 DSPs are all 0 or 1. |> All four were rebooted less than 36 hours ago. All the interfaces show |> up/up right now. |> |> Per other people's recommendations here, I just fired an email off to |> Bellsouth to see if they can set their DMS100 to round-robin through the B |> channels instead of first-available. I'm also going to move some PRI's |> back to our spare Quads. The Quake players will just have to deal with |> it for a little while. :-) |> |> Once a card gets into this state, has anyone found any way to get those |> channels to behave themselves again, OTHER than busying out and then |> rebooting the whole DSP card? |> |> Also, when I went to reboot yesterday, the 4th DSP had several LEDs lit on |> its usage meter, despite the ARC showing no calls on that span. (I didn't |> check to see if the interfaces were up/up then, or what the reject count |> was.) Right now, it's showing 4 LED's, the reject count is 0, all |> interfaces are up, ATI6 on each modem shows several giving "current call" |> instead of "last call" times... yet the ARC shows only 1 active session. |> Hmm. Different problem? |> |> Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org |> VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net |> Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ |> If Milli Vanilli fell in the forest, would someone else make the sound? |> |> - |> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" |> with "unsubscribe usr-tc" in the body of the message. |> For information on digests or retrieving files and old messages send |> "help" to the same address. Do not use quotes in your message. | |- | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" | with "unsubscribe usr-tc" in the body of the 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

Subject: (usr-tc) FW: USR Netserver 8/16 vulnarable to nestea attack
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-10-26 15:30:44

This might be of some interest to some of you running on this platform. I haven't checked totalservice yet to see if there is more current code that is immune to this attack. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 > A quart of wheat for a day's wages, and three quarts of barley for a day's > wages, and do not damage the oil and the wine! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > -----Original Message----- > From: Vesselin Mladenov [SMTP:root@NETBG.COM] > Sent: Monday, October 26, 1998 2:51 PM > To: BUGTRAQ@NETSPACE.ORG > Subject: USR Netserver 8/16 vulnarable to nestea attack > > Three days ago I found out that USR Netserver 8/16 V.34, running version > 2.0.14 OS is vulnerable to nestea DoS attack (for more info lookup in > http://www.rootshell.com). > I alarmed 3COM by sending them e-mail about the problem and exact > behaviour > of the NAS I was playing with. > They mailed me back, telling me that they appreciate I have contacted > them, > but unfortunatelly they are too busy to pay attention to my e-mail, so I > was > redirected to the local technical support organization. > Well, I decided to forward the message to bugtraq - cause I'm sure the > response will be more rapid and they'll be no more too busy. :) > > Here is the message, in general: > > -------------------------------------------------- > Hi, > > I was playing with old nestea program (http://www.rootshell.com) and I > decided to test if my netserver is vulnarable to that attack. > Unfortunatelly it turned out that it is. > The model is NETServer/8 V.34, OS version 4.0.14. > The error message netserver returned to me was: > > bla bla bla .../src/ppp_dsm.c Level CRITICAL: Buffer Alloc Error (3052) > ES_NO_BUFMEM > > After that netserver stop accepting user logins. > From logfile: "Connection was dropped for user UNKNOWN." > > I use RADIUS authentication and accounting. > > In 10% of cases netserver was completely dead. I attacked the NAS with 200 > repetitions of nestea. If you increase the repetition number, you will not > have to run the nestea twice to kill the netserver completely. > > I thing that the problem is in ppp_dsm.c module. > The module is quite buggy - there are other problems with it, but not so > serious as this one. > > --------------------------------------------------- > > That's it. > > > --------------------------- > Vesselin Mladenov > NetBG Ltd. > Phone: +3592-9744260 > ---------------------------

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Kirk Mitchell <mitch@keyconn.net>
Date: 1998-10-26 16:13:39

At 10:01 PM 10/25/98 -0500, Jeff McAdams wrote: >Thus spake Kirk Mitchell >>Having a faster modem doesn't inherently mean that a user will consume more >>bandwidth. It's just as likely that they'll be able to do what they want >>faster, then log-off. This will actually save your resources as the >>bandwidth used is the same yet your modem was available for the next >>customer sooner. > >Go back, reread what you posted, and tell me why you came to the wrong >conclusion. :) Hmmm...looks ok to me :) I'm not referring to the immediate effect of a 56k modem pulling a file, as opposed to a 28.8 pulling that file. What I'm referring to is the overall capacity useage caused by the file download. Which consumes more, downloading a 1mb file at 52k in 20 minutes, or downloading the same file at 28.8 in 38 minutes? In the grand scheme of things, they both have used an equal amount of your capacity, yet the 28.8 modem tied up your dial-in line longer. True, you can argue that the faster modem encourages people to download more, but that isn't always the case. Many times a user connects specifically to get some file, visit a specific website, or check email, and disconnects after he's done. In this case, if you have 'flat rate' or 'unlimited' accounts, you've come out ahead because the user hasn't stayed connected as long. Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-26 16:25:24

Thus spake Kirk Mitchell >At 10:01 PM 10/25/98 -0500, Jeff McAdams wrote: >>Thus spake Kirk Mitchell >>>Having a faster modem doesn't inherently mean that a user will consume more >>>bandwidth. It's just as likely that they'll be able to do what they want >>>faster, then log-off. This will actually save your resources as the >>>bandwidth used is the same yet your modem was available for the next >>>customer sooner. >> >>Go back, reread what you posted, and tell me why you came to the wrong >>conclusion. :) >Hmmm...looks ok to me :) *zoom* right over your head. :) > I'm not referring to the immediate effect of a 56k modem pulling a file, >as opposed to a 28.8 pulling that file. What I'm referring to is the >overall capacity useage caused by the file download. Which consumes more, >downloading a 1mb file at 52k in 20 minutes, or downloading the same file >at 28.8 in 38 minutes? First off...to be pedantic...bandwidth means the amount of data pushed over a line in a specific amount of time...so it does use more bandwidth...pedantry aside, you still missed a major point. >In the grand scheme of things, they both have used >an equal amount of your capacity, yet the 28.8 modem tied up your dial-in >line longer. True, you can argue that the faster modem encourages people to >download more, but that isn't always the case. Many times a user connects >specifically to get some file, visit a specific website, or check email, >and disconnects after he's done. In this case, if you have 'flat rate' or >'unlimited' accounts, you've come out ahead because the user hasn't stayed >connected as long. >>>This will actually save your resources as the >>>bandwidth used is the same yet your modem was available for the next >>>customer sooner. OK, here's the specific statement which points out the flaw in your own argument. :) Even assuming that the user only downloads a set amount of data...which is a stretch at best, but one I'm willing to run with for the moment...you yourself pointed out that the user then gets off the modem faster, freeing it up *for another user*. So...using your theory...yes, the "capacity" (not bandwidth) used by a specific user may be the same, but you're able to service more users on the same number of lines now, so your total capacity needed will *still* go up. I guess you could then argue that you would need fewer lines because you can then increase your user-modem ratio because users are being serviced more quickly with the faster modems, but that's *really* a stretch. :) -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) Bad Netserver Card - Looking for Spare??
From: Butch Kemper <kemper@tstar.net>
Date: 1998-10-26 16:29:05

Just this morning, I started getting these messages from a box (2059 bundle) with two CT1s, 12 Quad modem cards, and a Netserver.: >Oct 26 15:53:10 usr1 MODEM: S42: CALL_REF >0x0b010044< PRI_SLOT >255< TS > >22< SPAN >255< B_CH >255< >Oct 26 15:53:10 usr1 acct 0x0b010044 dial: S42 call arrived. >Oct 26 15:53:10 usr1 sent out answer incoming call for S42. The error is happening on many different ports. Sometimes a port fails and sometime it connects up normally. Watching the syslog, it seems that there is "shortage" of something because when some line disconnects, another line will succeccfully connect. When there seemed to be no other option, I powercycled the box but the problem remained. I called 3com Technical Support and they suggested the NetServer card was bad. Does anyone have any alternate possiblities? Butch

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: David Bolen <db3l@ans.net>
Date: 1998-10-26 16:34:57

Kirk Mitchell <mitch@keyconn.net> writes: >Thus spake Kirk Mitchell >> (...) This will actually save your resources as the >>bandwidth used is the same yet your modem was available for the next >>customer sooner. (...) > Hmmm...looks ok to me :) I think what Jeff was referring to is you basically said (if I might paraphrase): Old scheme: * User A works slower - takes X time and logs off. * User B signs on to same line, and does same thing. New scheme: * User A works faster - takes Y time to work and log off. * User B then signs on to same line, and does same thing. Now, by definition 2X (old scheme) is less time than 2Y (new scheme) but the same work is done - presumably requiring the same aggregate downloaded information, and thus a higher transfer rate averaged over the total time. So what you've said is that overall average higher bandwidth utilized is going to go up. > I'm not referring to the immediate effect of a 56k modem pulling a file, > as opposed to a 28.8 pulling that file. What I'm referring to is the > overall capacity useage caused by the file download. Which consumes more, > downloading a 1mb file at 52k in 20 minutes, or downloading the same file > at 28.8 in 38 minutes? In the grand scheme of things, they both have used > an equal amount of your capacity, yet the 28.8 modem tied up your dial-in > line longer. You've somehow decided to eliminate the time factor in bandwidth consumption. Bandwidth doesn't exist as a standalone metric, but rather as an available transfer capacity per unit time. Downloading that 1MB file in 20 minutes is going to use about 833bps of bandwidth in the system. Downloading the same file in 38 minutes is only going to use 439bps. In effect, the fact that the 28.8 modem "tied up" your dial-in line longer _saves_ your bandwidth resource on the back-end (and occupies an inbound line longer which is another kind of resource, not being addressed in this particular note). Now, yes, if you said that both users were actually online for 40 minutes (20 of which was downloading for the higher speed user, and 38 of which were downloading for the lower speed user), I'd agree that net bandwidth resource utilization over a large time scale would be about the same. Of course, systems have to be designed with peak loads in mind, so you might still have a problem. But you didn't say that - you said the faster user would get off sooner letting another user on. So you end up with the above session bps averages (for example) with each user keeping the higher rate up since they get off sooner. That's the contradiction in your original paragraph. > line longer. True, you can argue that the faster modem encourages people to > download more, but that isn't always the case. Many times a user connects > specifically to get some file, visit a specific website, or check email, > and disconnects after he's done. But then the next user does exactly the same thing - you service more users per unit time, which has the natural consequence that they all push up the average bandwidth (remember - data transfer per unit time) up, requiring more bandwidth from the system. > and disconnects after he's done. In this case, if you have 'flat rate' or > 'unlimited' accounts, you've come out ahead because the user hasn't stayed > connected as long. Only if that line isn't immediately used to service another similar user, which is what your original statement postulated :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: David Bolen <db3l@ans.net>
Date: 1998-10-26 16:45:37

In my last message, I wrote: (a few mis-calculations that I should have caught rather than zipping through it too quickly - don't you hate it when that happens). > Now, by definition 2X (old scheme) is less time than 2Y (new scheme) Argh - this is clearly backwards. 2Y < 2X - sorry about that. > Downloading that 1MB file in 20 minutes is going to use about 833bps > of bandwidth in the system. Downloading the same file in 38 minutes > is only going to use 439bps. In effect, the fact that the 28.8 modem I read your 1MB incorrectly as 1Mbit. So either change the "bps" to "cps" or multiply by 8 (to 6664bps or 3512bps respectively). The general points made were ok though :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-26 17:46:23

David Bolen was heard to say: >Mike Wronski <mwronski@coredump.ae.usr.com> writes: >> Why charge for a service that does not use any extra resources? >> Its not like ISDN or MLPPP that would require a larger investment on the >> part of the ISP. > >While pricing is largely a market driven issue, why would you assume >that it doesn't cost any more to provide 56k on dialup? It seems to >me that you're making assumptions about what constitutes a "resource" >(I'm assuming you're thinking just of the telco access lines). ... What, you think that X2 enable key is free? --Ricky

Subject: Re: (usr-tc) Bad Netserver Card - Looking for Spare??
From: David Bolen <db3l@ans.net>
Date: 1998-10-26 17:49:58

Butch Kemper <kemper@tstar.net> writes: > Just this morning, I started getting these messages from a box (2059 > bundle) with two CT1s, 12 Quad modem cards, and a Netserver.: > > >Oct 26 15:53:10 usr1 MODEM: S42: CALL_REF >0x0b010044< PRI_SLOT >255< TS > > >22< SPAN >255< B_CH >255< > >Oct 26 15:53:10 usr1 acct 0x0b010044 dial: S42 call arrived. > >Oct 26 15:53:10 usr1 sent out answer incoming call for S42. > > The error is happening on many different ports. Sometimes a port fails and > sometime it connects up normally. Watching the syslog, it seems that there > is "shortage" of something because when some line disconnects, another line > will succeccfully connect. I'm not sure what "error" you are referring to in the above. That looks like a perfectly normal sequence of events. The "MODEM:" line is an indication from your circuit card of the call arrival and gives call detail info. The slot/span/b_ch is 255 due to your CT1 (non-PRI) setup. The NETServer gets this information directly from the Dual-T1 card. The "call arrived" is the indication from the quad modem to the NETServer, which the NETServer syslogs. The "answer incoming" is the NETServer logging that it has told the quad modem to go ahead and answer the phone. Unless there are error messages afterwards that you haven't included here, I'm not quite sure what is going wrong. There is one thing I noticed - the Dual-T1 card appears to indicate that the call is using timeslot 22, and the NETServer is indicating it as being port S42. Under default conditions (of both Dual-T1 and NETServer), the physical timeslot (indicated in the syslog) is numbered backwards from 63 for the first modem in slot 2. Thus, timeslot 22 would normally be the second modem in slot 12 (S46), not S42 (which is the second modem in slot 11). So you may want to check your TDM mapping on the Dual-T1 card to ensure that you haven't somehow mapped two DS0s to the same modem or left some unmapped - perhaps if you were changing things around to try to debug a problem. I suppose an alternative might be that you changed the density assignment on your NETServer (a "show modem" should show 4 S ports on each of slots 2-13) and that accounts for the S42 notation. But there's nothing at least in these logs that would seem to indicate any hardware problems or anything. -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: David Bolen <db3l@ans.net>
Date: 1998-10-26 17:59:02

Ricky Beam <jfbeam@Interpath.net> writes: > What, you think that X2 enable key is free? I assume you addressed that to Mike's original comment and not to me, since I didn't claim there were no extra costs (though I didn't highlight the feature key) Then again, of course, yes, it's free for HDM cards, so it does matter what sort of equipment you may already have :-) -- David /-----------------------------------------------------------------------\ \ David Bolen \ Internet: db3l@ans.net / | ANS Communications, Inc. \ Phone: (914) 701-5327 | / 100 Manhattanville Rd, Purchase, NY 10577 \ Fax: (914) 701-5310 \ \-----------------------------------------------------------------------/

Subject: RE: (usr-tc) Problems with brackets in session_start_message
From: Paul Curnock <paul_curnock@pervasive.co.uk>
Date: 1998-10-26 17:59:07

> Mike Wronski was heard to say: > >Have you tried escaping the '(' with back slashes?? > > > >set slip session_start_message "SL/IP session from $%server_ip$ to > >%client_ip beginning..." > > I think I did, but it's been awhile. > > --Ricky [Paul Curnock] I've also been informed today (26th OCT) that this doesn't work? Sorry! > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Radius List's
From: MegaZone <megazone@megazone.org>
Date: 1998-10-26 20:29:05

Once upon a time Terry Kennedy shaped the electrons to say... >that might help us here, I would appeciate someone posting the address's >here or mailing me privately. Point and I shall follow... cistron-radius@info.cistron.nl portmaster-radius@livingston.com radiusabm-users@livingston.com isp-radius@isp-radius.com I believe there are also lists for Merit RADIUS and Emeral (RadiusNT) from IEA. But I don't know those off hand. The IETF list is: ietf-radius@livingston.com -MZ -- <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! ==================================================================== ISPF, The Forum for ISPs by ISPs. October 26-28, 1998, Atlanta, GA. Three days of clues, news, and views from the industry's best and brightest. http://www.ispf.com/ for information and registration. ====================================================================

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Kevin Benton <s1kevin@tims.net>
Date: 1998-10-27 09:17:03

On Mon, 26 Oct 1998, Jeff Mcadams wrote: > argument. :) Even assuming that the user only downloads a set amount > of data...which is a stretch at best, but one I'm willing to run with > for the moment...you yourself pointed out that the user then gets off > the modem faster, freeing it up *for another user*. So...using your > theory...yes, the "capacity" (not bandwidth) used by a specific user > may be the same, but you're able to service more users on the same > number of lines now, so your total capacity needed will *still* go up. > > I guess you could then argue that you would need fewer lines because you > can then increase your user-modem ratio because users are being serviced > more quickly with the faster modems, but that's *really* a stretch. :) In the end, what we get complaints about from users is slow download speeds with their "56k-capable" modems. Sometimes, it's because the pipe feeding the modem isn't big enough to handle it and all the other modems attempting to run at full speed all at once. That's bandwidth. If we had the same number of users downloading information at 28k, we wouldn't need as much bandwidth on our feed pipes even though the same number of people would take longer to download, the aggregate bandwidth required is still less to feed slower modems. Kevin E-Mail: s1kevin@tims.net Web: http://users.sota-oh.com/~s1kevin/ Unsolicited advertisements processing fee: $50 subject to change without notice

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Kirk Mitchell <mitch@keyconn.net>
Date: 1998-10-27 10:20:05

At 04:25 PM 10/26/98 -0500, Jeff McAdams wrote: >OK, here's the specific statement which points out the flaw in your own >argument. :) Even assuming that the user only downloads a set amount >of data...which is a stretch at best, but one I'm willing to run with >for the moment...you yourself pointed out that the user then gets off >the modem faster, freeing it up *for another user*. So...using your >theory...yes, the "capacity" (not bandwidth) used by a specific user >may be the same, but you're able to service more users on the same >number of lines now, so your total capacity needed will *still* go up. With bandwidth as the specific, you're correct, I misspoke myself. With regards to my "overall capacity useage" arguement, I wasn't implying that less capacity was needed, simply that it's not a given that faster modems mean the user will use more resources. Your capacity needs may well go up due to the ability to serve more users faster, but, in the case of the 'specific purpose' users, the resources used per user could be lower. Granted, not everybody logs on for a specific purpose, but a look at the logs for <1hr sessions reveals a number of users that would likely be on and off quicker with a faster modem. >I guess you could then argue that you would need fewer lines because you >can then increase your user-modem ratio because users are being serviced >more quickly with the faster modems, but that's *really* a stretch. :) I may be off-base at times, but even I wouldn't go that far :) Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: (usr-tc) Modem disconnects
From: Gilles Melanson <gilles@vianet.on.ca>
Date: 1998-10-27 11:32:29

Wondering if anyone has seen a problem similar to this: I've added a 4th DSP card to one of my chassis.. and now I'm seeing alot of unexplained disconnects on the modems. The system is comprised of: 4 DSPs (1.2.5) ARC (4.0.30) DMS100 up here, PRIs. I will likely upgrade the DSPs to 1.2.66 shortly, and I'm curious as to what 4.1.x rev is trustworthy. *laf* Anyone, anyone? -- Gilles Melanson ViaNet Internet Solutions System Administrator 128 Larch St. Suite 301 gilles@vianet.on.ca Sudbury, ON Canada P3E 5J8 - "Computationally expensive" is a computer term for "slow"

Subject: Re: (usr-tc) reporting connect speed in radius request VSA's?
From: Lon R. Stockton, Jr. <lon@moonstar.com>
Date: 1998-10-27 12:30:32

On Mon, 26 Oct 1998, Ricky Beam wrote: > What, you think that X2 enable key is free? It is for the clueful (HiPer owners). (:

Subject: (usr-tc) DNS setup
From: Richard Roy <rjroy@nbnet.nb.ca>
Date: 1998-10-28 10:17:31

This is a cryptographically signed message in MIME format. --------------ms07A878C51528B7D7E7A52230 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just want to have your ideas on enabling dns caching on hiperarc. Right now, I'm using the default which is "disable" but I may reconsider my setup. --------------ms07A878C51528B7D7E7A52230 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIHogYJKoZIhvcNAQcCoIIHkzCCB48CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC BcUwggKEMIIB7aADAgECAgI9ljANBgkqhkiG9w0BAQQFADCBuTELMAkGA1UEBhMCWkExFTAT BgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UEBxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRo YXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBUaGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAx Nzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5 OC45LjE2MB4XDTk4MDkzMDEzMjgxNFoXDTk5MDkzMDEzMjgxNFowQzEfMB0GA1UEAxMWVGhh d3RlIEZyZWVtYWlsIE1lbWJlcjEgMB4GCSqGSIb3DQEJARYRcmpyb3lAbmJuZXQubmIuY2Ew XDANBgkqhkiG9w0BAQEFAANLADBIAkEA7ZakokNf/LN0cGOQBtOae4pISp35e8Bow/Dzz046 Ra/sA3fnntd0/a9kSBbBOUR9HCLGztuy2v1tViPr2AYhRQIDAQABo1QwUjARBglghkgBhvhC AQEEBAMCBaAwDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwHwYDVR0jBBgwFoAU/j5g nGuMD7DYM8bKxh5YsHE4teAwDQYJKoZIhvcNAQEEBQADgYEAY2sbsVlzW86LRfekbr267rrc Co2Aa8JTF9f2NEBw9QdMtWyvO8aQ1kyxwjzfo5Fx6j0Vvx9Ajtpx8RYwnMkx5jaqCYcCxxWE tSOhoET3kUVRGNpmrc7da/TGrc33nM8weCEB6gm5v2XEZd1ezHOUPrYFJuL/GJ3vBKnCMkZp WJowggM5MIICoqADAgECAgEKMA0GCSqGSIb3DQEBBAUAMIHRMQswCQYDVQQGEwJaQTEVMBMG A1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xGjAYBgNVBAoTEVRoYXd0 ZSBDb25zdWx0aW5nMSgwJgYDVQQLEx9DZXJ0aWZpY2F0aW9uIFNlcnZpY2VzIERpdmlzaW9u MSQwIgYDVQQDExtUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgQ0ExKzApBgkqhkiG9w0BCQEW HHBlcnNvbmFsLWZyZWVtYWlsQHRoYXd0ZS5jb20wHhcNOTgwOTE2MTc1NTM0WhcNMDAwOTE1 MTc1NTM0WjCBuTELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTEUMBIGA1UE BxMLRHVyYmFudmlsbGUxGjAYBgNVBAoTEVRoYXd0ZSBDb25zdWx0aW5nMSkwJwYDVQQLEyBU aGF3dGUgUEYgUlNBIElLIDE5OTguOS4xNiAxNzo1NTE2MDQGA1UEAxMtVGhhd3RlIFBlcnNv bmFsIEZyZWVtYWlsIFJTQSBJc3N1ZXIgMTk5OC45LjE2MIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDEpeXU1NBfCALuByF9JL+ra44e6yAHAhWEa4/QkyQfG53uaLK5LE/pk2cXEBce oflDQSO5MKp2l7vz5/2BwLUxi/amUCZU8pUo6xmkHpcesOK4m8EEmjLQPAlsT+Q1T/B2vwAT A09FCGDz/LTQkAGKEsmcun9S6iqTNTY8POQ1LwIDAQABozcwNTASBgNVHRMBAf8ECDAGAQH/ AgEAMB8GA1UdIwQYMBaAFHJJwnM0xlX0C3ZygX539IfnxrIOMA0GCSqGSIb3DQEBBAUAA4GB ACzHgh8BQz4Hj+5pXKlkgvjAlq2TK8ubUNdAmoHCuqZ2nTyVQNxVweFVgnmrCimm1QzhVyg+ j/m71d8Nk1iqWy2LjzPk3VgVNXZyFSm9QvRakgt3X50n25otThuCBo7SjVa7ld7bDGUF3pWe At1TF76+/GvDGiJ6FCthvcKfXnpaMYIBpTCCAaECAQEwgcAwgbkxCzAJBgNVBAYTAlpBMRUw EwYDVQQIEwxXZXN0ZXJuIENhcGUxFDASBgNVBAcTC0R1cmJhbnZpbGxlMRowGAYDVQQKExFU aGF3dGUgQ29uc3VsdGluZzEpMCcGA1UECxMgVGhhd3RlIFBGIFJTQSBJSyAxOTk4LjkuMTYg MTc6NTUxNjA0BgNVBAMTLVRoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBSU0EgSXNzdWVyIDE5 OTguOS4xNgICPZYwCQYFKw4DAhoFAKB9MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTk4MTAyODE0MTczMlowHgYJKoZIhvcNAQkPMREwDzANBggqhkiG9w0D AgIBKDAjBgkqhkiG9w0BCQQxFgQUuhX3DwkJBJdxzc+C1U1qho27DhgwDQYJKoZIhvcNAQEB BQAEQLQkjhoMkQifKLXfIhjFQwBSOdV5AgrneaDygCVMfJpHl7ZEQMujOyqBpoMwgA1kiVaU HGUeW+aVKqu4BhadzC4= --------------ms07A878C51528B7D7E7A52230--

Subject: RE: (usr-tc) Problems with brackets in session_start_message
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-28 11:56:11

Subject: RE: (usr-tc) NetServer - error message
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-28 12:18:19

Not quite sure what it means, other than a possible memory leak, but I do know those message won't stop unless you reboot. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Experts in Remote Access; NetWork Design; Security; Implementation = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Martins Erts Sent: Wednesday, October 28, 1998 11:01 AM Hello, sometimes we get following messages on our Netserver: remote_slifrecv: Limited expansion room - packet lost Is it shortage of memory and what can I do about it? Command> show mem Total physical RAM: 16384 kb Total physical FLASH: 4096 kb System memory 12551087 bytes - 7057696 used, 5493391 available Free blocks (block_size:count): 16:1 32:57 48:18 64:1 80:4 112:1 128:17 144:19 160:18 176:18 208:24 224:1 240:2 256:4 272:2 288:2 304:8 320:1 336:1 640:1 1168:1 1280:0 1984:19 4160:16 4208:3 8208:5 16400:5 20384:16 Real Available Memory: 6086351 System nbufs 1000 - 10 used, 990 available Command> -- Martins - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Problems with brackets in session_start_message
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-28 13:21:33

Mike Wronski was heard to say: >You said you reported it. Whats the ticket number? It was reported during BETA... there is no ticket number. And without a valid support contract the support monkeys will hang up on me -- they have in the past. --Ricky

Subject: RE: (usr-tc) Problems with brackets in session_start_message
From: Paul Curnock <paul_curnock@pervasive.co.uk>
Date: 1998-10-28 18:07:11

A nice chap from 3Com is working on it at the moment, but just for reference the ticket number is 920881 Paul Curnock > -----Original Message----- > From: Mike Wronski [SMTP:mike@coredump.ae.usr.com] > Sent: 28 October 1998 17:56 > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Problems with brackets in session_start_message > > |-----Original Message----- > |From: owner-usr-tc@lists.xmission.com > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Paul Curnock > |Sent: Monday, October 26, 1998 11:59 AM > |To: 'usr-tc@lists.xmission.com' > |Subject: RE: (usr-tc) Problems with brackets in session_start_message > | > | > |> Mike Wronski was heard to say: > |> >Have you tried escaping the '(' with back slashes?? > |> > > |> >set slip session_start_message "SL/IP session from $%server_ip$ to > |> >%client_ip beginning..." > |> > |> I think I did, but it's been awhile. > |> > |> --Ricky > | [Paul Curnock] > | > | I've also been informed today (26th OCT) that this doesn't work? > |Sorry! > > You said you reported it. Whats the ticket number? > > > -M > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Netserver - error message
From: Martins Erts <ouch@latnet.lv>
Date: 1998-10-28 19:00:49

Hello, sometimes we get following messages on our Netserver: remote_slifrecv: Limited expansion room - packet lost Is it shortage of memory and what can I do about it? Command> show mem Total physical RAM: 16384 kb Total physical FLASH: 4096 kb System memory 12551087 bytes - 7057696 used, 5493391 available Free blocks (block_size:count): 16:1 32:57 48:18 64:1 80:4 112:1 128:17 144:19 160:18 176:18 208:24 224:1 240:2 256:4 272:2 288:2 304:8 320:1 336:1 640:1 1168:1 1280:0 1984:19 4160:16 4208:3 8208:5 16400:5 20384:16 Real Available Memory: 6086351 System nbufs 1000 - 10 used, 990 available Command> -- Martins

Subject: (usr-tc) Interesting buglet...
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-28 21:45:25

I seem to have a chassis that refuses to allow MLPPP! It doesn't seem to care which version of code is running on anything and the configuration is line for line identical to all the other systems in our network. I've even tried swapping the netserver and still does this crap. Anyone else seen this before? I moved a functional (3.7.24) netserver into that rack and it worked fine. So, it's gotta be something funky with that Netserver and/or configuration. (This is the "beta test" card, so there's no telling what kind of hell is in it's flash :-)) --Ricky

Subject: RE: (usr-tc) Interesting buglet...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-28 22:42:19

How are the ports configured? Are they Network Hardwired? ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Experts in Remote Access; NetWork Design; Security; Implementation = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam Sent: Wednesday, October 28, 1998 8:45 PM I seem to have a chassis that refuses to allow MLPPP! It doesn't seem to care which version of code is running on anything and the configuration is line for line identical to all the other systems in our network. I've even tried swapping the netserver and still does this crap. Anyone else seen this before? I moved a functional (3.7.24) netserver into that rack and it worked fine. So, it's gotta be something funky with that Netserver and/or configuration. (This is the "beta test" card, so there's no telling what kind of hell is in it's flash :-)) --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.

Subject: Re: (usr-tc) Interesting buglet...
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-28 23:01:17

Brian K McIntire was heard to say: >How are the ports configured? >Are they Network Hardwired? set all login network twoway device /dev/network -- It's the "twoway" part that's breaking MLPPP. Strange that I've never noticed that. --Ricky

Subject: RE: (usr-tc) Interesting buglet...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-28 23:12:59

yes, it is set the ports to network dialin reset all save all I should work ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Experts in Remote Access; NetWork Design; Security; Implementation = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Ricky Beam Sent: Wednesday, October 28, 1998 10:01 PM Brian K McIntire was heard to say: >How are the ports configured? >Are they Network Hardwired? set all login network twoway device /dev/network -- It's the "twoway" part that's breaking MLPPP. Strange that I've never noticed that. --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.

Subject: Re: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
Date: 1998-10-28 23:44:34

Interproc.ae.usr.com is up and running if you have problems with name the ip is 207.24.169.174 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, 29 Oct 1998, Blake Fithen wrote: > Hello. Does any one know what the latest information is on the > Quake lag issues with HiperARC and Netserver. Interproc seems > unreachable right now and I forgot the address for the archives > for this list - usr-tc.datasys.net? > > thanks for you time. > > blake > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: (usr-tc) Netserver not accepting calls
From: Andrew Aken <ajaken@globaleyes.net>
Date: 1998-10-29 06:48:22

In the process of moving a previously working TCH with a Netserver to replace a TCH with a HiPer ARC at a remote POP, the Netserver would no longer authenticate users. In the process, the Netserver hub's NMC was replaced by the NMC from the HiPer chassis. The network segment also changed. The IP address and Netmask of the Netserver were changed to the new segment as well as the starting address of the IP pool. I could watch users attempting to logon with the sh ses command via telnet, but the status would remain AUTHENTICATING until the session dropped. The Radius servers are still in the original segment and can be pinged from the telnet session. Does anyone have any suggestions for what I may be missing? -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

Subject: Re: (usr-tc) Netserver not accepting calls
From: Andrew Aken <ajaken@globaleyes.net>
Date: 1998-10-29 07:00:16

Never mind... An idiot with no sleep forgot to update the Radius clients file with the new IP address... Andrew Aken wrote: > > In the process of moving a previously working TCH with a Netserver to > replace a TCH with a HiPer ARC at a remote POP, the Netserver would no > longer authenticate users. In the process, the Netserver hub's NMC was > replaced by the NMC from the HiPer chassis. The network segment also > changed. The IP address and Netmask of the Netserver were changed to the > new segment as well as the starting address of the IP pool. > > I could watch users attempting to logon with the sh ses command via > telnet, but the status would remain AUTHENTICATING until the session > dropped. The Radius servers are still in the original segment and can be > pinged from the telnet session. > > Does anyone have any suggestions for what I may be missing? > -- > ======================================================= > =========== Andrew Aken - President ========= > ====== GlobalEyes Communications, Inc. ====== > =Southern Illinois' Fastest Connection to the Internet= > ========== http://www.GlobalEyes.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. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

Subject: (usr-tc) Most Stable Modem Code (HDM)
From: Brian <signal@shreve.net>
Date: 1998-10-29 08:43:00

What are you all finding the most stable modem code to be? Right now, we are running 1.2.5 relase code, but I am not convinced that is the best to be running. We have seen here, the problem where you dial, and the modem does not send carrier, i guess it may be what some are calling the "dead air" problem. I am *very* interested in ER code that addresses this and the lt winmodem problem (lucent). I know the lucent problem is a client side problem, but still, if their is anything that can be done to make things better. So whats the best Release/ER HDM code out their? Once I find out what it is, I will try to get my hands on it. Also we are running 4.1.11 release ARC code. Have any of you found ER code that works better and good reason to use that ER code over release code? One issue I have seen with ARC code (and this goes on for many releases) is that the ARC will place some interfaces "down" sometimes, when they shouldn't be, this results in a busy, and the fix is to try and re-enable the interfaces, which may or may not work, it may require a hard reset of the card. Brian Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Interesting buglet...
From: Brian <signal@shreve.net>
Date: 1998-10-29 08:45:29

On Wed, 28 Oct 1998, Ricky Beam wrote: > I seem to have a chassis that refuses to allow MLPPP! It doesn't seem > to care which version of code is running on anything and the configuration > is line for line identical to all the other systems in our network. > > I've even tried swapping the netserver and still does this crap. > > Anyone else seen this before? I have, but it was with a netserver not an ARC (is it a netserver?). The problem was the clock chip on the netserver. The clock/time as you know is essential to MLPPP operation at least in the netserver enviroment. Can you check the date/time on the netserver, and ensure it is keeping its time withing 3 seconds of the other netservers? I think its 2-3 seconds is the threshold for proper MLPPP operation. > > I moved a functional (3.7.24) netserver into that rack and it worked fine. > So, it's gotta be something funky with that Netserver and/or configuration. > (This is the "beta test" card, so there's no telling what kind of hell is > in it's flash :-)) really, make sure you wash your hands after handling it, you dont want it spreading to your other chassis :) > > --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. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: Re: (usr-tc) Netserver not accepting calls
From: Brian <signal@shreve.net>
Date: 1998-10-29 08:47:26

On Thu, 29 Oct 1998, Andrew Aken wrote: > In the process of moving a previously working TCH with a Netserver to > replace a TCH with a HiPer ARC at a remote POP, the Netserver would no > longer authenticate users. In the process, the Netserver hub's NMC was > replaced by the NMC from the HiPer chassis. The network segment also > changed. The IP address and Netmask of the Netserver were changed to the > new segment as well as the starting address of the IP pool. > > I could watch users attempting to logon with the sh ses command via > telnet, but the status would remain AUTHENTICATING until the session > dropped. The Radius servers are still in the original segment and can be > pinged from the telnet session. > > Does anyone have any suggestions for what I may be missing? 1. make sure your radius clients list, has the correct IP for the netserver. 2. make sure the secret is correct on both ends of the RADIUS link. 3. make sure the authentication scheme is correct (pap?) Brian > -- > ======================================================= > =========== Andrew Aken - President ========= > ====== GlobalEyes Communications, Inc. ====== > =Southern Illinois' Fastest Connection to the Internet= > ========== http://www.GlobalEyes.net ======== > ======================================================= > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1

Subject: RE: (usr-tc) Interesting buglet...
From: Mike Wronski <mike@coredump.ae.usr.com>
Date: 1998-10-29 09:28:29

|-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Thursday, October 29, 1998 8:45 AM |To: USR Total Control List |Subject: Re: (usr-tc) Interesting buglet... | | |On Wed, 28 Oct 1998, Ricky Beam wrote: | |> I seem to have a chassis that refuses to allow MLPPP! It doesn't seem |> to care which version of code is running on anything and the configuration |> is line for line identical to all the other systems in our network. |> |> I've even tried swapping the netserver and still does this crap. |> |> Anyone else seen this before? | |I have, but it was with a netserver not an ARC (is it a netserver?). The |problem was the clock chip on the netserver. The clock/time as you know |is essential to MLPPP operation at least in the netserver enviroment. I think you mean MPIP here. There is no clock sync between Netservers required for MLPPP. Only the cross-chassls MLPPP or MPIP. -M

Subject: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Blake Fithen <fithen@networksplus.net>
Date: 1998-10-29 09:49:45

Hello. Does any one know what the latest information is on the Quake lag issues with HiperARC and Netserver. Interproc seems unreachable right now and I forgot the address for the archives for this list - usr-tc.datasys.net? thanks for you time. blake

Subject: Re: (usr-tc) Most Stable Modem Code (HDM)
From: Andrew Aken <ajaken@globaleyes.net>
Date: 1998-10-29 09:58:58

Not sure about the most stable code, but there is a "fix" from Lucent for the LTWinmodem problem. You can download it at ftp://guest:GlobalEyes@ftp.globaleyes.net/updates/v.90/ltwinmodem523t.exe . This at least allows the modems to connect to our TCH's, although generally not at v.90 speeds. Brian wrote: > > What are you all finding the most stable modem code to be? > > Right now, we are running 1.2.5 relase code, but I am not convinced that > is the best to be running. > > We have seen here, the problem where you dial, and the modem does not send > carrier, i guess it may be what some are calling the "dead air" problem. > I am *very* interested in ER code that addresses this and the lt winmodem > problem (lucent). I know the lucent problem is a client side problem, but > still, if their is anything that can be done to make things better. > > So whats the best Release/ER HDM code out their? Once I find out what it > is, I will try to get my hands on it. > > Also we are running 4.1.11 release ARC code. Have any of you found ER > code that works better and good reason to use that ER code over release > code? > > One issue I have seen with ARC code (and this goes on for many releases) > is that the ARC will place some interfaces "down" sometimes, when they > shouldn't be, this results in a busy, and the fix is to try and re-enable > the interfaces, which may or may not work, it may require a hard reset of > the card. > > Brian > > -------------------------------------------------------------------------- > Brian Feeny (BF304) | ShreveNet Inc. - Premium Internet Service Provider > Network Administrator | Shreveport, Louisiana - http://www.shreve.net/ > signal@shreve.net | Web Hosting, Virtual Domains, Storefronts, > (318)222-2NET x 109 | Database/Web Integration, 56k, ISDN, T1 > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. -- ======================================================= =========== Andrew Aken - President ========= ====== GlobalEyes Communications, Inc. ====== =Southern Illinois' Fastest Connection to the Internet= ========== http://www.GlobalEyes.net ======== =======================================================

Subject: Re: (usr-tc) Quad Modem Question?
From: Jack Singer <jsinger@usacars.com>
Date: 1998-10-29 10:08:18

How do you tell the difference between single and double sided quad modems. The manual says it uses different software if you have one or the other. Jack. jsinger@i-c.net

Subject: Re: (usr-tc) Quad Modem Question?
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-29 10:10:29

Thus spake Jack Singer >How do you tell the difference between single and double sided quad modems. >The manual says it uses different software if you have one or the other. You can either pull the cards and look at them (double-sided have chips on both sides of the circuit card...thus the name), or if you're using TCM, you can just trust TCM to figure it out for you...I've never had it fail me there, so I feel pretty comfortable in doing that. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) MPIP hates me
From: Scott Goettsch <sgoth@ionet.net>
Date: 1998-10-29 10:12:37

We have a large TCH modem pool (over 1000 ports) containing a mix of quads, DSPs, Netservers, and ARCs. Untill the first of this week we had our mpip master on a netserver. We decided to improve things a bit, plus we had a spare ARC, and move the mpip server over to an ARC. We disabled mpip server on the netserver, removed the mpip server settings in all the clients, set up a mpip server on the ARC, added all the clients in to it, and set up all the clients with the new mpip server and secret. We then dialed in with the TA we have at the office and rejoiced when we achieved a 2B connect. The next moring our tech support call center started getting an abnormal amount of ISDN calls. I then started checking into things and decided to dial into our POP with my TA. I then discovered I could not even achieve a 1B connect, much less a 2b. So I dialed in and dialed in some more. I was able to get 1b and 2b connects if I hit an ARC, but I got an error message (629 in Win95) if I hit a Netserver. This distressed me greatly. The issue was not apparent at first because our ARCs are towards the end of our rollover, and at night everyone was logging into an ARC. To make sure ISDN was woking on our netservers I turned mpip off on one of them and dialed directly into it. I was able to connect. Turned mpip back on and I could not even connect one channal to the same netserver. I then double checked everything. IPs, shared secrets, all mpip settings. Our ARCs are in a diffrent network than our netservers and everything else due to the ARCs sending over a hundred ICMP redirects instead of just one. We then put the netserver I had been dialing into in the same network as the ARCs, and added the new client to the mpip master. I still could not connect. After that, I readdressed the netserver to the old IP. Next, I turned debug mode on in the netserver, captured an output, and ran it through Livingston's decoder. This is what it spat out: Sending LCP_CONFIGURE_REQUEST to port I0 of 29 bytes containing: 01 01 00 1D 01 04 05 DC 11 04 05 DC 13 03 00 05 06 CF 23 CA 3F 07 02 08 02 03 04 C0 23 Packet Info: Code: 0x01, ID: 0x01, 29 bytes. Maximum-Receive-Unit [0x01], length: (4 bytes) 1500 bytes [0x05DC] Multilink-MRRU [0x11], length: (4 bytes), [0x05DC] Max-Receive-Reconstructed-Unit (MRRU): 1500 bytes. Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00] Class [0x00]: Null Class Null Address Magic-Number [0x05], length: (6 bytes), [0xCF23CA3F] Protocol-Field-Compression [0x07], length: (2 bytes) Address-and-Control-Field-Compression [0x08], length: (2 bytes) Authentication-Protocol [0x03], length: (4 bytes), Password Authentication Protocol [0xC023] Received LCP_CONFIGURE_ACK on port I0 of 25 bytes containing: 02 01 00 1D 01 04 05 DC 11 04 05 DC 13 03 00 05 06 CF 23 CA 3F 07 02 08 02 03 04 C0 23 Packet Info: Code: 0x02, ID: 0x01, 29 bytes. Maximum-Receive-Unit [0x01], length: (4 bytes) 1500 bytes [0x05DC] Multilink-MRRU [0x11], length: (4 bytes), [0x05DC] Max-Receive-Reconstructed-Unit (MRRU): 1500 bytes. Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00] Class [0x00]: Null Class Null Address Magic-Number [0x05], length: (6 bytes), [0xCF23CA3F] Protocol-Field-Compression [0x07], length: (2 bytes) Address-and-Control-Field-Compression [0x08], length: (2 bytes) Authentication-Protocol [0x03], length: (4 bytes), Password Authentication Protocol [0xC023] Received LCP_CONFIGURE_REQUEST on port I0 of 19 bytes containing: 01 04 00 17 01 04 05 DC 07 02 08 02 11 04 05 DC 13 07 04 54 58 1C 00 Packet Info: Code: 0x01, ID: 0x04, 23 bytes. Maximum-Receive-Unit [0x01], length: (4 bytes) 1500 bytes [0x05DC] Protocol-Field-Compression [0x07], length: (2 bytes) Address-and-Control-Field-Compression [0x08], length: (2 bytes) Multilink-MRRU [0x11], length: (4 bytes), [0x05DC] Max-Receive-Reconstructed-Unit (MRRU): 1500 bytes. Multilink-Endpoint-Discriminator [0x13], length: (7 bytes), [0x0454581C00] Class [0x04]: PPP Magic-Number Block 54 58 1C 00 Sending LCP_CONFIGURE_ACK to port I0 of 23 bytes containing: 02 04 00 17 01 04 05 DC 07 02 08 02 11 04 05 DC 13 07 04 54 58 1C 00 Packet Info: Code: 0x02, ID: 0x04, 23 bytes. Maximum-Receive-Unit [0x01], length: (4 bytes) 1500 bytes [0x05DC] Protocol-Field-Compression [0x07], length: (2 bytes) Address-and-Control-Field-Compression [0x08], length: (2 bytes) Multilink-MRRU [0x11], length: (4 bytes), [0x05DC] Max-Receive-Reconstructed-Unit (MRRU): 1500 bytes. Multilink-Endpoint-Discriminator [0x13], length: (7 bytes), [0x0454581C00] Class [0x04]: PPP Magic-Number Block 54 58 1C 00 **** I0: LCP Open Received PAP_AUTH_REQ on port I0 of 18 bytes containing: 01 05 00 12 06 62 72 74 65 73 74 06 67 30 30 62 65 72 Packet Info: Code: 0x01, ID: 0x05, 18 bytes. Peer-ID: brtest (6 bytes), [0x627274657374] Password: g00ber (6 bytes), [0x673030626572] Connection Failed I then set up syslog and had the netserver send it info. This is some of the logged messages: Oct 28 14:26:56 okcnas9 PRI: I0: CALL_REF >0x00001663< PRI_SLOT >0< TS >14< SPAN >1< B_CH >23< Oct 28 14:26:59 okcnas9 acct 0x00001663 dialnet: port I0 PPP succeeded dest Negotiated Oct 28 14:27:01 okcnas9 dialnet: port I0 ppp_sync failed dest Oct 28 14:27:09 okcnas9 MPIP: no response from server #0 (38.193.0.142) Oct 28 14:27:09 okcnas9 MPIPRegisterLink: None of the configured MPIP Servers responded After that, I tipple checked everything. If I hit an arc I could get a bonded 2b mpip connection, but nothing at all if I hit a netserver. The day had almost ended with mpip still broken so we implemented a mcgyver fix. We set the netserver that was running mpip server back up as a mpip server. We then added all the other netservers as clients. On the netservers we set the mpip netserver as the secondary mpip server, so they now have two mpip masters. This worked, sort of. If the first B hits a netserver it will log in, but the second B will only connect if it too hits a netserver. If the first B hits an ARC, the second B will only connect if it too hits an ARC. We are running 4.1.78-4 ER on the HiPerARCs, 3.8.1 on the netservers, and the TA is a USR courier I. Any help would be very apreciated. Thank you for taking the time to read this. sgoth sgoth@ionet.net ioNET Network Specialist http://www.ionet.net/~sgoth Quake 2 Administrator 1.800.360.5183

Subject: Re: (usr-tc) WTB Total Control Units
From: Jack Singer <jsinger@usacars.com>
Date: 1998-10-29 10:23:30

Sorry if this is the wrong place to post. I need used Total Control Units. Hyper boxes with or without modems. Quad boxes with our wihtout modems. Jack Singer (800) 224-3806 jsinger@i-c.net

Subject: Re: (usr-tc) WTB Total Control Units
From: t----hiller <hiller@interaccess.com>
Date: 1998-10-29 10:44:07

We have two HiPer Chassis and two TC Chassis, bare except for NICs. Please make an offer. t o n y h i l l e r Interaccess Network Ops thiller@interaccess.com On Thu, 29 Oct 1998, Jack Singer wrote: > Sorry if this is the wrong place to post. > I need used Total Control Units. > Hyper boxes with or without modems. > Quad boxes with our wihtout modems. > > Jack Singer > (800) 224-3806 > jsinger@i-c.net > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Subject: RE: (usr-tc) Quad Modem Question?
From: Sys Mgr - BrunNet <"stainforth, matthew (sys mgr - brunnet)">
Date: 1998-10-29 11:22:50

On Thursday, October 29, 1998 11:08 AM, Jack Singer [SMTP:jsinger@usacars.com] wrote: > How do you tell the difference between single and double sided quad modems. > The manual says it uses different software if you have one or the other. Pull them out and look at them. Double sided quads have chips on both sides of the card. Single sided ones don't. Be Seeing You... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Matthew Stainforth<>Technical Services Manager<>BrunNet Inc.<>(506)450-4562 A quart of wheat for a day's wages, and three quarts of barley for a day's wages, and do not damage the oil and the wine! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-29 13:20:25

The latest is: The HiPer ARC has no known or I should say no disclosed issues relating to Quake. The NetServer does. Unfortunately, based on my own testing, so does the HiPer DSP's. The HiPer DSP's are being fine tuned to handle quake better. The problem is not hardware related. Interim fix: Use quads with the HiPer ARC. It works great. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Experts in Remote Access; NetWork Design; Security; Implementation = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Blake Fithen Sent: Thursday, October 29, 1998 10:50 AM Hello. Does any one know what the latest information is on the Quake lag issues with HiperARC and Netserver. Interproc seems unreachable right now and I forgot the address for the archives for this list - usr-tc.datasys.net? thanks for you time. blake - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) Interesting buglet...
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-29 13:20:26

For those of you that did not get the fix for this the NetServer ports were configured for two-way. You can not establish mppp on two-way ports. ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = Experts in Remote Access; NetWork Design; Security; Implementation = = Serving North America and parts of Canada. Reselling to the world. = ======================================================================= -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Mike Wronski Sent: Thursday, October 29, 1998 9:28 AM |-----Original Message----- |From: owner-usr-tc@lists.xmission.com |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Brian |Sent: Thursday, October 29, 1998 8:45 AM |To: USR Total Control List |Subject: Re: (usr-tc) Interesting buglet... | | |On Wed, 28 Oct 1998, Ricky Beam wrote: | |> I seem to have a chassis that refuses to allow MLPPP! It doesn't seem |> to care which version of code is running on anything and the configuration |> is line for line identical to all the other systems in our network. |> |> I've even tried swapping the netserver and still does this crap. |> |> Anyone else seen this before? | |I have, but it was with a netserver not an ARC (is it a netserver?). The |problem was the clock chip on the netserver. The clock/time as you know |is essential to MLPPP operation at least in the netserver enviroment. I think you mean MPIP here. There is no clock sync between Netservers required for MLPPP. Only the cross-chassls MLPPP or MPIP. -M - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) Interesting buglet...
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-29 13:30:50

Brian K McIntire was heard to say: >For those of you that did not get the fix for this the NetServer ports were >configured for two-way. You can not establish mppp on two-way ports. That explains the behavior, but it does not explain why. The netserver can create a dialout MLPPP bundle, right? --Ricky

Subject: Re: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Aaron Nabil <nabil@spiritone.com>
Date: 1998-10-29 16:17:19

Brett Murphy writes... >Brian K McIntire wrote: > >> The latest is: >> The HiPer ARC has no known or I should say no disclosed issues relating to >> Quake. The NetServer does. Unfortunately, based on my own testing, so does >> the HiPer DSP's. The HiPer DSP's are being fine tuned to handle quake >> better. The problem is not hardware related. >> Interim fix: >> Use quads with the HiPer ARC. It works great. > >The only problem we have had with HyperDSP/HyperARC and quake is thatstac >compression causes very bad lag. Once this was disabled on the HyperARC >the users were very happy. Which compression? -a

Subject: (usr-tc) LAN to LAN routing
From: Blake Fithen <fithen@networksplus.net>
Date: 1998-10-29 17:49:49

Hello, we have a ISDN customer that we are trying to setup on what 3COM techs describe as LAN-to-LAN routing scenario. In non-fluff terms we want to give them a /27 and have them connect to an ARC who's eth:1 is on a different /27. We want their LAN workstations and their WAN port to have to have static (pingable from the Internet) addresses on their LAN from their /27. They are using a Pipeline 75. We'd use NAT but we need more that 10 static address translations. Although this is an atypical routing setup I'm certain it's possible - or am I dreaming? So far I've given 3Com 4 hours of phone time to work this out and we haven't made much progress. Any suggestions? blake

Subject: Re: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Jeff Mcadams <jeffm@iglou.com>
Date: 1998-10-29 20:24:57

Thus spake Jason_Kelton@3com.com [couple of suggestions deleted] >* disable tcp nagle (on HARC) This improves UDP performance by removing the >tcp nagle (buffering I believe) algorithm nagle won't get you anything for Quake...its only a tcp thing, and (to my knowledge at least) Quake is UDP only [couple more deleted] >* Set the MTU to 576 and the RWIN to 536 and a window size of 4 (for 28K) >or 6-8 for 56K. Since Quake uses lot's of small packets (that's why its hard on access servers) I doubt the MTU is gonna get you anything...Quake will proly never hit it to begin with. >* Set the TTL to 64 or 128. Again, not gonna get you anything...number of IP hops affecting Quake? I'd be interested in seeing a theory on why this would help. :) None of these things will *hurt*, but if they help, I'd be *extremely* surprised, and *really* hesitant to use anymore 3Com code if these things affect it...also might be hesitant to use Livingston^WLucent code since 3Com derived their code from it, though, from what I understand, Lucent has/had no problems with it. *shrug* -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456

Subject: (usr-tc) as5100 - am i crazy?
From: bryan s. blank <bryan@supernet.net>
Date: 1998-10-30 08:29:40

hi there, we're about to pick up an as5100/old tc at a very good price, and chances are good that we'll buy more if they work out well. interested in any comments on experience with these units, i'm actually really looking forward to playing with them, us robotics on the modem, cisco on the router, doesn't get much better than that. it sounds like i have to run 4 ethernets to every 48 ports which is kind of lousy. i've done ppp with cisco before. just interested in what people have to say about this box. thanks! |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-30 08:40:25

Is your configuration default or have you done something special? -----Original Message----- [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Robert von Bismarck Sent: Friday, October 30, 1998 3:25 AM What's that about HiPerDSP not handling quake well ?? I have a DSP/HARC-only environment and quake2 is lovely (quake pings at about 50-60 with ISDN and 80-100 with analog). I'm running 4.0.29 on the HARC's and 1.2.5 on the DSP's with E1/PRI's off a Siemens EWSD switch.... Users are happy like never before (we average 30 users on quake every second evening...) Robert > -----Original Message----- > From: Brian K McIntire [SMTP:bmcintire@commnet.com] > Sent: Thursday, October 29, 1998 8:20 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600 > > The latest is: > The HiPer ARC has no known or I should say no disclosed issues > relating to > Quake. The NetServer does. Unfortunately, based on my own testing, > so does > the HiPer DSP's. The HiPer DSP's are being fine tuned to handle quake > better. The problem is not hardware related. > Interim fix: > Use quads with the HiPer ARC. It works great. > ====================================================================== > = > = Brian K. McIntire bmcintire@commnet.com > = > = Systems Engineer III 317-558-5050 x113 > = > = CommNetPlus, Indianapolis, IN http://www.commnet.com > = > = Experts in Remote Access; NetWork Design; Security; Implementation > = > = Serving North America and parts of Canada. Reselling to the world. > = > ====================================================================== > = > > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Blake Fithen > Sent: Thursday, October 29, 1998 10:50 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600 > > > Hello. Does any one know what the latest information is on the > Quake lag issues with HiperARC and Netserver. Interproc seems > unreachable right now and I forgot the address for the archives > for this list - usr-tc.datasys.net? > > thanks for you time. > > blake > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) Re: MPIP hates me
From: Mark Lemmert <cto@athenet.net>
Date: 1998-10-30 09:41:37

I am having MPIP issues between my Netservers and HyperARCs but somewhat different. I upgraded to TCS 3.3 to get MPIP between Netserver's and HyperARCs and ever since I did there have been problems. MPIP doesn't work between the two platforms. I dial with a Courier I and I see one channel connect to a Netserver and one to a HyperARC and after 10 seconds or so both disconnect. The syslog info doesn't given any reason for the disconection. MPIP between netservers also no longer works properly. When I connect across two Netservers I encounter major throughput problems, my transfer rates are only at around 16kbps. I've got a case open on this and 3com has had me put on several emergency code releases on the HyperARC (the lastest being 4.1.72) and nothing seems to fix it. 3com is stating that this is a code problem. If that is the case then this must not be working anywhere. Does anybody have MPIP working properly betweeen Netserver's and HyperARCs? Mark Lemmert cto@athenet.net Chief Technical Officer (920)954-9799 AthEnet Data Exchange http://www.athenet.net

Subject: Re: (usr-tc) as5100 - am i crazy?
From: System Administrator <jamie-tc@atconnex.net>
Date: 1998-10-30 09:45:36

At 08:29 AM 10/30/98 -0500, you wrote: > hi there, we're about to pick up an as5100/old tc at a very good price, > and chances are good that we'll buy more if they work out well. > interested in any comments on experience with these units, i'm > actually really looking forward to playing with them, us > robotics on the modem, cisco on the router, doesn't get much > better than that. it sounds like i have to run 4 ethernets to > every 48 ports which is kind of lousy. i've done ppp with cisco > before. just interested in what people have to say about this > box. thanks! >|o|----------------------------------------------------------------------|o| >|o| bryan s. blank (203)-351-1178 voice |o| >|o| senior systems analyst (203)-351-1186 fax |o| >|o| discovernet, incorporated (203)-979-5126 emerg |o| Hi, I bought one of these little boxes (hardly :) ) and found the following points to be true: * its a serious bitch to setup (Im no idiot, and it took me 2 weeks) * requires 4 10BaseT for each frame * most questions require two tech support teams to answer * runs like a piece of granite when you have it running! After all the hassle this box caused me, I am surprised at how much I love it. It seems to be a case of major synergy. I worked hard to make it happen, but now it runs without any interference from me! If you need tips and tricks on this box or would like to hear some pre-war horror and post-war rejoicing, drop me a line. J ========================================== James Arlen SysAdmin At Connex Internet www.atconnex.net 519-836-8777

Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-10-30 10:24:39

What's that about HiPerDSP not handling quake well ?? I have a DSP/HARC-only environment and quake2 is lovely (quake pings at about 50-60 with ISDN and 80-100 with analog). I'm running 4.0.29 on the HARC's and 1.2.5 on the DSP's with E1/PRI's off a Siemens EWSD switch.... Users are happy like never before (we average 30 users on quake every second evening...) Robert > -----Original Message----- > From: Brian K McIntire [SMTP:bmcintire@commnet.com] > Sent: Thursday, October 29, 1998 8:20 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600 > > The latest is: > The HiPer ARC has no known or I should say no disclosed issues > relating to > Quake. The NetServer does. Unfortunately, based on my own testing, > so does > the HiPer DSP's. The HiPer DSP's are being fine tuned to handle quake > better. The problem is not hardware related. > Interim fix: > Use quads with the HiPer ARC. It works great. > ====================================================================== > = > = Brian K. McIntire bmcintire@commnet.com > = > = Systems Engineer III 317-558-5050 x113 > = > = CommNetPlus, Indianapolis, IN http://www.commnet.com > = > = Experts in Remote Access; NetWork Design; Security; Implementation > = > = Serving North America and parts of Canada. Reselling to the world. > = > ====================================================================== > = > > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Blake Fithen > Sent: Thursday, October 29, 1998 10:50 AM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600 > > > Hello. Does any one know what the latest information is on the > Quake lag issues with HiperARC and Netserver. Interproc seems > unreachable right now and I forgot the address for the archives > for this list - usr-tc.datasys.net? > > thanks for you time. > > blake > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) LAN to LAN routing
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1998-10-30 10:33:27

I have never done this with ARC's (don't have them) we do it with Netservers no problem. Customer uses a 3Com Office Connect Netbuilder router to dial up via isdn. If you need general routing help, give me a shout, like I said, don't know the ARC but should be no probs. Phil -----Original Message----- From: Blake Fithen [mailto:fithen@networksplus.net] Sent: Thursday, October 29, 1998 11:50 PM To: 'usr-tc@lists.xmission.com' Subject: (usr-tc) LAN to LAN routing Hello, we have a ISDN customer that we are trying to setup on what 3COM techs describe as LAN-to-LAN routing scenario. In non-fluff terms we want to give them a /27 and have them connect to an ARC who's eth:1 is on a different /27. We want their LAN workstations and their WAN port to have to have static (pingable from the Internet) addresses on their LAN from their /27. They are using a Pipeline 75. We'd use NAT but we need more that 10 static address translations. Although this is an atypical routing setup I'm certain it's possible - or am I dreaming? So far I've given 3Com 4 hours of phone time to work this out and we haven't made much progress. Any suggestions? blake - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) as5100 - am i crazy?
From: bryan s. blank <bryan@supernet.net>
Date: 1998-10-30 10:50:09

|o| I bought one of these little boxes (hardly :) ) and found the following |o| points to be true: |o| |o| * its a serious bitch to setup (Im no idiot, and it took me 2 weeks) that's cool. we already know the modem side, and the cisco side is actually fun for me. will be interesting, at least. |o| * requires 4 10BaseT for each frame that's the big bummer. |o| * most questions require two tech support teams to answer *grin* ... |o| * runs like a piece of granite when you have it running! glad to hear that ... terribly glad to hear that ... |o| After all the hassle this box caused me, I am surprised at how much I love |o| it. It seems to be a case of major synergy. I worked hard to make it |o| happen, but now it runs without any interference from me! that's great. |o| If you need tips and tricks on this box or would like to hear some pre-war |o| horror and post-war rejoicing, drop me a line. certainly, would be interested in any sample configs, tips, anything! ... |o|----------------------------------------------------------------------|o| |o| bryan s. blank (203)-351-1178 voice |o| |o| senior systems analyst (203)-351-1186 fax |o| |o| discovernet, incorporated (203)-979-5126 emerg |o|

Subject: Re: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Brett Murphy <sysadmin@alphalink.com.au>
Date: 1998-10-30 10:50:12

Brian K McIntire wrote: > The latest is: > The HiPer ARC has no known or I should say no disclosed issues relating to > Quake. The NetServer does. Unfortunately, based on my own testing, so does > the HiPer DSP's. The HiPer DSP's are being fine tuned to handle quake > better. The problem is not hardware related. > Interim fix: > Use quads with the HiPer ARC. It works great. The only problem we have had with HyperDSP/HyperARC and quake is thatstac compression causes very bad lag. Once this was disabled on the HyperARC the users were very happy. <snip> -- 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.

Subject: Re: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: jason_kelton@3com.com
Date: 1998-10-30 10:51:11

Guys, There are a number of things you can do to decrease quake lag.... We have been working with Wireplay both in the UK and Australia to help fine tune this process. Some hints (most of you probably know this already).... Although these are aimed at dedicated MP gaming chassis - hence, may impact on TCP performance. * Set the frame-rate (CL_MAXFPS) of customers Quake systems to 31 or lower. The default is 90 (blows performance) * Set the Rate (download) for Quake to 4500 for 56K, 3500 for 33K and 3000 for 28K. Default is 25000 (way too high) * disable tcp nagle (on HARC) This improves UDP performance by removing the tcp nagle (buffering I believe) algorithm * Get customers to disable software compression and modem hardware compression & error correction. * disable flow control (not required as you will probably need to force DTE to 19200 for this to work effectively) * Set the MTU to 576 and the RWIN to 536 and a window size of 4 (for 28K) or 6-8 for 56K. * Set the TTL to 64 or 128. To further decrease client processing delay, users should use 3dfx cards. goto http://www.ve3d.net/3fingers for more info on tweaking these devices. Encourage users to use V.34 instead of V.90/x2 in MP gaming scenario's, because in most cases, it does not provide any throughput benefits (and when disabling error correction/compression, you're more susseptable to errors). This has been standard testing policy with Wireplay in Oz, and on approx. 50 simultaneous connections to the HARC we see ping delays in Quake of about 90-110ms (depending on client PC's hardware and quality of the line/exchange). Unfortunately, WP Australia do not have a high enough customer-base to test performance any higher. They are using DSP/ARC's. Most of the above is common knowledge and standard practise for any multiplayer scenario... Regards, Jason Kelton NC - Australia. Please respond to usr-tc@lists.xmission.com cc: (Jason Kelton/AU/3Com) Note: Some recipients have been dropped due to syntax errors. Please refer to the "$AdditionalHeaders" item for the complete headers. Brian K McIntire wrote: > The latest is: > The HiPer ARC has no known or I should say no disclosed issues relating to > Quake. The NetServer does. Unfortunately, based on my own testing, so does > the HiPer DSP's. The HiPer DSP's are being fine tuned to handle quake > better. The problem is not hardware related. > Interim fix: > Use quads with the HiPer ARC. It works great. The only problem we have had with HyperDSP/HyperARC and quake is thatstac compression causes very bad lag. Once this was disabled on the HyperARC the users were very happy. <snip> -- 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.

Subject: (usr-tc) E1 getting wierd timeouts when rotary group dialed.
From: Brett Murphy <sysadmin@alphalink.com.au>
Date: 1998-10-30 10:53:10

Hi All, We have an occasional problem where all ports are close to full, I notice the top LED or so of the HyperDSP's utilisation "bar" on the panel are blinking off and on alot more than usual. Upon inspection, it appears that only 27 or so of the 30 channels on each DSP card are in use, and when the rotary group number is dialed, rather than getting an immediate busy signal, we get a pause of 20 seconds or so and THEN a busy signal. The only solution is to power off the chassis. Has anyone seen anything similar 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.

Subject: (usr-tc) TotalControl Manager can't change anything on Quadmodems
From: Ralph Helfenberger <rhelfenberger@comlight.ch>
Date: 1998-10-30 12:38:34

Hi folks Has anybody encountered following problem: When I try to change the settings on a QuadModem only the "AddedCost feautures" show up. I don't see any configurable parameters like "line interface settings"... I know there is such an issue with HiPer Arc when the management card doesn't has 16MB memory. But this is a plain old chassis. - TCM 5.5.1 - QuadModems with 5.9.9 - EdgeServer Pro Thanks. Ralph

Subject: RE: (usr-tc) TotalControl Manager can't change anything on Quadmo
From: Phil Le Clercq <phil.le.clercq@cinergy.net>
Date: 1998-10-30 13:21:48

Ralph, this is happening because you are selecting the whole Quad modem card in TCM. You need to select the "modem led" on the card in TCM to get the other options, then go to configuration. Phil -----Original Message----- From: Ralph Helfenberger [mailto:rhelfenberger@comlight.ch] Sent: Friday, October 30, 1998 11:39 AM To: usr-tc@lists.xmission.com Subject: (usr-tc) TotalControl Manager can't change anything on Quadmodems Hi folks Has anybody encountered following problem: When I try to change the settings on a QuadModem only the "AddedCost feautures" show up. I don't see any configurable parameters like "line interface settings"... I know there is such an issue with HiPer Arc when the management card doesn't has 16MB memory. But this is a plain old chassis. - TCM 5.5.1 - QuadModems with 5.9.9 - EdgeServer Pro Thanks. Ralph - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (usr-tc) New Trade-in
From: Jeff Lynch <jeff@mercury.jorsm.com>
Date: 1998-10-30 14:43:01

There's a new Netserver PRI trade-up: 003465-0 (1) HiperARC $6525 (1) HiperDSP (1) 16MB upgrade for NMC (-1) Netserver PRI -$3200 TOTAL $3325 After you get the HARC installed and working, send back your Netserver card and they send you $3200. Seems like a realistic deal. HARC and DSP for $3325 ($139/port and Netserver gone). Not a perfect solution but it bridges the gap between the old Netserver "bend-over" trade-in and the HiPer bundle. Has anybody else heard rumors of a trade-in for the Quads? ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com

Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600
From: Robert von Bismarck <rvb@petrel.ch>
Date: 1998-10-30 15:32:49

Defaults out of the ARC auto-configuration script, just removed the CCP from everything.... Robert > -----Original Message----- > From: Brian K McIntire [SMTP:bmcintire@commnet.com] > Sent: Friday, October 30, 1998 3:40 PM > To: usr-tc@lists.xmission.com > Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600 > > Is your configuration default or have you done something special? > > > > > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Robert von > Bismarck > Sent: Friday, October 30, 1998 3:25 AM > To: 'usr-tc@lists.xmission.com' > Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600 > > > What's that about HiPerDSP not handling quake well ?? > > I have a DSP/HARC-only environment and quake2 is lovely (quake pings > at > about 50-60 with ISDN and 80-100 with analog). > > I'm running 4.0.29 on the HARC's and 1.2.5 on the DSP's with E1/PRI's > off a Siemens EWSD switch.... > > Users are happy like never before (we average 30 users on quake every > second evening...) > > Robert > > > > -----Original Message----- > > From: Brian K McIntire [SMTP:bmcintire@commnet.com] > > Sent: Thursday, October 29, 1998 8:20 PM > > To: usr-tc@lists.xmission.com > > Subject: RE: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600 > > > > The latest is: > > The HiPer ARC has no known or I should say no disclosed issues > > relating to > > Quake. The NetServer does. Unfortunately, based on my own testing, > > so does > > the HiPer DSP's. The HiPer DSP's are being fine tuned to handle > quake > > better. The problem is not hardware related. > > Interim fix: > > Use quads with the HiPer ARC. It works great. > > > ====================================================================== > > = > > = Brian K. McIntire bmcintire@commnet.com > > = > > = Systems Engineer III 317-558-5050 x113 > > = > > = CommNetPlus, Indianapolis, IN http://www.commnet.com > > = > > = Experts in Remote Access; NetWork Design; Security; > Implementation > > = > > = Serving North America and parts of Canada. Reselling to the > world. > > = > > > ====================================================================== > > = > > > > > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Blake Fithen > > Sent: Thursday, October 29, 1998 10:50 AM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) Date: Thu, 29 Oct 1998 11:00:25 -0600 > > > > > > Hello. Does any one know what the latest information is on the > > Quake lag issues with HiperARC and Netserver. Interproc seems > > unreachable right now and I forgot the address for the archives > > for this list - usr-tc.datasys.net? > > > > thanks for you time. > > > > blake > > > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages > send > > "help" to the same address. Do not use quotes in your message. > > > > > > - > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > > with "unsubscribe usr-tc" in the body of the message. > > For information on digests or retrieving files and old messages > send > > "help" to the same address. Do not use quotes in your message. > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: Re: (usr-tc) v.90 connect problems
From: Richard Lorbieski <richard@mail.alpha1.net>
Date: 1998-10-30 15:34:59

Another solution: add commas ,,, or ,,,, at the end of the phone number. That eliminates most of the "modem is not answering" problems and "...not connecting". K Mitchell wrote: > > Since upgrading my DSP's to 1.2.5 I've been having a number of customers > with problems connecting, from plain no-connects to x2 or x2/v90 modems > connecting at a slower rate than before. Otherwise on my HiPer; > ARC 4.0.30 > NMC 5.5.5 > > Some of the no-connects were LT Winmodems and the -v90=0 string helped, the > others I'm waiting to hear back on modem type. > Does DSP 1.2.6x or ARC 4.1.x seem to be helping these problems for anybody > else that's been experiencing them? > > 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.

Subject: (usr-tc) v.90 connect problems
From: K Mitchell <mitch@keyconn.net>
Date: 1998-10-30 15:40:08

Since upgrading my DSP's to 1.2.5 I've been having a number of customers with problems connecting, from plain no-connects to x2 or x2/v90 modems connecting at a slower rate than before. Otherwise on my HiPer; ARC 4.0.30 NMC 5.5.5 Some of the no-connects were LT Winmodems and the -v90=0 string helped, the others I'm waiting to hear back on modem type. Does DSP 1.2.6x or ARC 4.1.x seem to be helping these problems for anybody else that's been experiencing them? Kirk Kirk Mitchell-General Manager sysadmin@keyconn.net Keystone Connect http://www.keyconn.net Altoona, PA 814-941-5000 We Unlock the World

Subject: Re: (usr-tc) New Trade-in
From: Kurtiss Johnson <kurtiss_johnson@mw.3com.com>
Date: 1998-10-30 15:52:16

Jeff, That rumor is not true. We currently do not have a plan for a trade-in program for Quads. And I'm glad to hear the feedback on the new HiPer ARC trade-in package. Kurtiss Johnson Product Manager 3Com - Carrier Business Unit Jeff Lynch <jeff@mercury.jorsm.com> on 10/30/98 02:43:01 PM Please respond to usr-tc@lists.xmission.com cc: (Kurtiss Johnson/MW/US/3Com) Note: Some recipients have been dropped due to syntax errors. Please refer to the "$AdditionalHeaders" item for the complete headers. There's a new Netserver PRI trade-up: 003465-0 (1) HiperARC $6525 (1) HiperDSP (1) 16MB upgrade for NMC (-1) Netserver PRI -$3200 TOTAL $3325 After you get the HARC installed and working, send back your Netserver card and they send you $3200. Seems like a realistic deal. HARC and DSP for $3325 ($139/port and Netserver gone). Not a perfect solution but it bridges the gap between the old Netserver "bend-over" trade-in and the HiPer bundle. Has anybody else heard rumors of a trade-in for the Quads? ========================================================================= Jeffrey A. Lynch JORSM Internet email: jeff@jorsm.com Northwest Indiana's Full-Service Provider Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 Autoresponse: info@jorsm.com http://www.jorsm.com - To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of the message. For information on digests or retrieving files and old messages send "help" to the same address. Do not use quotes in your message.

Subject: (no subject)
From: Brian K McIntire <bmcintire@commnet.com>
Date: 1998-10-30 16:59:06

I had a problem with the LT1 win modem last week. Someone from this list gave me a link to a site that had 5.23. I attempted to download it but kept getting a bad CRC when it was time to unzip. Does anyone have a clean copy of this? ======================================================================= = Brian K. McIntire bmcintire@commnet.com = = Systems Engineer III 317-558-5050 x113 = = CommNetPlus, Indianapolis, IN http://www.commnet.com = = = = Experts in Remote Access and all areas of NetWork Design, Security,= = and Implementation. Offering remote management and monitoring = = packages for dedicated clients (specializing in ISP's). = = Firm partnerships established with all the key players. = = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = = = = Serving North America and parts of Canada. Reselling to the world. = =======================================================================

Subject: Re: (usr-tc) Re: your mail
From: Brian Elfert <brian@citilink.com>
Date: 1998-10-30 17:00:30

On Fri, 30 Oct 1998, Ricky Beam wrote: > Brian K McIntire was heard to say: > >I had a problem with the LT1 win modem last week. Someone from this list > >gave me a link to a site that had 5.23. I attempted to download it but kept > >getting a bad CRC when it was time to unzip. Does anyone have a clean copy > >of this? > > I downloaded that file from Lucent over 700 times. Only FIVE of the copies > came across correctly. Lucent is aware of some sort of corruption problem when downloading that file from their web site. A week or so ago, they were talking about removing the file until the problem could be fixed. Brian

Subject: (usr-tc) RE:
From: Brown Mikel-AMB003 <amb003@namerica.mot.com>
Date: 1998-10-30 17:06:13

Check that your hardware flow control is on, this may correct your CRC errors. > -----Original Message----- > From: Brian K McIntire [SMTP:bmcintire@commnet.com] > Sent: Friday, October 30, 1998 4:59 PM > To: usr tc > Subject: > > I had a problem with the LT1 win modem last week. Someone from this list > gave me a link to a site that had 5.23. I attempted to download it but > kept > getting a bad CRC when it was time to unzip. Does anyone have a clean > copy > of this? > > ======================================================================= > = Brian K. McIntire bmcintire@commnet.com = > = Systems Engineer III 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = > = = > = Experts in Remote Access and all areas of NetWork Design, Security,= > = and Implementation. Offering remote management and monitoring = > = packages for dedicated clients (specializing in ISP's). = > = Firm partnerships established with all the key players. = > = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = > = = > = Serving North America and parts of Canada. Reselling to 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.

Subject: (usr-tc) Re: your mail
From: Ricky Beam <jfbeam@interpath.net>
Date: 1998-10-30 17:22:19

Brian K McIntire was heard to say: >I had a problem with the LT1 win modem last week. Someone from this list >gave me a link to a site that had 5.23. I attempted to download it but kept >getting a bad CRC when it was time to unzip. Does anyone have a clean copy >of this? I downloaded that file from Lucent over 700 times. Only FIVE of the copies came across correctly. http://enterprise.interpath.net/~jfbeam/modem523.exe ftp://ftp.interpath.net/misc/LT-Winmodem/modem523.exe (both copies have been verified) 14fe0c36a49169a2fe74aef719d0569b modem523.exe (md5sum) --Ricky

Subject: Re: (usr-tc) as5100 - am i crazy?
From: Bob Purdon <bobp@southcom.com.au>
Date: 1998-10-31 11:33:56

> * its a serious bitch to setup (Im no idiot, and it took me 2 weeks) Hmmm, we had one a while back and it took me around 30 minutes to get all 3 AS51 cards humming. Then again, we already used 2511's for dialup access at that time, so we had the basic configuration. > * requires 4 10BaseT for each frame Yeah, that's a bitch. It's also a shame they don't make the AS51 cards any longer - I can see them being really useful as POP routers, as well as providing remote console access - something we do now with normal Cisco 2511's. To ahve the same router on a card, with dual power and basic managability would be even better. Regards, Bob Purdon, Technical Manager, Southern Internet Services.

Subject: (usr-tc) Re:
From: Kingsley S. Grant <ksg@recorder.ca>
Date: 1998-10-31 13:21:48

Brian, Try http://www.56k.com they have a list of alternate links that may have the latest update. King. Brian K McIntire wrote: > I had a problem with the LT1 win modem last week. Someone from this list > gave me a link to a site that had 5.23. I attempted to download it but kept > getting a bad CRC when it was time to unzip. Does anyone have a clean copy > of this? > > ======================================================================= > = Brian K. McIntire bmcintire@commnet.com = > = Systems Engineer III 317-558-5050 x113 = > = CommNetPlus, Indianapolis, IN http://www.commnet.com = > = = > = Experts in Remote Access and all areas of NetWork Design, Security,= > = and Implementation. Offering remote management and monitoring = > = packages for dedicated clients (specializing in ISP's). = > = Firm partnerships established with all the key players. = > = Sales 800-845-2981 x117 (Aggressive Pricing strategies) = > = = > = Serving North America and parts of Canada. Reselling to 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.

Subject: RE: (usr-tc) v.90 connect problems
From: Mario M. Bustamante <mario@accesspro.net>
Date: 1998-10-31 15:21:29

We are having the same problems and we are finding a number of complaints coming from customers with USR Sportsters. We have 4 Total Control boxes (3 with net servers and 1 Hiper ARC) and we have postponed our plans for buying another Hiper ARC because of these problems. The Quad modems with Net Servers are less problematic than the Hiper DSP's with Hiper ARC. Some customers get very slow connections or connect fast but can't surf. Many claim they have to dial in many times before they get a good connection, but eventually they do. We are running 4.1.11 and 1.2.5, basically TCS 3.3 for all components. Are some older versions better? Is there some Beta code we should be trying? The problem is so bad we are considering going back to just X2. We are also looking into other equipment, which would kill us since we had become so comfortable with Total Control... ______________________________________________ Mario M. Bustamante, President AccessPro Communications Inc. Miami, Florida > -----Original Message----- > From: owner-usr-tc@lists.xmission.com > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > Sent: Friday, October 30, 1998 3:40 PM > To: usr-tc@lists.xmission.com > Subject: (usr-tc) v.90 connect problems > > > Since upgrading my DSP's to 1.2.5 I've been having a > number of customers > with problems connecting, from plain no-connects to x2 > or x2/v90 modems > connecting at a slower rate than before. Otherwise on my HiPer; > ARC 4.0.30 > NMC 5.5.5 > > Some of the no-connects were LT Winmodems and the > -v90=0 string helped, the > others I'm waiting to hear back on modem type. > Does DSP 1.2.6x or ARC 4.1.x seem to be helping these > problems for anybody > else that's been experiencing them? > > > 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. >

Subject: Re: (usr-tc) New Trade-in
From: Dave Winston <mhamrich@drfast.net>
Date: 1998-10-31 15:59:23

Can you still use the old quads and dual T1/PRI with the HyperArc and add 24 additional ports and 1 T1/PRI form the Hyper DSP? In other words do you get 69 (or 71 with NFAS) active ports in one chassis? If so that is an excellent trade in program! Dave Winston "New" Technical Director DrFast.Net, Inc. -----Original Message----- >Jeff, > >That rumor is not true. We currently do not have a plan for a trade-in >program for Quads. >And I'm glad to hear the feedback on the new HiPer ARC trade-in package. > >Kurtiss Johnson >Product Manager >3Com - Carrier Business Unit > > > > > >Jeff Lynch <jeff@mercury.jorsm.com> on 10/30/98 02:43:01 PM > >Please respond to usr-tc@lists.xmission.com > >To: usr-tc@lists.xmission.com >cc: (Kurtiss Johnson/MW/US/3Com) >Subject: (usr-tc) New Trade-in > > > > >Note: Some recipients have been dropped due to syntax errors. >Please refer to the "$AdditionalHeaders" item for the complete headers. > > > >There's a new Netserver PRI trade-up: > >003465-0 (1) HiperARC $6525 > (1) HiperDSP > (1) 16MB upgrade for NMC > (-1) Netserver PRI -$3200 > > TOTAL $3325 > >After you get the HARC installed and working, send back your >Netserver card and they send you $3200. Seems like a realistic >deal. HARC and DSP for $3325 ($139/port and Netserver gone). Not >a perfect solution but it bridges the gap between the old Netserver >"bend-over" trade-in and the HiPer bundle. > >Has anybody else heard rumors of a trade-in for the Quads? > >========================================================================= >Jeffrey A. Lynch JORSM Internet >email: jeff@jorsm.com Northwest Indiana's Full-Service Provider >Voice: (219)322-2180 927 Sheffield Avenue, Dyer, IN 46311 >Autoresponse: info@jorsm.com http://www.jorsm.com > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. > > > > > > > > >- > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message.

Subject: RE: (usr-tc) v.90 connect problems
From: Mike Andrews <mandrews@termfrost.org>
Date: 1998-10-31 18:41:49

Oh good, it's not just me. :) This has been driving me absolutely crazy for weeks now! We're running ARC 4.1.78 and DSP 1.2.68. As far as I can tell: * It only affects v.90 calls -- x2 and v.34 work fine. * It only affects our DSP/ARC rack, not our Quad/NETserver racks. * It's not specific to LT Winmodems, as I first thought. We have several Sportster owners complaining. I haven't yet tried it with a Courier -- that's next week's project. :) Anyone have ANY hints here? We've lost a customer or two over this now. Mike Andrews (MA12) icq 6602506 -------------- mandrews@termfrost.org VP 'n' Systems/Network Administrator --------------- mandrews@dcr.net Digital Crescent, Frankfort, KY ----------- http://www.termfrost.org/ # view;touch;unzip;finger;mount;mv;mv;mv;yes;mv;yes;mv;yes;umount;sleep On Sat, 31 Oct 1998, Mario M. Bustamante wrote: > We are having the same problems and we are finding a number of > complaints coming from customers with USR Sportsters. > > We have 4 Total Control boxes (3 with net servers and 1 Hiper > ARC) and we have postponed our plans for buying another Hiper ARC > because of these problems. The Quad modems with Net Servers are > less problematic than the Hiper DSP's with Hiper ARC. > > Some customers get very slow connections or connect fast but > can't surf. Many claim they have to dial in many times before > they get a good connection, but eventually they do. > > We are running 4.1.11 and 1.2.5, basically TCS 3.3 for all > components. Are some older versions better? Is there some Beta > code we should be trying? > > The problem is so bad we are considering going back to just X2. > We are also looking into other equipment, which would kill us > since we had become so comfortable with Total Control... > > ______________________________________________ > > Mario M. Bustamante, President > AccessPro Communications Inc. > Miami, Florida > > > > -----Original Message----- > > From: owner-usr-tc@lists.xmission.com > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of K Mitchell > > Sent: Friday, October 30, 1998 3:40 PM > > To: usr-tc@lists.xmission.com > > Subject: (usr-tc) v.90 connect problems > > > > > > Since upgrading my DSP's to 1.2.5 I've been having a > > number of customers > > with problems connecting, from plain no-connects to x2 > > or x2/v90 modems > > connecting at a slower rate than before. Otherwise on my HiPer; > > ARC 4.0.30 > > NMC 5.5.5 > > > > Some of the no-connects were LT Winmodems and the > > -v90=0 string helped, the > > others I'm waiting to hear back on modem type. > > Does DSP 1.2.6x or ARC 4.1.x seem to be helping these > > problems for anybody > > else that's been experiencing them? > > > > > > 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. > > > > > - > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com" > with "unsubscribe usr-tc" in the body of the message. > For information on digests or retrieving files and old messages send > "help" to the same address. Do not use quotes in your message. >

Messages