home *** CD-ROM | disk | FTP | other *** search
/ ftp.xmission.com / 2014.06.ftp.xmission.com.tar / ftp.xmission.com / pub / lists / usr-tc / archive / usr-tc.199903 < prev    next >
Internet Message Format  |  1999-03-31  |  1MB
  1. From: Bob Purdon <bobp@southcom.com.au>
  2. Subject: Re: (usr-tc) 3Com Problems. (And how to survive)
  3. Date: 01 Mar 1999 18:11:18 +1100 (EST)
  4.  
  5.  
  6. > Correct... the AS51 card is a 2511 on a card.
  7.  
  8. We looked at using them at remote POP's - we already use conventional
  9. Cisco 2511's there.  The asyncs for remtoe console access, and the sync
  10. for frame-relay.
  11.  
  12. In the TCH, of course you get remote bootability (without a remote power
  13. switching thingy), dual power, and smaller footprint :-)
  14.  
  15. > Which brings to mind an interesting use for a TCH... 16 2511's in a rack :-)
  16. > (Or course, you could do the same thing with the Edge server cards...)
  17.  
  18. Think of all the ether connections :-(  Still, 16 2511's in 5U plus a 1U
  19. switch or hub, is still fairly dense...
  20.  
  21. > Hmm, 8 Edge Pro's (running linux or freebsd) in one 5U rack...
  22.  
  23. Been there too...  When I priced the Edgeserver (not the Pro), they quoted
  24. me around $20k for the base model.  No way!
  25.  
  26. Regards,
  27.  
  28. Bob Purdon,
  29. Technical Manager,
  30. Southern Internet Services.
  31.  
  32.  
  33. -
  34.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35.  with "unsubscribe usr-tc" in the body of the message.
  36.  For information on digests or retrieving files and old messages send
  37.  "help" to the same address.  Do not use quotes in your message.
  38.  
  39.  
  40. -------------------------------------------------------------------------------
  41.  
  42. From: Ricky Beam <jfbeam@enterprise.interpath.net>
  43. Subject: Re: (usr-tc) 3Com Problems. (And how to survive)
  44. Date: 01 Mar 1999 03:04:30 -0500 (EST)
  45.  
  46. Bob Purdon was heard to say:
  47. >> Hmm, 8 Edge Pro's (running linux or freebsd) in one 5U rack...
  48. >
  49. >Been there too...  When I priced the Edgeserver (not the Pro), they quoted
  50. >me around $20k for the base model.  No way!
  51.  
  52. So, I didn't say it was cheap... just dense.  We just need to find out who's
  53. selling the cards to 3Com :-)  (Or have them built yourself -- the midplane
  54. connector is documented in the ARC docs.)
  55.  
  56. --Ricky
  57.  
  58.  
  59. -
  60.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  61.  with "unsubscribe usr-tc" in the body of the message.
  62.  For information on digests or retrieving files and old messages send
  63.  "help" to the same address.  Do not use quotes in your message.
  64.  
  65.  
  66. -------------------------------------------------------------------------------
  67.  
  68. From: Ricky Beam <jfbeam@enterprise.interpath.net>
  69. Subject: Re: (usr-tc) 3Com Problems.
  70. Date: 01 Mar 1999 03:07:57 -0500 (EST)
  71.  
  72. Allen Marsalis was heard to say:
  73. >>I'm gonna start pushing them for VoIP on the ARC next. :-)
  74. >
  75. >that would be cool..  we have had dozens of PPC's clocking wasted cycles
  76. >for a year now..  perhaps 3COM could get with distributed.net and crack
  77. >RSA keys in the mean time....  :)
  78.  
  79. Heh, funny that you should mention that I'm one of the "coders" for d.net.
  80.  
  81. Of course, you will notice alot of those clocks being used by OSPF... it's
  82. taking about 4% of the CPU here, but that's alpha code that has a few
  83. problems 3Com is clearing up.
  84.  
  85. --Ricky
  86.  
  87.  
  88. -
  89.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  90.  with "unsubscribe usr-tc" in the body of the message.
  91.  For information on digests or retrieving files and old messages send
  92.  "help" to the same address.  Do not use quotes in your message.
  93.  
  94.  
  95. -------------------------------------------------------------------------------
  96.  
  97. From: Bob Purdon <bobp@southcom.com.au>
  98. Subject: Re: (usr-tc) 3Com Problems. (And how to survive)
  99. Date: 01 Mar 1999 19:16:25 +1100 (EST)
  100.  
  101.  
  102. > >me around $20k for the base model.  No way!
  103. > 
  104. > So, I didn't say it was cheap... just dense.
  105.  
  106. Over here, density isn't everything :-)
  107.  
  108. I could build a full size functionally equivalent PC for $3-$4k, and use
  109. the other $16-$17k to pay extra rent, power, etc.
  110.  
  111. It's a neat solution (the Edgeserver), but I can't justify it :-)
  112.  
  113. Regards,
  114.  
  115. Bob Purdon,
  116. Technical Manager,
  117. Southern Internet Services.
  118.  
  119.  
  120. -
  121.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  122.  with "unsubscribe usr-tc" in the body of the message.
  123.  For information on digests or retrieving files and old messages send
  124.  "help" to the same address.  Do not use quotes in your message.
  125.  
  126.  
  127. -------------------------------------------------------------------------------
  128.  
  129. From: MegaZone <megazone@megazone.org>
  130. Subject: Re: (usr-tc) 3Com Problems.
  131. Date: 01 Mar 1999 02:25:54 -0800 (PST)
  132.  
  133. Once upon a time Ricky Beam shaped the electrons to say...
  134. >That magic DSP hardware is Telebit MicaModem hardware.  Telebit still sells
  135. >the "micablazer" line of products that use the same DSP technology.  Pick up
  136.  
  137. Telebit is dead.  ITK absorbed them and the old products were on the way
  138. out, not Digi bought up ITK and there is basically nothing left.  The
  139. NetBlazer name is being used for NT based software and hardware solutions.
  140. The MICABlazer appears to be dead.
  141.  
  142. -MZ
  143. -- 
  144. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  145. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  146. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  147. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  148. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  149.  
  150. -
  151.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  152.  with "unsubscribe usr-tc" in the body of the message.
  153.  For information on digests or retrieving files and old messages send
  154.  "help" to the same address.  Do not use quotes in your message.
  155.  
  156.  
  157. -------------------------------------------------------------------------------
  158.  
  159. From: Ricky Beam <jfbeam@enterprise.interpath.net>
  160. Subject: Re: (usr-tc) 3Com Problems.
  161. Date: 01 Mar 1999 05:59:22 -0500 (EST)
  162.  
  163. MegaZone was heard to say:
  164. >Once upon a time Ricky Beam shaped the electrons to say...
  165. >>That magic DSP hardware is Telebit MicaModem hardware.  Telebit still sells
  166. >>the "micablazer" line of products that use the same DSP technology.  Pick up
  167. >
  168. >Telebit is dead.  ITK absorbed them and the old products were on the way
  169. >out, not Digi bought up ITK and there is basically nothing left.  The
  170. >NetBlazer name is being used for NT based software and hardware solutions.
  171. >The MICABlazer appears to be dead.
  172.  
  173. Telebit/ITK, whatever :-)  I just noticed the Digi thing.  I guess the
  174. netblazer fire has gone out of the universe.  And the netblazer was a
  175. _damn_ good NAS -- who else has ever been able to get a 386dx40 to run
  176. 48 115.2k serial ports without a problem?
  177.  
  178. --Ricky
  179.  
  180.  
  181. -
  182.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  183.  with "unsubscribe usr-tc" in the body of the message.
  184.  For information on digests or retrieving files and old messages send
  185.  "help" to the same address.  Do not use quotes in your message.
  186.  
  187.  
  188. -------------------------------------------------------------------------------
  189.  
  190. From: MegaZone <megazone@megazone.org>
  191. Subject: Re: (usr-tc) 3Com Problems.
  192. Date: 01 Mar 1999 03:05:25 -0800 (PST)
  193.  
  194. Once upon a time Ricky Beam shaped the electrons to say...
  195. >_damn_ good NAS -- who else has ever been able to get a 386dx40 to run
  196. >48 115.2k serial ports without a problem?
  197.  
  198. Well, the PM-2eR-30 only has a 386-33, early revs were 386-25. :-)  That's
  199. the most ports on an async PM.  The PM-3 is a 486-66.
  200.  
  201. -MZ
  202. -- 
  203. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  204. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  205. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  206. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  207. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  208.  
  209.  
  210. -
  211.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  212.  with "unsubscribe usr-tc" in the body of the message.
  213.  For information on digests or retrieving files and old messages send
  214.  "help" to the same address.  Do not use quotes in your message.
  215.  
  216.  
  217. -------------------------------------------------------------------------------
  218.  
  219. From: Luke Gain <luke@erinet.com>
  220. Subject: Re: (usr-tc) 3Com Problems. (And how to survive)
  221. Date: 01 Mar 1999 07:39:58 -0500 (EST)
  222.  
  223. > 
  224. > Correct... the AS51 card is a 2511 on a card.
  225. > 
  226. > Which brings to mind an interesting use for a TCH... 16 2511's in a rack :-)
  227. > (Or course, you could do the same thing with the Edge server cards...)
  228. > 
  229. > Hmm, 8 Edge Pro's (running linux or freebsd) in one 5U rack...
  230. > 
  231. > --Ricky
  232. Or....
  233.  
  234. One could be really ambitious and port Linux to  the HiperArc. Then you
  235. could have 16 603e in 5U of space. (IMO, HiperARC should make a decent
  236. server: 200mhz 603e, 8mb of flash (local disk) 128MB ram, Dual Fast-Ethernet
  237. Serial Console)  What more do you really need?
  238.  
  239.  
  240. -Luke
  241.  
  242. -
  243.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  244.  with "unsubscribe usr-tc" in the body of the message.
  245.  For information on digests or retrieving files and old messages send
  246.  "help" to the same address.  Do not use quotes in your message.
  247.  
  248.  
  249. -------------------------------------------------------------------------------
  250.  
  251. From: Jim Johnson <jim@perigee.net>
  252. Subject: (usr-tc) Quad connects at 2400 BPS
  253. Date: 01 Mar 1999 09:35:50 -0500
  254.  
  255.  
  256.  
  257. We have a quad modem (fw ver 5.10) that will only connect at 2400 BPS. 
  258. Whenever I check the Default DTE data rate setting in TCM, it is set to
  259. 2400 BPS.  I can reset it to something else (e.g., 38 KBPS), but after
  260. any modem connects to it, it is set back to 2400.  I tried savign config
  261. to NVRAM and restoring, restoring from Defaults, but no matter what I do
  262. the first modem that hits it connects at 2400 BPS and the Default DTE
  263. date rate is reset back to 2400 BPS.
  264.  
  265. Does anyone have any suggections, or is this a bad port on the quad?
  266.  
  267. Thanks,
  268.  
  269. Jim
  270.  
  271. -
  272.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  273.  with "unsubscribe usr-tc" in the body of the message.
  274.  For information on digests or retrieving files and old messages send
  275.  "help" to the same address.  Do not use quotes in your message.
  276.  
  277.  
  278. -------------------------------------------------------------------------------
  279.  
  280. From: "bryan s. blank" <bryan@supernet.net>
  281. Subject: Re: (usr-tc) 3Com Problems. (And how to survive)
  282. Date: 01 Mar 1999 10:14:37 -0500 (EST)
  283.  
  284. % The AS5100 card is a 2511 on a card, right?  I've been toying around with
  285. % the idea of finding a used one just to use in place of a 2511 for a remote
  286. % pop (not actually run modems off it, but hook the async ports to the NMC,
  287. % DSP, and Dual PRI serial ports...)  How much flash/dram do they have?  If
  288. % it's got enough flash and it's really 2500 based, you could still get IOS
  289. % 11.3 or 12.0 on it...
  290.     
  291.     yeah, 16mb ram, 16mb flash.  you can run 12.0 on it.  great
  292.     stuff, 1 sync serial, console, aux, and ethernet per card.
  293.     works better than anything i've found.  give 'em a shot, once
  294.     you have a good configuration it's wonderful.
  295.  
  296. |o|----------------------------------------------------------------------|o|
  297. |o| bryan s. blank                                  (203)-351-1178 voice |o|
  298. |o| senior systems analyst                          (203)-351-1186 fax   |o|
  299. |o| discovernet, incorporated                       (800)-209-0223 emerg |o|
  300.  
  301.  
  302.  
  303. -
  304.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  305.  with "unsubscribe usr-tc" in the body of the message.
  306.  For information on digests or retrieving files and old messages send
  307.  "help" to the same address.  Do not use quotes in your message.
  308.  
  309.  
  310. -------------------------------------------------------------------------------
  311.  
  312. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  313. Subject: Re: (usr-tc) connecting to hdm console or quad/dsp for outbound
  314. Date: 01 Mar 1999 09:29:50 -0600 (CST)
  315.  
  316. On Sun, 28 Feb 1999, Mike Andrews wrote:
  317.  
  318. > Great, just what I needed.  Now why would a Quad modem get a DSP Interrupt
  319. > Timeout when trying to answer a call...
  320.  
  321. Where are you see thins?  Is this on a ati6 screen on the modem? or 
  322. something in the syslog?
  323.  
  324. krish
  325.  
  326. > 
  327. > 
  328. > Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  329. > mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  330. > getting beaten by the police, put down the video camera and come help me!"
  331. > 
  332.  
  333. -
  334.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  335.  with "unsubscribe usr-tc" in the body of the message.
  336.  For information on digests or retrieving files and old messages send
  337.  "help" to the same address.  Do not use quotes in your message.
  338.  
  339.  
  340. -------------------------------------------------------------------------------
  341.  
  342. From: Marcelo Souza <mpsouza@centroin.com.br>
  343. Subject: Re: (usr-tc) Filter docs
  344. Date: 01 Mar 1999 12:46:29 -0300 (EST)
  345.  
  346. On Sun, 28 Feb 1999, Jamie Orzechowski wrote:
  347.  
  348. |Just wondering if anyone can point me to a reference for ARC filters (and
  349. |netserver) ... I just need some syntax to add blocks for some TCP/UDP ports
  350.  
  351.     You have all the information in the Total Control CD PDF files.
  352.  
  353. - Marcelo
  354.  
  355. |---------------------------------------------------
  356. |Have a Great Day!
  357. |
  358. |Jamie Orzechowski
  359. |RipNET System Admin
  360. |
  361. |Tel.: 613-342-3946 ext 293
  362. |Tel.: 800-267-4434 ext 293
  363. |Page.: 613-341-0883
  364. |EMail.: mhz@ripnet.com
  365. |Web.: http://www.ripnet.com
  366. |Personal.: http://www.moonchilli.com
  367. |---------------------------------------------------
  368. |
  369. |
  370. |-
  371. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  372. | with "unsubscribe usr-tc" in the body of the message.
  373. | For information on digests or retrieving files and old messages send
  374. | "help" to the same address.  Do not use quotes in your message.
  375. |
  376.  
  377. - Marcelo
  378.  
  379.  
  380. -
  381.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  382.  with "unsubscribe usr-tc" in the body of the message.
  383.  For information on digests or retrieving files and old messages send
  384.  "help" to the same address.  Do not use quotes in your message.
  385.  
  386.  
  387. -------------------------------------------------------------------------------
  388.  
  389. From: "Jamie Orzechowski" <mhz@ripnet.com>
  390. Subject: Re: (usr-tc) Filter docs
  391. Date: 01 Mar 1999 11:00:12 -0500
  392.  
  393. I never even opened up the cd ... =) ... got any web links?
  394.  
  395. -----Original Message-----
  396.  
  397.  
  398. >On Sun, 28 Feb 1999, Jamie Orzechowski wrote:
  399. >
  400. >|Just wondering if anyone can point me to a reference for ARC filters (and
  401. >|netserver) ... I just need some syntax to add blocks for some TCP/UDP
  402. ports
  403. >
  404. > You have all the information in the Total Control CD PDF files.
  405. >
  406. >- Marcelo
  407. >
  408. >|---------------------------------------------------
  409. >|Have a Great Day!
  410. >|
  411. >|Jamie Orzechowski
  412. >|RipNET System Admin
  413. >|
  414. >|Tel.: 613-342-3946 ext 293
  415. >|Tel.: 800-267-4434 ext 293
  416. >|Page.: 613-341-0883
  417. >|EMail.: mhz@ripnet.com
  418. >|Web.: http://www.ripnet.com
  419. >|Personal.: http://www.moonchilli.com
  420. >|---------------------------------------------------
  421. >|
  422. >|
  423. >|-
  424. >| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  425. >| with "unsubscribe usr-tc" in the body of the message.
  426. >| For information on digests or retrieving files and old messages send
  427. >| "help" to the same address.  Do not use quotes in your message.
  428. >|
  429. >
  430. >- Marcelo
  431. >
  432. >
  433. >-
  434. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  435. > with "unsubscribe usr-tc" in the body of the message.
  436. > For information on digests or retrieving files and old messages send
  437. > "help" to the same address.  Do not use quotes in your message.
  438. >
  439. >
  440.  
  441.  
  442. -
  443.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  444.  with "unsubscribe usr-tc" in the body of the message.
  445.  For information on digests or retrieving files and old messages send
  446.  "help" to the same address.  Do not use quotes in your message.
  447.  
  448.  
  449. -------------------------------------------------------------------------------
  450.  
  451. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  452. Subject: RE: (usr-tc) Preferences in RADIUS servers
  453. Date: 01 Mar 1999 10:33:11 -0600
  454.  
  455.  
  456.  
  457. |-----Original Message-----
  458. |From: owner-usr-tc@lists.xmission.com
  459. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of MegaZone
  460. |Sent: Sunday, February 28, 1999 5:02 AM
  461. |To: usr-tc@lists.xmission.com
  462. |Subject: Re: (usr-tc) Preferences in RADIUS servers
  463. |
  464. |
  465. |Once upon a time Jeff Mcadams shaped the electrons to say...
  466. |>Oh man...I'm not even sure what to say about this...
  467. |>BTW, the spelling is "subtle"
  468. |
  469. |You know their forums are 3Com owners only.  I was rejected. :-)
  470. |
  471. |Maybe I shouldn't have sold that old NetServer I had collecting dust.
  472. |This summer perhaps I'll buy some dead 3Com/USR gear at the MIT flea
  473. |and then insist they let me in as an owner. ;-)
  474. |
  475.  
  476. These forums are open. Maybe you tried to subscribe to an internal forum.
  477.  
  478.  
  479. To Subscribe/Unsubscribe to/from the 3Com Carrier User-Forum - 
  480. http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+forumlink
  481. To access the 3Com Knowledgebase - http://knowledgebase.3com.com
  482. To access 3Com Carrier documentation - 
  483. http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+docs
  484. To view 3Com Carrier Service Offerings - 
  485. http://totalservice.3com.com/cgi-bin/w3com/start?totalservice+service
  486.  
  487. -
  488.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  489.  with "unsubscribe usr-tc" in the body of the message.
  490.  For information on digests or retrieving files and old messages send
  491.  "help" to the same address.  Do not use quotes in your message.
  492.  
  493.  
  494. -------------------------------------------------------------------------------
  495.  
  496. From: Jose Roberto Bulcao <bulcao@rio.com.br>
  497. Subject: Re: (usr-tc) Filter docs
  498. Date: 01 Mar 1999 13:46:31 -0300 (GRNLNDST)
  499.  
  500.  
  501. I think all relavante documentation a freely distributed on
  502. http://totalservice.usr.com. Try to look for HARC User Guide under 
  503. 'Latest Code', find 'harc41user.pdf (~4Mb)' and download it. 
  504.  
  505.  
  506. On Mon, 1 Mar 1999, Jamie Orzechowski wrote:
  507.  
  508. > 
  509. > I never even opened up the cd ... =) ... got any web links?
  510. > 
  511. > -----Original Message-----
  512. > From: Marcelo Souza <mpsouza@centroin.com.br>
  513. > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  514. > Date: Monday, March 01, 1999 10:49 AM
  515. > Subject: Re: (usr-tc) Filter docs
  516. > 
  517. > 
  518. > >On Sun, 28 Feb 1999, Jamie Orzechowski wrote:
  519. > >
  520. > >|Just wondering if anyone can point me to a reference for ARC filters (and
  521. > >|netserver) ... I just need some syntax to add blocks for some TCP/UDP
  522. > ports
  523. > >
  524. > > You have all the information in the Total Control CD PDF files.
  525. > >
  526. > >- Marcelo
  527. > >
  528.  
  529. Jose Roberto Bulcao - RioLink Internet
  530. Tel    : (021) 577-8899
  531. e-mail : bulcao@rio.com.br
  532.  
  533.  
  534. -
  535.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  536.  with "unsubscribe usr-tc" in the body of the message.
  537.  For information on digests or retrieving files and old messages send
  538.  "help" to the same address.  Do not use quotes in your message.
  539.  
  540.  
  541. -------------------------------------------------------------------------------
  542.  
  543. From: Carl Jagerski <carll@forcomm.net>
  544. Subject: (usr-tc) Password encryption ?
  545. Date: 01 Mar 1999 12:25:28 -0500
  546.  
  547. Hi All,
  548.     I am using S&A 6.0.8 with TC HyperDSP.  Every time someone tries
  549. to authenticate, The high bit of every character in the password in the
  550. users table is turned on.  It seems to do it before it authenticates 
  551. because it refuses the connection.  
  552. The setup program says not to use a secret for accounting or it will
  553. encrypt the password.  I made sure that the secret  was deleted 
  554. from both the radius and the TC box.
  555.  
  556.     Can someone shed some light on this problem?
  557.  
  558.  
  559.  
  560. Carl Jagerski
  561. Network Administrator, Forward Communications
  562. carll@forcomm.net
  563. 412-378-4490   Fax: 412-375-0156
  564.  
  565.  
  566. -
  567.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  568.  with "unsubscribe usr-tc" in the body of the message.
  569.  For information on digests or retrieving files and old messages send
  570.  "help" to the same address.  Do not use quotes in your message.
  571.  
  572.  
  573. -------------------------------------------------------------------------------
  574.  
  575. From: beckerr@softrends.com
  576. Subject: (usr-tc) HARC Idle q....
  577. Date: 01 Mar 1999 12:39:12 -0500
  578.  
  579. Hello,
  580.    We are about to upgrade our NETserver to a HiperARC, and I
  581. know that Idle times are not directly available via SNMP anymore
  582. on the HiperARC... my question is this- does the HiperARC actually
  583. take note of the standard RADIUS attribute "Idle-Session-Timeout"?
  584. I know the NETserver doesnt; the only way to get Idles knocked off
  585. on that is to be running the USR RADIUS package + the TC management
  586. on an NT box; and the software polls for idles, and knocks them off,
  587. not the TC box itself.  If the HiperARC doesn't support the RADIUS
  588. Idle attribute, then I assume that the only way to get users out is
  589. to use telnet and check for them? I can't imagine everyone is doing
  590. that....
  591.  
  592.  
  593. --Ross
  594.   beckerr@softrends.com
  595.  
  596. -
  597.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  598.  with "unsubscribe usr-tc" in the body of the message.
  599.  For information on digests or retrieving files and old messages send
  600.  "help" to the same address.  Do not use quotes in your message.
  601.  
  602.  
  603. -------------------------------------------------------------------------------
  604.  
  605. From: Jeff Mcadams <jeffm@iglou.com>
  606. Subject: Re: (usr-tc) HARC Idle q....
  607. Date: 01 Mar 1999 12:45:55 -0500 (EST)
  608.  
  609. Thus spake beckerr@softrends.com
  610. >   We are about to upgrade our NETserver to a HiperARC, and I
  611. >know that Idle times are not directly available via SNMP anymore
  612. >on the HiperARC... my question is this- does the HiperARC actually
  613. >take note of the standard RADIUS attribute "Idle-Session-Timeout"?
  614. >I know the NETserver doesnt; the only way to get Idles knocked off
  615. >on that is to be running the USR RADIUS package + the TC management
  616. >on an NT box; and the software polls for idles, and knocks them off,
  617. >not the TC box itself.  
  618.  
  619. Uhm, that's not correct.  Our NETServer's handle Idle-Timeout (in case
  620. our dictionary files don't match, its attribute 28) with no problems
  621. whatsoever.  I *believe* HiPer Arcs handle this just as easily, just
  622. there is no user-interface way of checking what the current idle-time on
  623. a port is.
  624. -- 
  625. Jeff McAdams                            Email: jeffm@iglou.com
  626. Head Network Administrator              Voice: (502) 966-3848
  627. IgLou Internet Services                        (800) 436-4456
  628.  
  629. -
  630.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  631.  with "unsubscribe usr-tc" in the body of the message.
  632.  For information on digests or retrieving files and old messages send
  633.  "help" to the same address.  Do not use quotes in your message.
  634.  
  635.  
  636. -------------------------------------------------------------------------------
  637.  
  638. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  639. Subject: RE: (usr-tc) HARC Idle q....
  640. Date: 01 Mar 1999 11:47:42 -0600
  641.  
  642.  
  643.  
  644. |-----Original Message-----
  645. |From: owner-usr-tc@lists.xmission.com
  646. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  647. |beckerr@softrends.com
  648. |Sent: Monday, March 01, 1999 11:39 AM
  649. |To: usr-tc@lists.xmission.com
  650. |Subject: (usr-tc) HARC Idle q....
  651. |
  652. |
  653. |Hello,
  654. |   We are about to upgrade our NETserver to a HiperARC, and I
  655. |know that Idle times are not directly available via SNMP anymore
  656. |on the HiperARC... my question is this- does the HiperARC actually
  657. |take note of the standard RADIUS attribute "Idle-Session-Timeout"?
  658. |I know the NETserver doesnt; the only way to get Idles knocked off
  659. |on that is to be running the USR RADIUS package + the TC management
  660. |on an NT box; and the software polls for idles, and knocks them off,
  661. |not the TC box itself.  If the HiperARC doesn't support the RADIUS
  662. |Idle attribute, then I assume that the only way to get users out is
  663. |to use telnet and check for them? I can't imagine everyone is doing
  664. |that....
  665. |
  666. |
  667.  
  668. 1) Idle timeout works on the netserver with the RADIUS Attribute. (assuming your
  669. not running 2 year old code)
  670. 2) So doe the HARC.
  671.  
  672. -M
  673.  
  674.  
  675. -
  676.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  677.  with "unsubscribe usr-tc" in the body of the message.
  678.  For information on digests or retrieving files and old messages send
  679.  "help" to the same address.  Do not use quotes in your message.
  680.  
  681.  
  682. -------------------------------------------------------------------------------
  683.  
  684. From: Richard Stuplich <dick@dwave.net>
  685. Subject: Re: (usr-tc) HARC Idle q....
  686. Date: 01 Mar 1999 12:01:29 -0600
  687.  
  688. How do you set the default IDLE timout on a HiperARC?
  689.  
  690. We have no default user on the HiperARC now.  What, exactly, is the way to
  691. get it to have a default IDLE timeout?
  692.  
  693. At 12:45 PM 3/1/99 -0500, you wrote:
  694. >Thus spake beckerr@softrends.com
  695. >>   We are about to upgrade our NETserver to a HiperARC, and I
  696. >>know that Idle times are not directly available via SNMP anymore
  697. >>on the HiperARC... my question is this- does the HiperARC actually
  698. >>take note of the standard RADIUS attribute "Idle-Session-Timeout"?
  699. >>I know the NETserver doesnt; the only way to get Idles knocked off
  700. >>on that is to be running the USR RADIUS package + the TC management
  701. >>on an NT box; and the software polls for idles, and knocks them off,
  702. >>not the TC box itself.  
  703. >
  704. >Uhm, that's not correct.  Our NETServer's handle Idle-Timeout (in case
  705. >our dictionary files don't match, its attribute 28) with no problems
  706. >whatsoever.  I *believe* HiPer Arcs handle this just as easily, just
  707. >there is no user-interface way of checking what the current idle-time on
  708. >a port is.
  709. >-- 
  710. >Jeff McAdams                            Email: jeffm@iglou.com
  711. >Head Network Administrator              Voice: (502) 966-3848
  712. >IgLou Internet Services                        (800) 436-4456
  713. >
  714. >-
  715. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  716. > with "unsubscribe usr-tc" in the body of the message.
  717. > For information on digests or retrieving files and old messages send
  718. > "help" to the same address.  Do not use quotes in your message.
  719. >
  720. >
  721.  
  722.  Richard B. Stuplich                     DataWave, Not just faster, Better.
  723.  President, DataWave Technologies        17 T1 circuits and growing strong.
  724. DataWave, Wausau's first local ISP to have a direct connection to the
  725. midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90.  The only area ISP to
  726. have redundant T1 NAP connections, All modem compatibility and a staff
  727. dedicated exclusively to providing Internet Service to this area.
  728. This E-Mail Copyright 1999 Richard Stuplich, see http://dw.net/cr/
  729.  
  730. -
  731.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  732.  with "unsubscribe usr-tc" in the body of the message.
  733.  For information on digests or retrieving files and old messages send
  734.  "help" to the same address.  Do not use quotes in your message.
  735.  
  736.  
  737. -------------------------------------------------------------------------------
  738.  
  739. From: Jim Johnson <jim@perigee.net>
  740. Subject: (usr-tc) ALERT - Widespread Problem with Quads...
  741. Date: 01 Mar 1999 12:56:12 -0500
  742.  
  743.  
  744.  
  745. Earlier, I emailed the group about a Quad Modem stuck in 2400 BPS mode. 
  746. This problem was pretty obvious due to the low connect speed. If the
  747. speed had been higher, say 14.4 or 19.2 KBPS, we might not have detected
  748. it.  I emailed this list and disabled the modem.  Since there are always
  749. two extra ports in a 12 quad chassis, I was not overly concerned.
  750.  
  751. BUT WAIT....THERE'S MORE..... 
  752.  
  753. I have spent this morning looking through several of our other chasssis
  754. in different physical locations and it appears that the problem is more
  755. widespread for us than a single port stuck at 2400 BPS.
  756.  
  757. In one chassis, I have three cards, each with one port locked in at an
  758. upper speed of 19,200 BPS.  In another chassis, I have two cards that
  759. each have a port locked to a max speed of 19,200 BPS.  Just as in the
  760. case of the 2400 BPS modem, I cannot find any way to change these
  761. permanently.  The first modem that connects changes the default DTE data
  762. rate back to 19200.  On a side note, can anyone explain to me why the
  763. Default DTE data rate is so important?
  764.  
  765. Anyway here is the real kicker, in yet another chassis, a single quad
  766. card had three ports locked at 19,200 and another at 14,200.  So after
  767. trying everything else, I tried to reflash the card to 5.10/5.9.  Now
  768. the card is DEAD.  Since it is a Digital Quad Modem, there is not a
  769. console port to try and SDL any new code, so I am SOL.  I had to drive
  770. out to the site and replace the card! ARGH.
  771.  
  772. Anyone have any suggestions?  Surely, a problem this widespread through
  773. a small ISP like ours is occuring undetected across hundreds of other
  774. ISPs.
  775.  
  776. I would suggest people with Quad modem cards who are getting complaints
  777. of intermittent, low connect speeds, check their ports for this
  778. problem.  Just 'Select All" ports => Programmed Settings => DTE
  779. Interface Settings and check the Default DTE data rate.  It appears that
  780. the normal default number is 38 kbps.  If you see, 19,200, 14,400 or
  781. 2,400, you might want to check and see how that port is connecting.
  782.  
  783. Regards,
  784.  
  785. Jim Johnson
  786.  
  787. -
  788.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  789.  with "unsubscribe usr-tc" in the body of the message.
  790.  For information on digests or retrieving files and old messages send
  791.  "help" to the same address.  Do not use quotes in your message.
  792.  
  793.  
  794. -------------------------------------------------------------------------------
  795.  
  796. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  797. Subject: RE: (usr-tc) HARC Idle q....
  798. Date: 01 Mar 1999 12:18:01 -0600
  799.  
  800.  
  801.  
  802. |-----Original Message-----
  803. |From: owner-usr-tc@lists.xmission.com
  804. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Richard Stuplich
  805. |Sent: Monday, March 01, 1999 12:01 PM
  806. |To: usr-tc@lists.xmission.com
  807. |Subject: Re: (usr-tc) HARC Idle q....
  808. |
  809. |
  810. |How do you set the default IDLE timout on a HiperARC?
  811. |
  812. |We have no default user on the HiperARC now.  What, exactly, is the way to
  813. |get it to have a default IDLE timeout?
  814.  
  815.  
  816. Since you can't delete the DEFAULT user on the HARC, you have one. This is where
  817. you set the default idle timeout.
  818. The settings made on the default user are applied to all dial-in users if not
  819. otherwise specified by RADIUS. This will also apply to all local users created
  820. after the change of the default user. Its basically a template.
  821.  
  822.  
  823. -M
  824.  
  825.  
  826.  
  827. -
  828.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  829.  with "unsubscribe usr-tc" in the body of the message.
  830.  For information on digests or retrieving files and old messages send
  831.  "help" to the same address.  Do not use quotes in your message.
  832.  
  833.  
  834. -------------------------------------------------------------------------------
  835.  
  836. From: David Bolen <db3l@ans.net>
  837. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  838. Date: 01 Mar 1999 13:25:29 EST
  839.  
  840. Jim Johnson <jim@perigee.net> writes:
  841.  
  842. >                      On a side note, can anyone explain to me why the
  843. > Default DTE data rate is so important?
  844.  
  845. Normally the DTE rate can act as an overall rate limiter to the
  846. connection depending on the type of connection being negotiated.
  847. Normally this only applies to modems with an actual DTE, but I've seen
  848. most releases of the quad code look at this value even when connected
  849. on the packet bus.
  850.  
  851. >                    Since it is a Digital Quad Modem, there is not a
  852. > console port to try and SDL any new code, so I am SOL.  I had to drive
  853. > out to the site and replace the card! ARGH.
  854.  
  855. You don't need a console port for SDL - that's what the NMC is for :-)
  856.  
  857. > Anyone have any suggestions?  Surely, a problem this widespread through
  858. > a small ISP like ours is occuring undetected across hundreds of other
  859. > ISPs.
  860.  
  861. It sounds to me like you may have had some corruption during a code
  862. upgrade.  I suggest the following process during any upgrade:
  863.  
  864.   * Download the new code.
  865.   * Restore all modems to factory defaults (we restore to the hardware
  866.     flow control configuration via the NMC - equivalent to AT&F1)
  867.   * Reprogram any settings you change from the defaults.
  868.   * Save the modem to NVRAM.
  869.  
  870. In this case, I'd suggest doing the restore/program/save cycle on all
  871. of your modems and see if anything changes.
  872.  
  873. While forward upgrades in code are always supposed to maintain
  874. settings, it doesn't always work that way - particularly when new
  875. releases add new settings and/or start using internal locations that
  876. may not have been cleared properly.
  877.  
  878. -- David
  879.  
  880. /-----------------------------------------------------------------------\
  881.  \               David Bolen              \  Internet: db3l@ans.net    /
  882.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  883.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  884. \-----------------------------------------------------------------------/
  885.  
  886. -
  887.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  888.  with "unsubscribe usr-tc" in the body of the message.
  889.  For information on digests or retrieving files and old messages send
  890.  "help" to the same address.  Do not use quotes in your message.
  891.  
  892.  
  893. -------------------------------------------------------------------------------
  894.  
  895. From: "Tony Loosle" <tony@tcsourceone.com>
  896. Subject: (usr-tc) USR Reseller
  897. Date: 01 Mar 1999 11:33:54 -0700
  898.  
  899. Thanks to all who replied and have helped with my usr software problem.
  900.  
  901. Tony
  902.  
  903.  
  904.  
  905.  
  906. -
  907.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  908.  with "unsubscribe usr-tc" in the body of the message.
  909.  For information on digests or retrieving files and old messages send
  910.  "help" to the same address.  Do not use quotes in your message.
  911.  
  912.  
  913. -------------------------------------------------------------------------------
  914.  
  915. From: Ricky Beam <jfbeam@enterprise.interpath.net>
  916. Subject: Re: (usr-tc) Password encryption ?
  917. Date: 01 Mar 1999 14:28:05 -0500 (EST)
  918.  
  919. Carl Jagerski was heard to say:
  920. >Hi All,
  921. >    I am using S&A 6.0.8 with TC HyperDSP.  Every time someone tries
  922. >to authenticate, The high bit of every character in the password in the
  923. >users table is turned on.  It seems to do it before it authenticates 
  924. >because it refuses the connection.  
  925. >The setup program says not to use a secret for accounting or it will
  926. >encrypt the password.  I made sure that the secret  was deleted 
  927. >from both the radius and the TC box.
  928.  
  929. Look through the RADIUS server script (radserv.scp)... there are a few
  930. sections of code in there that "encrypts" secrets and passwords in the
  931. database -- some encryption, eh?
  932.  
  933. I removed the stupid waste of CPU time...  (you do know you can rewrite
  934. that script.)
  935.  
  936. --Ricky
  937.  
  938.  
  939. -
  940.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  941.  with "unsubscribe usr-tc" in the body of the message.
  942.  For information on digests or retrieving files and old messages send
  943.  "help" to the same address.  Do not use quotes in your message.
  944.  
  945.  
  946. -------------------------------------------------------------------------------
  947.  
  948. From: Brian Elfert <brian@citilink.com>
  949. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  950. Date: 01 Mar 1999 13:28:05 -0600 (CST)
  951.  
  952.  
  953.  
  954. On Mon, 1 Mar 1999, Jim Johnson wrote:
  955.  
  956. > I would suggest people with Quad modem cards who are getting complaints
  957. > of intermittent, low connect speeds, check their ports for this
  958. > problem.  Just 'Select All" ports => Programmed Settings => DTE
  959. > Interface Settings and check the Default DTE data rate.  It appears that
  960. > the normal default number is 38 kbps.  If you see, 19,200, 14,400 or
  961. > 2,400, you might want to check and see how that port is connecting.
  962.  
  963. I'm pretty sure that rate is only for use with a serial port.  If you're
  964. using a Netserver or Hiper ARC, that setting is ingnored.
  965.  
  966. Many of my quad modems are set to 19.2 or slower, and they all connect at
  967. high speeds.  A few weeks ago, I wrote up a war dialer script aimed at my
  968. modem pool.  It logged the connect speeds, and every single modem
  969. connected at 49333 over 5 hours or so the dialer ran. 
  970.  
  971. Brian
  972.  
  973.  
  974. -
  975.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  976.  with "unsubscribe usr-tc" in the body of the message.
  977.  For information on digests or retrieving files and old messages send
  978.  "help" to the same address.  Do not use quotes in your message.
  979.  
  980.  
  981. -------------------------------------------------------------------------------
  982.  
  983. From: "Wayne Barber" <barberw@tidewater.net>
  984. Subject: RE: (usr-tc) geo-book connect
  985. Date: 01 Mar 1999 14:54:07 -0500
  986.  
  987. Jeff,
  988.  
  989. Do you have any other advice for connecting GeoBook users? I just changed to
  990. 4.1.59-5 of the HiperARC software, but my one GeoBook owner still cannot
  991. stay connected. She gets connected and my radius software claims she
  992. authenticates successfully, but she then gets dropped right away.  The
  993. latest attempt saw seven successful authentications in a row for the same
  994. call. She still didn't stay connected.
  995.  
  996. I am running a mix of 12 quads (5.9.9) and 1 DSP (1.2.60).
  997.  
  998. Thanks,
  999. Wayne Barber
  1000. Coastal Telco Services
  1001.  
  1002. > -----Original Message-----
  1003. > From: owner-usr-tc@lists.xmission.com
  1004. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
  1005. > Sent: Thursday, February 25, 1999 10:59 PM
  1006. > To: usr-tc@lists.xmission.com
  1007. > Subject: (usr-tc) geo-book connect
  1008. >
  1009. >
  1010. > -> Greetings,
  1011. > ->   I am having trouble connecting a client who is using a
  1012. > Brother Geo-Book.
  1013. > -> I'm using a TC chassis with HiPer ARC and DSP. No trouble with
  1014. > Anyone before
  1015. > -> this. The Brother folks say I need to assign IP and mask and
  1016. > gateway but I
  1017. > -> work with a pool.
  1018. > ->   Anyone have a suggestion?
  1019. >
  1020. > Talk to Krish.  he and I worked on this and you must have 4.1.64
  1021. > of HiPerArc
  1022. > code or higher.
  1023. >
  1024. > Jeff Binkley
  1025. > ASA Network Computing
  1026. >
  1027. > -
  1028. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1029. >  with "unsubscribe usr-tc" in the body of the message.
  1030. >  For information on digests or retrieving files and old messages send
  1031. >  "help" to the same address.  Do not use quotes in your message.
  1032. >
  1033.  
  1034.  
  1035. -
  1036.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1037.  with "unsubscribe usr-tc" in the body of the message.
  1038.  For information on digests or retrieving files and old messages send
  1039.  "help" to the same address.  Do not use quotes in your message.
  1040.  
  1041.  
  1042. -------------------------------------------------------------------------------
  1043.  
  1044. From: Jim Johnson <jim@perigee.net>
  1045. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  1046. Date: 01 Mar 1999 15:19:28 -0500
  1047.  
  1048.  
  1049. David Bolen wrote:
  1050. > 
  1051. > Jim Johnson <jim@perigee.net> writes:
  1052. > 
  1053. > >                      On a side note, can anyone explain to me why the
  1054. > > Default DTE data rate is so important?
  1055. > 
  1056. > Normally the DTE rate can act as an overall rate limiter to the
  1057. > connection depending on the type of connection being negotiated.
  1058. > Normally this only applies to modems with an actual DTE, but I've seen
  1059. > most releases of the quad code look at this value even when connected
  1060. > on the packet bus.
  1061. > 
  1062. > >                    Since it is a Digital Quad Modem, there is not a
  1063. > > console port to try and SDL any new code, so I am SOL.  I had to drive
  1064. > > out to the site and replace the card! ARGH.
  1065. > 
  1066. > You don't need a console port for SDL - that's what the NMC is for :-)
  1067.  
  1068.  
  1069. Unfortunately, the NMC can't talk to the card once it has erased its
  1070. flash memory and then aborted a download.  This happened once before to
  1071. a digital (not an Analog/Digital) quad and the only solution was to
  1072. return the card to USR.
  1073.  
  1074.  
  1075. > 
  1076. > > Anyone have any suggestions?  Surely, a problem this widespread through
  1077. > > a small ISP like ours is occuring undetected across hundreds of other
  1078. > > ISPs.
  1079. > 
  1080. > It sounds to me like you may have had some corruption during a code
  1081. > upgrade.  I suggest the following process during any upgrade:
  1082. > 
  1083. >   * Download the new code.
  1084. >   * Restore all modems to factory defaults (we restore to the hardware
  1085. >     flow control configuration via the NMC - equivalent to AT&F1)
  1086. >   * Reprogram any settings you change from the defaults.
  1087. >   * Save the modem to NVRAM.
  1088.  
  1089.  
  1090. I am going to replace the seven quad cards with sticky 'DTE default
  1091. rates' and put them in a spare chassis and see what, if any, luck I have
  1092. in trying to reconfigure or reflash the code (i.e., destroy them.)
  1093. before I send them back to USR for replacement.
  1094.  
  1095. > 
  1096. > In this case, I'd suggest doing the restore/program/save cycle on all
  1097. > of your modems and see if anything changes.
  1098. > 
  1099. > While forward upgrades in code are always supposed to maintain
  1100. > settings, it doesn't always work that way - particularly when new
  1101. > releases add new settings and/or start using internal locations that
  1102. > may not have been cleared properly.
  1103.  
  1104.  
  1105. Normally, We do a save to NVRAM, Restore from Defaults, Restore fom
  1106. NVRAM after we upgrade any firmware.  I don't know of any other
  1107. procedure to flush out the old code.
  1108.  
  1109. I guess no one else is aware of having intermittent slow connections due
  1110. to faulty quads in their hubs. Personally, I find it a little scary that
  1111. a quad card can sit there in a such a state without any indication of a
  1112. problem.....
  1113.  
  1114. -JJ
  1115.  
  1116. -
  1117.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1118.  with "unsubscribe usr-tc" in the body of the message.
  1119.  For information on digests or retrieving files and old messages send
  1120.  "help" to the same address.  Do not use quotes in your message.
  1121.  
  1122.  
  1123. -------------------------------------------------------------------------------
  1124.  
  1125. From: Jeff Mcadams <jeffm@iglou.com>
  1126. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  1127. Date: 01 Mar 1999 15:30:32 -0500 (EST)
  1128.  
  1129. Thus spake Jim Johnson
  1130. >David Bolen wrote:
  1131. >> You don't need a console port for SDL - that's what the NMC is for :-)
  1132.  
  1133. >Unfortunately, the NMC can't talk to the card once it has erased its
  1134. >flash memory and then aborted a download.  
  1135.  
  1136. Oh, nonsense...I've done this many times.  It takes a rare situation
  1137. indeed to make a card not take code.  The NMC can still throw code on a
  1138. flash-erased quad with no problem.  Try a hardware reset on the slot,
  1139. give it a minute or two, then try the download again.
  1140.  
  1141. >This happened once before to
  1142. >a digital (not an Analog/Digital) quad and the only solution was to
  1143. >return the card to USR.
  1144.  
  1145. Someone at USR gave you a load of hooey there.
  1146.  
  1147. >I guess no one else is aware of having intermittent slow connections due
  1148. >to faulty quads in their hubs. Personally, I find it a little scary that
  1149. >a quad card can sit there in a such a state without any indication of a
  1150. >problem.....
  1151.  
  1152. That's because its not a problem...its a configuration option.  Now, if
  1153. the configuration option really isn't sticking when you set it, save it,
  1154. and everything, then *that* might be a problem, but I seriously doubt
  1155. that the card is bad and/or needs to be returned to USR.
  1156. -- 
  1157. Jeff McAdams                            Email: jeffm@iglou.com
  1158. Head Network Administrator              Voice: (502) 966-3848
  1159. IgLou Internet Services                        (800) 436-4456
  1160.  
  1161. -
  1162.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1163.  with "unsubscribe usr-tc" in the body of the message.
  1164.  For information on digests or retrieving files and old messages send
  1165.  "help" to the same address.  Do not use quotes in your message.
  1166.  
  1167.  
  1168. -------------------------------------------------------------------------------
  1169.  
  1170. From: David Bolen <db3l@ans.net>
  1171. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  1172. Date: 01 Mar 1999 15:31:30 EST
  1173.  
  1174. Jim Johnson <jim@perigee.net> writes:
  1175.  
  1176. > Unfortunately, the NMC can't talk to the card once it has erased its
  1177. > flash memory and then aborted a download.  This happened once before to
  1178. > a digital (not an Analog/Digital) quad and the only solution was to
  1179. > return the card to USR.
  1180.  
  1181. It is possible to get a card in that state (although if you keep at
  1182. least one NIC around you can just use PCSDL after getting the card
  1183. returned to a central site of yours), but it's not easy.  I've aborted
  1184. many a quad download in all sorts of states and generally restarting
  1185. the download is fine.  I think you can get in trouble if the NMC
  1186. resets before it is retried, but I'd have to run some tests to be sure.
  1187.  
  1188. > Normally, We do a save to NVRAM, Restore from Defaults, Restore fom
  1189. > NVRAM after we upgrade any firmware.  I don't know of any other
  1190. > procedure to flush out the old code.
  1191.  
  1192. This is sort of a strange procedure.  Assuming we're talking about
  1193. following a code upgrade, first, the initial save is going to save a
  1194. potentially bad state (post-upgrade) to NVRAM.  Then, even though you
  1195. restore from defaults, you then restore from NVRAM which you
  1196. previously saved, so your net result is no change.  In effect, if
  1197. there was a problem with some internal setting, the above procedure
  1198. explicitly preserves that problem :-)
  1199.  
  1200. The point I was suggesting was that sometimes various internal status
  1201. or configuration information is in a bad state following a code
  1202. upgrade.  Restoring to factory defaults resets all internal
  1203. information (so even if the newer code used previously unused
  1204. settings, restoring under control of that newer code flushes those
  1205. out), which you can then adjust and save to NVRAM.
  1206.  
  1207. That's why it's important that the first thing you do post-download is
  1208. restoring from factory defaults.  This resets the internal state for
  1209. all known information (to the currently running code).  Only save to
  1210. NVRAM _after_ restoring, or else you may preserve the bad information.
  1211.  
  1212. > I guess no one else is aware of having intermittent slow connections due
  1213. > to faulty quads in their hubs. Personally, I find it a little scary that
  1214. > a quad card can sit there in a such a state without any indication of a
  1215. > problem.....
  1216.  
  1217. I've definitely seen quad cards with this 2400bps behavior, but only
  1218. after an upgrade where I didn't follow the restore from factory
  1219. defaults behavior.
  1220.  
  1221. -- David
  1222.  
  1223. /-----------------------------------------------------------------------\
  1224.  \               David Bolen              \  Internet: db3l@ans.net    /
  1225.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  1226.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  1227. \-----------------------------------------------------------------------/
  1228.  
  1229. -
  1230.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1231.  with "unsubscribe usr-tc" in the body of the message.
  1232.  For information on digests or retrieving files and old messages send
  1233.  "help" to the same address.  Do not use quotes in your message.
  1234.  
  1235.  
  1236. -------------------------------------------------------------------------------
  1237.  
  1238. From: John Mies <jmies@advancenet.net>
  1239. Subject: (usr-tc) X2 status in monitoring TCM
  1240. Date: 01 Mar 1999 14:41:34 -0600
  1241.  
  1242. Does anyone know where to find the numbered messages that are connected to
  1243. the X2 status when monitoring? I have a user who is getting a low connect
  1244. rate and the X2 status is ChannelNoSymbolRate (13).
  1245.  
  1246. John Mies
  1247.  
  1248. -
  1249.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1250.  with "unsubscribe usr-tc" in the body of the message.
  1251.  For information on digests or retrieving files and old messages send
  1252.  "help" to the same address.  Do not use quotes in your message.
  1253.  
  1254.  
  1255. -------------------------------------------------------------------------------
  1256.  
  1257. From: "Chris Ashcraft" <Chris_Ashcraft@mw.3com.com>
  1258. Subject: (usr-tc) connecting to hdm console or quad/dsp for outbound
  1259. Date: 01 Mar 1999 10:39:20 -0600
  1260.  
  1261.  
  1262.  
  1263. Hi Mike,
  1264.  
  1265. I'll get back to you about remotely accessing the HDM console. Regarding channel
  1266. testing, refer to Appendix C of the Quad Modem doc set. It is entitled Modem
  1267. Testing. There you should find the information you need.
  1268.  
  1269. All the best,
  1270. /Chris
  1271. 3Com Corp.
  1272.  
  1273. >From usr-tc
  1274.  
  1275.  
  1276.  
  1277. I've seen some hints in ARC documentation/release notes that say there's a
  1278. way to connect to an HDM console through the ARC somehow (presumably over
  1279. the packet bus)...  but I can't find the exact syntax anywhere.  This
  1280. would save me a few serial ports...
  1281.  
  1282. I'm also trying to figure out how to connect to a particular Quad (or DSP)
  1283. to feed it AT commands.  I have a channel on a Quad I suspect is dead and
  1284. I'm trying to poke at it a bit to see if it's really dead...
  1285.  
  1286. Someone want to point me at the relevant chunk of documentation?  Maybe
  1287. "search" in Acrobat just doesn't work well, but I'm having trouble finding
  1288. it.  (Call me blind.)
  1289.  
  1290.  
  1291. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  1292. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  1293. getting beaten by the police, put down the video camera and come help me!"
  1294.  
  1295. -
  1296.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1297.  with "unsubscribe usr-tc" in the body of the message.
  1298.  For information on digests or retrieving files and old messages send
  1299.  "help" to the same address.  Do not use quotes in your message.
  1300.  
  1301.  
  1302. -------------------------------------------------------------------------------
  1303.  
  1304. From: Jeff Mcadams <jeffm@iglou.com>
  1305. Subject: Re: (usr-tc) 3Com Problems.
  1306. Date: 26 Feb 1999 15:18:48 -0500 (EST)
  1307.  
  1308. Thus spake Ricky Beam
  1309. >>Basically, because 3Com refuses to port and support HiPerOS on the
  1310. >>NETServer hardware, our only choice is to buy HiPer Arc cards to replace
  1311. >>all of our NETServer cards.  This amounts to 3Com screwing us over
  1312. >>because we have been customers of theirs long enough to have a large
  1313. >>number of NETServer cards.
  1314.  
  1315. >You cannot blame a company for dropping support for clearly out dated
  1316. >hardware.  The Netservers are 10 year old technology -- 486s.  Why would
  1317. >any company devote large amounts of resources to keeping old shit out there
  1318. >when they _really_ don't want that junk to still be out there?
  1319.  
  1320. I can still buy Cisco 2500's, that's older hardware technology than the
  1321. NETServers by a generation or two.  The hardware technology isn't the
  1322. problem.  If I were demanding VoIP on quads and NETServer's, then you'd
  1323. have a point, but 46 ports of PPP or rlogin?  There's no reason to
  1324. discontinue support of this hardware for that functionality.  I'm
  1325. certainly willing to forgo VoIP and other more advanced technologies if
  1326. I stay on quads and NETServer's...that's only reasonable.
  1327.  
  1328. >Did you go around screaming when Microsoft dropped support for several other
  1329. >platforms?
  1330.  
  1331. I don't pay a great deal of attention to what MSFT does, but to my
  1332. knowledge, they didn't drop support of a product that they sold as
  1333. recently as 6 months ago.
  1334.  
  1335. >>We were told (I *believe* by Tom, though I don't remember this
  1336. >>explicitely) that 3Com's idea is that any and all upgrade deals should
  1337. >>be "revenue positive."  Meaning that 3Com isn't willing to upgrade our
  1338. >>NETServer's to HiPer Arcs because they won't make any money on it.
  1339. >>Again, this goes back to the Bait and Switch argument I made above.
  1340.  
  1341. >No, it goes back to a business that has to make money.  What you are arguing
  1342. >for is a free upgrade path.  
  1343.  
  1344. Wrong.  What I'm arguing for is a fix for MPIP brokenness.  From what it
  1345. seems, the only path that 3Com has left for that fix is a hardware
  1346. upgrade, but that's their choice, not mine.  If they got me a fix for
  1347. MPIP on the NETServers, I'd be a happy camper, but that's not gonna
  1348. happen.
  1349.  
  1350. >That's like going to Dell and arguing that you
  1351. >want a free upgrade from a PPro to a PII machine.  
  1352.  
  1353. If the PPro couldn't be made to perform as advertised and the "fix" for
  1354. that was to get a PII machine, then yeah, I'd think that's appropriate.
  1355. If the "fix" were able to be accomplished via a software upgrade, more
  1356. power to them.
  1357.  
  1358. >3Com is dropping support
  1359. >for the netserver - period.  As of 2/26/1999, 3Com no longer services
  1360. >netservers.
  1361.  
  1362. OK, that's a stupid decision, but that's their decision to make.  My
  1363. point being, they sold me a product that doesn't perform as they
  1364. promised it would (MPIP is broken), and then they're trying to charge me
  1365. again for the fix (whatever that fix may be).  That's Bait and Switch,
  1366. and that's illegal, period.
  1367.  
  1368. >Companies move forward with new technologies.  They cannot continue to support
  1369. >the old stuff for ever 
  1370.  
  1371. I'd hope they could support it for 6 months though.
  1372.  
  1373. >-- if they try to then they end up with MacOS...  And
  1374. >you cannot expect them to out-right give you the new wiz-bang hardware for
  1375. >free.
  1376.  
  1377. Hey, if that's what they're saying the "fix" for their brokenness is,
  1378. then you're darn right I can expect them to do that.
  1379.  
  1380. >[deals...]
  1381. >In this respect, I think 3Com is trying to be reasonable here.  Do the math.
  1382. >After all is said and done, the cost of the new ARC is around 2k$ depending
  1383. >on your particular discount with 3Com or dealer.  We could have upgraded
  1384. >our entire dialup network for somewhere around 100k$.  That's an order
  1385. >of magnitude less than it will cost to replace it with someone else's
  1386. >hardware.  And when you add in personel and training... switching your
  1387. >dialup hardware is major expense and pain in the ass. (We've done it once
  1388. >and about to do it again.)
  1389.  
  1390. Trying, but failing miserably.  I don't care how reasonable the cost of
  1391. these bundles are, its still Bait and Switch, or paying for a fix for
  1392. something that should have worked in the first place.  I agree that
  1393. switching to new dial-up hardware is expensive, but we are considering
  1394. it, as are you.  Why are you considering it?  Because 3Com has treated
  1395. you like dirt?  Because they haven't delivered what they promised?
  1396. That's all I'm saying.
  1397.  
  1398. >>Again, we're having to pay more money because 3Com is unwilling to make 
  1399. >>the situation right when they failed to deliver the capabilities they 
  1400. >>promised.
  1401.  
  1402. >And what did they fail to deliver?  MPIP works.  It just doesn't work
  1403. >very well.
  1404.  
  1405. No, it doesn't work.  Having to reboot a system every 3 hours to provide
  1406. even *minimal* functionality is not what I call working.  Yeah, in my
  1407. first response to Phil I said it works ok, sort of (or actually affirmed
  1408. his statement to that effect), but for real use in a real dial-up
  1409. network, with more than about 300 ports...its not reliable enough to
  1410. really sell it.
  1411.  
  1412. >>                                         Customers such as us that have
  1413. >>had USR/3Com gear for years have to pay more money to keep our equipment
  1414. >>up to date and to work around bugs that 3Com was unable to fix, and
  1415. >>their poor planning in not having an upgrade path available for the
  1416. >>older equipment.
  1417.  
  1418. >What you appear to be expecting is a free migration path...
  1419. >eg. 286 -> 386 -> 486 -> Pentium -> PPro -> PII -> PIII
  1420.  
  1421. No, again, I'm expecting a fix for my bug that I've had a ticket open on
  1422. since April.  If they can do that without me having to get new
  1423. hardware...*wonderful*.  That would even be better than free
  1424. replacement, because even with free replacement, there is still cost
  1425. involved in my time and energy of going to our POPs and doing that
  1426. actual work to do the replacement.  Or if this equipment was bought even
  1427. as much as 2 years ago, I could even understand that.  We bought
  1428. NETServer's (already in the channel I believe) as late as 3 months ago
  1429. though.
  1430.  
  1431. >It costs money to support stuff.  I assume you charge your customers.
  1432. >Do you give your customers a free technological upgrade path?
  1433.  
  1434. Well...where its reasonable to do so, yeah, we do.  We charge the same
  1435. for ISDN that we do for modem dialup.  There are other costs involved to
  1436. the customer, but we don't charge any differently.
  1437.  
  1438. >>                  We have a large number of NETServer cards, and the
  1439. >>only three options that we have are to throw that investment into the
  1440. >>trash, try to sell these things used which throws most of our investment
  1441. >>into the trash, or send them back to 3Com for a $3200 rebate on new
  1442. >>purchases, which still throws a significant investment into the trash.
  1443.  
  1444. >No, it's an investment to keep the existing investment worth something.
  1445. >The money sunk into the netserver hardware years ago is gradually dwindling
  1446. >to nothing.  It's the same with your aging desktop computers; how much did
  1447. >you pay for a 486dx2-66 "power house" a few years ago and what's it worth
  1448. >today?
  1449.  
  1450. I'm still using my 486-33 at home.  The software works, doesn't have any
  1451. killer bugs (won't say there aren't any, but none that affect me), and
  1452. does the job I need of it.  If the NETServers were the same, you would
  1453. hear no complaints from me.  As it is though, they're broken, and seeing
  1454. that they were being sold by 3Com as recently as 6 months ago, I don't
  1455. think its unreasonable to expect better support of them in some way.
  1456. Like I said...I don't really care *how* its done...just as long as it
  1457. *is* done.
  1458.  
  1459. >Don't whine about your investment becoming worthless.  It's not worthless
  1460. >to you simply because of the amount of time and money spent in building it
  1461. >and the same that it will take to replace it.  Even if you completely
  1462. >replaced all of the 3Com hardware, the same thing will happen on down the
  1463. >road.
  1464.  
  1465. >Would Cisco upgrade a 2500 series router to a 2600 series router for free?
  1466.  
  1467. Is Cisco still releasing new software and fixing bugs in 2500 routers?
  1468. Yes...for free even, they're still fully supported.  If Cisco sold me a
  1469. 2500, and I found a killer bug in it 6 months later, then yes, I would
  1470. expect *something* to be done...whether thats a software upgrade, or if
  1471. Cisco was unable to do that, a hardware swap-out to something that did
  1472. work (doesn't even have to be newer as far as I'm concerned, just so
  1473. long as it does what I need) I don't really care, but *something* should
  1474. be done.
  1475.  
  1476. >The answer is "hell no".  It's next to impossible to get any measurable
  1477. >discount out of Cisco -- talk about revenue anal people...
  1478.  
  1479. We get a *heck* of a lot bigger discount for our Cisco equipment than we
  1480. do for our 3Com equipment.
  1481.  
  1482. >>                                                   it may mean swapping
  1483. >>out NETServers for HiPer Arcs at some smaller ratio and throwing in some
  1484. >>DSP's to make up for the port density problems.
  1485.  
  1486. >True, you don't need a hiperARC to drive 48 modems.  I'd expect some sort
  1487. >of deal to increase the density of ports on the hiperARC.  But, in some
  1488. >places, DSP hardware makes no sense.
  1489.  
  1490. Yeah, like I said...if that's cheaper/easier for them to do...I don't
  1491. have any problem with that.  If we have to pay for the upgrades, the
  1492. cheapest route for us is the buy 1 Arc, and 1 DSP, trade in a NETServer
  1493. bundle.  But, like I said earlier, I really don't think I should have to
  1494. pay for a fix for MPIP here.
  1495.  
  1496. >>                                                 I really don't care
  1497. >>*how* 3Com does this, all I know is that I need to get HiPer Arcs on my
  1498. >>network in place of NETServers, and I really don't think I should have
  1499. >>to pay to do it since the only reason I have to do this is because 3Com
  1500. >>couldn't deliver on their promise.
  1501.  
  1502. >Apparently you *do* care...
  1503.  
  1504. No, I don't care *how* its done...just that it *is* done.
  1505.  
  1506. >>3Com needs to start treating their loyal customers like the assets that
  1507. >>we are, rather than just prospective future customers.  If someone asks
  1508.  
  1509. >I would just like to interject a distinction between USR and 3Com...
  1510. >Most (if not all) of the current problems can be traced back to everything
  1511. >being run by 3Com.  It takes time for the dust to settle.  And it takes time
  1512. >for USR customers to get used to dealing with 3Com instead of USR.
  1513.  
  1514. OK, regardless of where the problem traces back to...I'm having to deal
  1515. with 3Com now.
  1516.  
  1517. >>me what I think about 3Com, I tell them that we use TC's, then I tell
  1518. >>them that if they can at all avoid it, not to make the same mistake we
  1519. >>did.  I tell them that 3Com is an absolute *nightmare* to work with
  1520. >>corporately because they don't care about their current customers at
  1521. >>all.  All 3Com seems to care about is where their next source of revenue
  1522. >>is going to be.
  1523.  
  1524. >Well, 3Com corp. aside, USR makes some damn good dialup hardware.  Lucent
  1525. >is about the only ones I know of that rival the USR toys.  (and cisco ain't
  1526. >even on the map.)
  1527.  
  1528. Yup, I generally tell people that...but then I tell them that if I had
  1529. to make the choice over again, I'd buy Cisco.
  1530. -- 
  1531. Jeff McAdams                            Email: jeffm@iglou.com
  1532. Head Network Administrator              Voice: (502) 966-3848
  1533. IgLou Internet Services                        (800) 436-4456
  1534.  
  1535. -
  1536.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1537.  with "unsubscribe usr-tc" in the body of the message.
  1538.  For information on digests or retrieving files and old messages send
  1539.  "help" to the same address.  Do not use quotes in your message.
  1540.  
  1541.  
  1542. -------------------------------------------------------------------------------
  1543.  
  1544. From: Jim Johnson <jim@perigee.net>
  1545. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  1546. Date: 01 Mar 1999 15:56:50 -0500
  1547.  
  1548.  
  1549.  
  1550. David Bolen wrote:
  1551. > 
  1552. > Jim Johnson <jim@perigee.net> writes:
  1553. > 
  1554. > > Unfortunately, the NMC can't talk to the card once it has erased its
  1555. > > flash memory and then aborted a download.  This happened once before to
  1556. > > a digital (not an Analog/Digital) quad and the only solution was to
  1557. > > return the card to USR.
  1558. > 
  1559. > It is possible to get a card in that state (although if you keep at
  1560. > least one NIC around you can just use PCSDL after getting the card
  1561. > returned to a central site of yours), but it's not easy.  I've aborted
  1562. > many a quad download in all sorts of states and generally restarting
  1563. > the download is fine.  I think you can get in trouble if the NMC
  1564. > resets before it is retried, but I'd have to run some tests to be sure.
  1565. > 
  1566. > > Normally, We do a save to NVRAM, Restore from Defaults, Restore fom
  1567. > > NVRAM after we upgrade any firmware.  I don't know of any other
  1568. > > procedure to flush out the old code.
  1569. > 
  1570. > This is sort of a strange procedure.  Assuming we're talking about
  1571. > following a code upgrade, first, the initial save is going to save a
  1572. > potentially bad state (post-upgrade) to NVRAM.  Then, even though you
  1573. > restore from defaults, you then restore from NVRAM which you
  1574. > previously saved, so your net result is no change.  In effect, if
  1575. > there was a problem with some internal setting, the above procedure
  1576. > explicitly preserves that problem :-)
  1577.  
  1578. I realize it seems strange, but according to the USR guy who gave me the
  1579. procedure, it clears out the problem associated with the way their
  1580. firmware changes it size from release to release and leaves code
  1581. fragments in memory.  The 'Restore from Defaults' flushes things out and
  1582. then you can reload you settings again from NVRAM.  Believe it or not,
  1583. this procedure has 'cured' a lot of strange behavior for us over the
  1584. years.
  1585.  
  1586. > 
  1587. > The point I was suggesting was that sometimes various internal status
  1588. > or configuration information is in a bad state following a code
  1589. > upgrade.  Restoring to factory defaults resets all internal
  1590. > information (so even if the newer code used previously unused
  1591. > settings, restoring under control of that newer code flushes those
  1592. > out), which you can then adjust and save to NVRAM.
  1593. > 
  1594. > That's why it's important that the first thing you do post-download is
  1595. > restoring from factory defaults.  This resets the internal state for
  1596. > all known information (to the currently running code).  Only save to
  1597. > NVRAM _after_ restoring, or else you may preserve the bad information.
  1598.  
  1599. You could do it that way, but I have never had to.  In this case, these
  1600. modems have not been upgraded for close to a year. They have also been
  1601. working fine for that long.
  1602.  
  1603. > > I guess no one else is aware of having intermittent slow connections due
  1604. > > to faulty quads in their hubs. Personally, I find it a little scary that
  1605. > > a quad card can sit there in a such a state without any indication of a
  1606. > > problem.....
  1607. > 
  1608. > I've definitely seen quad cards with this 2400bps behavior, but only
  1609. > after an upgrade where I didn't follow the restore from factory
  1610. > defaults behavior.
  1611.  
  1612. Hmmm. Lucky you had such a simple fix.
  1613.  
  1614. Jim
  1615.  
  1616. -
  1617.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1618.  with "unsubscribe usr-tc" in the body of the message.
  1619.  For information on digests or retrieving files and old messages send
  1620.  "help" to the same address.  Do not use quotes in your message.
  1621.  
  1622.  
  1623. -------------------------------------------------------------------------------
  1624.  
  1625. From: David Bolen <db3l@ans.net>
  1626. Subject: Re: (usr-tc) 3Com Problems.
  1627. Date: 01 Mar 1999 15:57:28 EST
  1628.  
  1629. Jeff Mcadams <jeffm@iglou.com> writes:
  1630.  
  1631. > I don't pay a great deal of attention to what MSFT does, but to my
  1632. > knowledge, they didn't drop support of a product that they sold as
  1633. > recently as 6 months ago.
  1634.  
  1635. Can't resist a quick Microsoft bash...
  1636.  
  1637. Can you say OS/2?  Went from full (not to mention a high profile product)
  1638. to no support in a heck of a lot less than 6 months...  They were
  1639. selling $2000-$3000 developer kits up until the day before they
  1640. announced they were dumping it.
  1641.  
  1642. -- David
  1643.  
  1644. /-----------------------------------------------------------------------\
  1645.  \               David Bolen              \  Internet: db3l@ans.net    /
  1646.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  1647.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  1648. \-----------------------------------------------------------------------/
  1649.  
  1650. -
  1651.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1652.  with "unsubscribe usr-tc" in the body of the message.
  1653.  For information on digests or retrieving files and old messages send
  1654.  "help" to the same address.  Do not use quotes in your message.
  1655.  
  1656.  
  1657. -------------------------------------------------------------------------------
  1658.  
  1659. From: Jim Johnson <jim@perigee.net>
  1660. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  1661. Date: 01 Mar 1999 15:58:39 -0500
  1662.  
  1663.  
  1664.  
  1665. Jeff Mcadams wrote:
  1666. > 
  1667. > Thus spake Jim Johnson
  1668. > >David Bolen wrote:
  1669. > >> You don't need a console port for SDL - that's what the NMC is for :-)
  1670. > 
  1671. > >Unfortunately, the NMC can't talk to the card once it has erased its
  1672. > >flash memory and then aborted a download.
  1673. > 
  1674. > Oh, nonsense...I've done this many times.  It takes a rare situation
  1675. > indeed to make a card not take code.  The NMC can still throw code on a
  1676. > flash-erased quad with no problem.  Try a hardware reset on the slot,
  1677. > give it a minute or two, then try the download again.
  1678.  
  1679.  
  1680. Well, I did a hardware reset and it still would not play with the NMC. 
  1681. I also pulled the card out and reseated it and it would not cooperate. 
  1682. I have it here at the main office and it is being as recalcitrant as
  1683. ever. 
  1684.  
  1685. > 
  1686. > >This happened once before to
  1687. > >a digital (not an Analog/Digital) quad and the only solution was to
  1688. > >return the card to USR.
  1689. > 
  1690. > Someone at USR gave you a load of hooey there.
  1691. > 
  1692. > >I guess no one else is aware of having intermittent slow connections due
  1693. > >to faulty quads in their hubs. Personally, I find it a little scary that
  1694. > >a quad card can sit there in a such a state without any indication of a
  1695. > >problem.....
  1696. > 
  1697. > That's because its not a problem...its a configuration option.  Now, if
  1698. > the configuration option really isn't sticking when you set it, save it,
  1699. > and everything, then *that* might be a problem, but I seriously doubt
  1700. > that the card is bad and/or needs to be returned to USR.
  1701. > --
  1702. > Jeff McAdams                            Email: jeffm@iglou.com
  1703. > Head Network Administrator              Voice: (502) 966-3848
  1704. > IgLou Internet Services                        (800) 436-4456
  1705. > 
  1706. > -
  1707. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1708. >  with "unsubscribe usr-tc" in the body of the message.
  1709. >  For information on digests or retrieving files and old messages send
  1710. >  "help" to the same address.  Do not use quotes in your message.
  1711.  
  1712. -
  1713.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1714.  with "unsubscribe usr-tc" in the body of the message.
  1715.  For information on digests or retrieving files and old messages send
  1716.  "help" to the same address.  Do not use quotes in your message.
  1717.  
  1718.  
  1719. -------------------------------------------------------------------------------
  1720.  
  1721. From: beckerr@softrends.com
  1722. Subject: Re: (usr-tc) 3Com Problems.
  1723. Date: 01 Mar 1999 15:59:15 -0500
  1724.  
  1725. On Fri, Feb 26, 1999 at 03:18:48PM -0500, Jeff Mcadams wrote:
  1726. > 
  1727. > >What you appear to be expecting is a free migration path...
  1728. > >eg. 286 -> 386 -> 486 -> Pentium -> PPro -> PII -> PIII
  1729. > 
  1730. > No, again, I'm expecting a fix for my bug that I've had a ticket open on
  1731. > since April.  If they can do that without me having to get new
  1732. > hardware...*wonderful*.  That would even be better than free
  1733. > replacement, because even with free replacement, there is still cost
  1734. > involved in my time and energy of going to our POPs and doing that
  1735. > actual work to do the replacement.  Or if this equipment was bought even
  1736. > as much as 2 years ago, I could even understand that.  We bought
  1737. > NETServer's (already in the channel I believe) as late as 3 months ago
  1738. > though.
  1739. Recall the intel "Pentium FDIV bug"- intel shipped a bunch of chips
  1740. which were broken. Once it was discovered, intel initially said it 
  1741. would only affect a _very_ few people. People started raising holy
  1742. terror, and intel agreed to replace the chips at no cost, to anyone
  1743. who would send them their chip. A hardware fix, at no cost to the 
  1744. consumer. 3Com, bless their hearts, isn't even willing to provide 
  1745. no-cost software fixes. 
  1746.  
  1747.  
  1748. --Ross
  1749.   beckerr@softrends.com
  1750.  
  1751. -
  1752.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1753.  with "unsubscribe usr-tc" in the body of the message.
  1754.  For information on digests or retrieving files and old messages send
  1755.  "help" to the same address.  Do not use quotes in your message.
  1756.  
  1757.  
  1758. -------------------------------------------------------------------------------
  1759.  
  1760. From: Richard Stuplich <dick@dwave.net>
  1761. Subject: (usr-tc) Q. Idle (Exactly)
  1762. Date: 01 Mar 1999 15:10:33 -0600
  1763.  
  1764. Is this how it is done?
  1765.  
  1766. set user default IDLE_TIMEOUT nnn
  1767.  
  1768. Is the 'nnn' in minutes or seconds?
  1769.  
  1770.  
  1771. -
  1772.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1773.  with "unsubscribe usr-tc" in the body of the message.
  1774.  For information on digests or retrieving files and old messages send
  1775.  "help" to the same address.  Do not use quotes in your message.
  1776.  
  1777.  
  1778. -------------------------------------------------------------------------------
  1779.  
  1780. From: David Bolen <db3l@ans.net>
  1781. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  1782. Date: 01 Mar 1999 16:03:40 EST
  1783.  
  1784. Jim Johnson <jim@perigee.net> writes:
  1785.  
  1786. > Well, I did a hardware reset and it still would not play with the NMC. 
  1787. > I also pulled the card out and reseated it and it would not cooperate. 
  1788.  
  1789. Just to check, by "play" you mean accept a download right?  Once the
  1790. card has no code, it won't respond to any normal operations except for
  1791. the download.  Also, if you're finding that the NMC doesn't identify
  1792. the card properly, then you may get stopped by the type check the NMC
  1793. does unless you force the download by setting the force parameter in
  1794. the command table (I'm not sure if you can do this via TCM or not).
  1795.  
  1796. > I have it here at the main office and it is being as recalcitrant as
  1797. > ever. 
  1798.  
  1799. It's always possible that there is something else wrong too - since
  1800. you've got it local, stick a NIC on it (presuming you have at least
  1801. one NIC from some analog or dual card somewhere - if you don't, it
  1802. might be a good thing to get to keep around for the future) and see if
  1803. even PCSDL will work - you may find there's something else going on.
  1804.  
  1805. -- David
  1806.  
  1807. /-----------------------------------------------------------------------\
  1808.  \               David Bolen              \  Internet: db3l@ans.net    /
  1809.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  1810.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  1811. \-----------------------------------------------------------------------/
  1812.  
  1813. -
  1814.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1815.  with "unsubscribe usr-tc" in the body of the message.
  1816.  For information on digests or retrieving files and old messages send
  1817.  "help" to the same address.  Do not use quotes in your message.
  1818.  
  1819.  
  1820. -------------------------------------------------------------------------------
  1821.  
  1822. From: Dan Hollis <goemon@sasami.anime.net>
  1823. Subject: Re: (usr-tc) 3Com Problems.
  1824. Date: 01 Mar 1999 13:09:11 -0800 (PST)
  1825.  
  1826. On Fri, 26 Feb 1999, Jeff Mcadams wrote:
  1827. > I can still buy Cisco 2500's, that's older hardware technology than the
  1828. > NETServers by a generation or two.
  1829.  
  1830. Cisco has EOL'd the 4000 and 4500's. There is no upgrade path.
  1831. What are owners of that technology to do?
  1832.  
  1833. -Dan
  1834.  
  1835.  
  1836. -
  1837.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1838.  with "unsubscribe usr-tc" in the body of the message.
  1839.  For information on digests or retrieving files and old messages send
  1840.  "help" to the same address.  Do not use quotes in your message.
  1841.  
  1842.  
  1843. -------------------------------------------------------------------------------
  1844.  
  1845. From: David Bolen <db3l@ans.net>
  1846. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  1847. Date: 01 Mar 1999 16:14:55 EST
  1848.  
  1849. Jim Johnson <jim@perigee.net> writes:
  1850.  
  1851. > I realize it seems strange, but according to the USR guy who gave me the
  1852. > procedure, it clears out the problem associated with the way their
  1853. > firmware changes it size from release to release and leaves code
  1854. > fragments in memory.
  1855.  
  1856. But it still doesn't make sense, and it wouldn't be the first time
  1857. some bad info got out.  Once running with the new code the in-memory
  1858. map is the new map, and that's what gets written to the flash.
  1859. Restoring may change the in-memory copy, but the later restoration
  1860. from NVRAM would overwrite that again.  I suppose this might clean up
  1861. some values that implicitly go to flash (similar to how AT&Z stuff
  1862. works), but...
  1863.  
  1864. >                                                     Believe it or not,
  1865. > this procedure has 'cured' a lot of strange behavior for us over the
  1866. > years.
  1867.  
  1868. Well, I'm hardly one to speak against something that has worked for
  1869. you.  You might give a shot at my procedure for some of your problem
  1870. modems just for the heck of it though - can't really hurt, could it?
  1871.  
  1872. -- David
  1873.  
  1874. /-----------------------------------------------------------------------\
  1875.  \               David Bolen              \  Internet: db3l@ans.net    /
  1876.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  1877.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  1878. \-----------------------------------------------------------------------/
  1879.  
  1880. -
  1881.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1882.  with "unsubscribe usr-tc" in the body of the message.
  1883.  For information on digests or retrieving files and old messages send
  1884.  "help" to the same address.  Do not use quotes in your message.
  1885.  
  1886.  
  1887. -------------------------------------------------------------------------------
  1888.  
  1889. From: MegaZone <megazone@megazone.org>
  1890. Subject: Re: (usr-tc) HARC Idle q....
  1891. Date: 01 Mar 1999 13:18:59 -0800 (PST)
  1892.  
  1893. Once upon a time beckerr@softrends.com shaped the electrons to say...
  1894. >on the HiperARC... my question is this- does the HiperARC actually
  1895. >take note of the standard RADIUS attribute "Idle-Session-Timeout"?
  1896.  
  1897. That's Idle-Timeout and Session-Timeout, two different things.
  1898.  
  1899. -MZ
  1900. -- 
  1901. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  1902. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  1903. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  1904. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  1905. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  1906.  
  1907. -
  1908.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1909.  with "unsubscribe usr-tc" in the body of the message.
  1910.  For information on digests or retrieving files and old messages send
  1911.  "help" to the same address.  Do not use quotes in your message.
  1912.  
  1913.  
  1914. -------------------------------------------------------------------------------
  1915.  
  1916. From: Jim Johnson <jim@perigee.net>
  1917. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  1918. Date: 01 Mar 1999 16:30:13 -0500
  1919.  
  1920.  
  1921. David Bolen wrote:
  1922. > 
  1923. > Jim Johnson <jim@perigee.net> writes:
  1924. > 
  1925. > > Well, I did a hardware reset and it still would not play with the NMC.
  1926. > > I also pulled the card out and reseated it and it would not cooperate.
  1927. > 
  1928. > Just to check, by "play" you mean accept a download right?  Once the
  1929. > card has no code, it won't respond to any normal operations except for
  1930. > the download.  Also, if you're finding that the NMC doesn't identify
  1931. > the card properly, then you may get stopped by the type check the NMC
  1932. > does unless you force the download by setting the force parameter in
  1933. > the command table (I'm not sure if you can do this via TCM or not).
  1934. > 
  1935. > > I have it here at the main office and it is being as recalcitrant as
  1936. > > ever.
  1937. > 
  1938. > It's always possible that there is something else wrong too - since
  1939. > you've got it local, stick a NIC on it (presuming you have at least
  1940. > one NIC from some analog or dual card somewhere - if you don't, it
  1941. > might be a good thing to get to keep around for the future) and see if
  1942. > even PCSDL will work - you may find there's something else going on.
  1943. > 
  1944.  
  1945. Can you use a NIC on the back of the chassis on the digital quad modem? 
  1946. That would be a useful NIC to keep around if it would work.
  1947.  
  1948. Jim
  1949.  
  1950. -
  1951.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1952.  with "unsubscribe usr-tc" in the body of the message.
  1953.  For information on digests or retrieving files and old messages send
  1954.  "help" to the same address.  Do not use quotes in your message.
  1955.  
  1956.  
  1957. -------------------------------------------------------------------------------
  1958.  
  1959. From: Richard Stuplich <dick@dwave.net>
  1960. Subject: Re: (usr-tc) 3Com Problems.
  1961. Date: 01 Mar 1999 15:40:15 -0600
  1962.  
  1963. I'd bet they will use Cisco 4000 and 4500's, happily, for many years to
  1964. come because they don't have horrible flaws in the hardware and code like
  1965. ALL the x2 racks I have ever used.
  1966.  
  1967. The analogy isn't relevant.  To 'stick' us with the USR/3COM crap and say
  1968. "everyone EOLs products" is irresponsible.  I smell a class action law suit.
  1969.  
  1970. My USR and 3COM equipment has NEVER performed as advertised!
  1971.  
  1972. Anyone suing 3COM, sign me up!
  1973.  
  1974. At 01:09 PM 3/1/99 -0800, you wrote:
  1975. >On Fri, 26 Feb 1999, Jeff Mcadams wrote:
  1976. >> I can still buy Cisco 2500's, that's older hardware technology than the
  1977. >> NETServers by a generation or two.
  1978. >
  1979. >Cisco has EOL'd the 4000 and 4500's. There is no upgrade path.
  1980. >What are owners of that technology to do?
  1981. >
  1982. >-Dan
  1983. >
  1984. >
  1985. >-
  1986. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  1987. > with "unsubscribe usr-tc" in the body of the message.
  1988. > For information on digests or retrieving files and old messages send
  1989. > "help" to the same address.  Do not use quotes in your message.
  1990. >
  1991. >
  1992.  
  1993.  Richard B. Stuplich                     DataWave, Not just faster, Better.
  1994.  President, DataWave Technologies        17 T1 circuits and growing strong.
  1995. DataWave, Wausau's first local ISP to have a direct connection to the
  1996. midwest NAP, Frame Relay, ISDN, x2, k56Flex, v.90.  The only area ISP to
  1997. have redundant T1 NAP connections, All modem compatibility and a staff
  1998. dedicated exclusively to providing Internet Service to this area.
  1999. This E-Mail Copyright 1999 Richard Stuplich, see http://dw.net/cr/
  2000.  
  2001. -
  2002.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2003.  with "unsubscribe usr-tc" in the body of the message.
  2004.  For information on digests or retrieving files and old messages send
  2005.  "help" to the same address.  Do not use quotes in your message.
  2006.  
  2007.  
  2008. -------------------------------------------------------------------------------
  2009.  
  2010. From: MegaZone <megazone@megazone.org>
  2011. Subject: Re: (usr-tc) 3Com Problems.
  2012. Date: 01 Mar 1999 13:31:11 -0800 (PST)
  2013.  
  2014. Once upon a time Dan Hollis shaped the electrons to say...
  2015. >On Fri, 26 Feb 1999, Jeff Mcadams wrote:
  2016. >> I can still buy Cisco 2500's, that's older hardware technology than the
  2017. >> NETServers by a generation or two.
  2018. >Cisco has EOL'd the 4000 and 4500's. There is no upgrade path.
  2019. >What are owners of that technology to do?
  2020.  
  2021. Apples and oranges.  They announced it well in advance.  They provide
  2022. maintanence releases of software.  In other words they didn't sell a product
  2023. as *new* with broken features, and then fail to provide any fixes  - and
  2024. instead  tell those who bought the old gear to buy new gear.  Why is it
  2025. hard to see the difference?
  2026.  
  2027. No one has yet presented an equivalent example  - except perhaps MS and
  2028. OS/2.  And I wouldn't want to be compared to MS for customer service.
  2029.  
  2030. -MZ
  2031. -- 
  2032. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  2033. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  2034. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  2035. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  2036. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  2037.  
  2038.  
  2039. -
  2040.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2041.  with "unsubscribe usr-tc" in the body of the message.
  2042.  For information on digests or retrieving files and old messages send
  2043.  "help" to the same address.  Do not use quotes in your message.
  2044.  
  2045.  
  2046. -------------------------------------------------------------------------------
  2047.  
  2048. From: David Bolen <db3l@ans.net>
  2049. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  2050. Date: 01 Mar 1999 16:35:45 EST
  2051.  
  2052. Jim Johnson <jim@perigee.net> writes:
  2053.  
  2054. > Can you use a NIC on the back of the chassis on the digital quad modem? 
  2055. > That would be a useful NIC to keep around if it would work.
  2056.  
  2057. Yep - any of the quad NICs (either RS232 only or RS232/RJ11) will work
  2058. with any variant of quad cards, although only analog cards can use the
  2059. RJ11 ports if present.
  2060.  
  2061. All of the quad cards understand how to use a NIC for their serial DTE
  2062. port (unless overridden by a packet bus connection formed from a
  2063. card such as the NETServer).
  2064.  
  2065. The "analog" versus "digital" difference in the cards is what they can
  2066. do with their "line side" interface.  An analog card can only use the
  2067. RJ11 ports on a NIC, whereas a digital card can only use the TDM bus
  2068. to a circuit card such as the dual T1/PRI cards.  A dual quad card can
  2069. do both.
  2070.  
  2071. -- David
  2072.  
  2073. /-----------------------------------------------------------------------\
  2074.  \               David Bolen              \  Internet: db3l@ans.net    /
  2075.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  2076.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  2077. \-----------------------------------------------------------------------/
  2078.  
  2079. -
  2080.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2081.  with "unsubscribe usr-tc" in the body of the message.
  2082.  For information on digests or retrieving files and old messages send
  2083.  "help" to the same address.  Do not use quotes in your message.
  2084.  
  2085.  
  2086. -------------------------------------------------------------------------------
  2087.  
  2088. From: Jeff Mcadams <jeffm@iglou.com>
  2089. Subject: Re: (usr-tc) 3Com Problems.
  2090. Date: 01 Mar 1999 16:46:34 -0500 (EST)
  2091.  
  2092. Thus spake Dan Hollis
  2093. >On Fri, 26 Feb 1999, Jeff Mcadams wrote:
  2094. >> I can still buy Cisco 2500's, that's older hardware technology than the
  2095. >> NETServers by a generation or two.
  2096.  
  2097. >Cisco has EOL'd the 4000 and 4500's. There is no upgrade path.
  2098. >What are owners of that technology to do?
  2099.  
  2100. A quote from Cisco's web page concerning the EOL'ing of the 4000 and
  2101. 4500 (note, they aren't EOL'ing the 4500-M, only the 4500, 4000 and 
  2102. 4000-M):
  2103.  
  2104.     Because Cisco is committed to upholding its investment protection
  2105.     guarantee, many EOL products can be upgraded or traded in for newer
  2106.     products.
  2107.  
  2108. And, since these products have a large commonality with the non-EOL'ed
  2109. products in the family (4500-M and 4700-M) many of the new NP's will
  2110. work in the EOL'ed boxes, as well as new versions of IOS will still
  2111. work in at least the 4500 (same processor as the 4500-M and 4700-M).
  2112.  
  2113. In short, Cisco is *very* good about providing upgrade paths for EOL'ed
  2114. products, and even still providing bug fixes (though non-supported).
  2115. -- 
  2116. Jeff McAdams                            Email: jeffm@iglou.com
  2117. Head Network Administrator              Voice: (502) 966-3848
  2118. IgLou Internet Services                        (800) 436-4456
  2119.  
  2120. -
  2121.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2122.  with "unsubscribe usr-tc" in the body of the message.
  2123.  For information on digests or retrieving files and old messages send
  2124.  "help" to the same address.  Do not use quotes in your message.
  2125.  
  2126.  
  2127. -------------------------------------------------------------------------------
  2128.  
  2129. From: Mike Andrews <mandrews@termfrost.org>
  2130. Subject: Re: (usr-tc) connecting to hdm console or quad/dsp for outbound
  2131. Date: 01 Mar 1999 16:52:47 -0500 (EST)
  2132.  
  2133. On Mon, 1 Mar 1999, Tatai SV Krishnan wrote:
  2134.  
  2135. > On Sun, 28 Feb 1999, Mike Andrews wrote:
  2136. > 
  2137. > > Great, just what I needed.  Now why would a Quad modem get a DSP Interrupt
  2138. > > Timeout when trying to answer a call...
  2139. > 
  2140. > Where are you see thins?  Is this on a ati6 screen on the modem? or 
  2141. > something in the syslog?
  2142.  
  2143. ATI6, under "failure to connect reason".  I think I get a DTE Ring No
  2144. Answer snmp trap around the same time -- I'm not sure because I changed
  2145. that Dual PRI card to fixed assignment and routed calls around the dud
  2146. modem.  I put it back online today though so we'll see if it's cleared
  2147. itself or not.
  2148.  
  2149.  
  2150. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  2151. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  2152. getting beaten by the police, put down the video camera and come help me!"
  2153.  
  2154.  
  2155. -
  2156.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2157.  with "unsubscribe usr-tc" in the body of the message.
  2158.  For information on digests or retrieving files and old messages send
  2159.  "help" to the same address.  Do not use quotes in your message.
  2160.  
  2161.  
  2162. -------------------------------------------------------------------------------
  2163.  
  2164. From: Dan Hollis <goemon@sasami.anime.net>
  2165. Subject: Re: (usr-tc) 3Com Problems.
  2166. Date: 01 Mar 1999 13:53:38 -0800 (PST)
  2167.  
  2168. On Mon, 1 Mar 1999, Richard Stuplich wrote:
  2169. > The analogy isn't relevant.  To 'stick' us with the USR/3COM crap and say
  2170. > "everyone EOLs products" is irresponsible.  I smell a class action law suit.
  2171.  
  2172. Ahh, the good old american pastime -- sue! Litigate! Doesnt it just give
  2173. you warm fuzzies. Living up to the american stereotype.
  2174.  
  2175. -Dan
  2176.  
  2177.  
  2178. -
  2179.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2180.  with "unsubscribe usr-tc" in the body of the message.
  2181.  For information on digests or retrieving files and old messages send
  2182.  "help" to the same address.  Do not use quotes in your message.
  2183.  
  2184.  
  2185. -------------------------------------------------------------------------------
  2186.  
  2187. From: David Bolen <db3l@ans.net>
  2188. Subject: Re: (usr-tc) connecting to hdm console or quad/dsp for outbound
  2189. Date: 01 Mar 1999 16:58:32 EST
  2190.  
  2191. Mike Andrews <mandrews@termfrost.org> writes:
  2192.  
  2193. > On Sun, 28 Feb 1999, Mike Andrews wrote:
  2194. > 
  2195. > > Great, just what I needed.  Now why would a Quad modem get a DSP Interrupt
  2196. > > Timeout when trying to answer a call...
  2197. (...)
  2198. > ATI6, under "failure to connect reason".  I think I get a DTE Ring No
  2199. > Answer snmp trap around the same time -- I'm not sure because I changed
  2200. > that Dual PRI card to fixed assignment and routed calls around the dud
  2201. > modem.  I put it back online today though so we'll see if it's cleared
  2202. > itself or not.
  2203.  
  2204. An occasional DSP interrupt timeout can just be a software problem,
  2205. potentially if the code got into a bad state - for which a slot reset
  2206. (not just a modem reset) should clean things up.
  2207.  
  2208. However, it could also be an indication of a failing DSP chip
  2209. (failing to generate a programmed interrupt), in which case it will
  2210. probably be the failure cause for the majority of calls handled by
  2211. that modem, and you'll want to replace the hardware.
  2212.  
  2213. -- David
  2214.  
  2215. /-----------------------------------------------------------------------\
  2216.  \               David Bolen              \  Internet: db3l@ans.net    /
  2217.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  2218.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  2219. \-----------------------------------------------------------------------/
  2220.  
  2221. -
  2222.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2223.  with "unsubscribe usr-tc" in the body of the message.
  2224.  For information on digests or retrieving files and old messages send
  2225.  "help" to the same address.  Do not use quotes in your message.
  2226.  
  2227.  
  2228. -------------------------------------------------------------------------------
  2229.  
  2230. From: Ricky Beam <jfbeam@enterprise.interpath.net>
  2231. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  2232. Date: 01 Mar 1999 16:59:37 -0500 (EST)
  2233.  
  2234. Jim Johnson was heard to say:
  2235. >I realize it seems strange, but according to the USR guy who gave me the
  2236. >procedure, it clears out the problem associated with the way their
  2237. >firmware changes it size from release to release and leaves code
  2238. >fragments in memory.  The 'Restore from Defaults' flushes things out and
  2239. >then you can reload you settings again from NVRAM.  Believe it or not,
  2240. >this procedure has 'cured' a lot of strange behavior for us over the
  2241. >years.
  2242.  
  2243. You should do this because the flash upgrade proceedure does not always
  2244. translate the NVRAM setting correctly from version to version, esp. for
  2245. downgrades and skipped version upgrades, etc.  I cannot really blame them
  2246. as that's a fairly complex problem to be able to translate any NVRAM config
  2247. to any other NVRAM config.
  2248.  
  2249. --Ricky
  2250.  
  2251.  
  2252. -
  2253.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2254.  with "unsubscribe usr-tc" in the body of the message.
  2255.  For information on digests or retrieving files and old messages send
  2256.  "help" to the same address.  Do not use quotes in your message.
  2257.  
  2258.  
  2259. -------------------------------------------------------------------------------
  2260.  
  2261. From: David Bolen <db3l@ans.net>
  2262. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  2263. Date: 01 Mar 1999 17:07:41 EST
  2264.  
  2265. Ricky Beam <jfbeam@enterprise.interpath.net> writes:
  2266.  
  2267. > You should do this because the flash upgrade proceedure does not always
  2268. > translate the NVRAM setting correctly from version to version, esp. for
  2269. > downgrades and skipped version upgrades, etc.  I cannot really blame them
  2270. > as that's a fairly complex problem to be able to translate any NVRAM config
  2271. > to any other NVRAM config.
  2272.  
  2273. While some paths may be problematic (specifically downgrading, since
  2274. code X can't be expected to know what code Y is doing), I sort of
  2275. disagree in the general case, and certainly in the upgrade case.
  2276. Future code should always be able to migrate older configs, since
  2277. they'll know exactly what was there.  Proper design and identification
  2278. of the parameter storage can make this very doable.  Heck, proper
  2279. parameterization of configuration information should make any code
  2280. changes adjust transparently, with a downgrade case simply ignoring or
  2281. clearing unknown (new features no longer supported) configuration info.
  2282.  
  2283. Not to mention that in the quad case, I don't believe I've seen cases
  2284. other than augmenting existing configuration information for upgrades
  2285. - e.g., register ## always remains the same, with new features being
  2286. added as new registers, or by using previously reserved bits in
  2287. existing registers.
  2288.  
  2289. I do know that the stated goal is to permit an upgrade completely
  2290. transparently, it's just that they don't always hit the goal.  Not too
  2291. much of a biggie given the workaround but I do think that not being
  2292. able to at least handle an upgrade path is a bug.
  2293.  
  2294. -- David
  2295.  
  2296. /-----------------------------------------------------------------------\
  2297.  \               David Bolen              \  Internet: db3l@ans.net    /
  2298.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  2299.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  2300. \-----------------------------------------------------------------------/
  2301.  
  2302. -
  2303.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2304.  with "unsubscribe usr-tc" in the body of the message.
  2305.  For information on digests or retrieving files and old messages send
  2306.  "help" to the same address.  Do not use quotes in your message.
  2307.  
  2308.  
  2309. -------------------------------------------------------------------------------
  2310.  
  2311. From: MegaZone <megazone@megazone.org>
  2312. Subject: Re: (usr-tc) 3Com Problems.
  2313. Date: 01 Mar 1999 14:23:46 -0800 (PST)
  2314.  
  2315. Once upon a time Dan Hollis shaped the electrons to say...
  2316. >On Mon, 1 Mar 1999, Richard Stuplich wrote:
  2317. >> The analogy isn't relevant.  To 'stick' us with the USR/3COM crap and say
  2318. >> "everyone EOLs products" is irresponsible.  I smell a class action law suit.
  2319. >Ahh, the good old american pastime -- sue! Litigate! Doesnt it just give
  2320. >you warm fuzzies. Living up to the american stereotype.
  2321.  
  2322. Yes, damn right!  While there are way to many bullshit lawsuits, just
  2323. because there are so many crappy ones does not mean that you should not
  2324. file one when there is a good reason.  That is why the courts are there.
  2325. 3Com loves to use the courts to their advantage if they can, I see nothing
  2326. wrong with shafted customers using the courts to obtain satisfaction - if
  2327. 3Com won't do it themselves.  And it does not appear that they are going
  2328. to provide a solution to the flaws in their product.  They sold a defective
  2329. product and are refusing to fix it, and are in fact trying to use it to
  2330. sell more product as the 'fix'.  Grabbing a jar or Vaseline and taking it
  2331. quietly will just allow them to continue to do the same thing again and
  2332. again.  Aside from the immediate shafting, it is also a bad business
  2333. practice that should be strongly discouraged.  It is looking like the
  2334. courts may be the only way to get 3Com to cough up a fix.
  2335.  
  2336. People shout 'sue' quite a bit, usually I blast them for being crazy.
  2337. Like the folks who think suing over less than perfect PCM modem connects
  2338. is a good idea - that's stupid.  But in this case I'm surprised it hasn't
  2339. happened yet.
  2340.  
  2341. -MZ
  2342. -- 
  2343. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  2344. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  2345. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  2346. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  2347. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  2348.  
  2349. -
  2350.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2351.  with "unsubscribe usr-tc" in the body of the message.
  2352.  For information on digests or retrieving files and old messages send
  2353.  "help" to the same address.  Do not use quotes in your message.
  2354.  
  2355.  
  2356. -------------------------------------------------------------------------------
  2357.  
  2358. From: Bob Purdon <bobp@southcom.com.au>
  2359. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  2360. Date: 02 Mar 1999 09:24:27 +1100 (EST)
  2361.  
  2362.  
  2363. > > You don't need a console port for SDL - that's what the NMC is for :-)
  2364. > 
  2365. > Unfortunately, the NMC can't talk to the card once it has erased its
  2366. > flash memory and then aborted a download.
  2367.  
  2368. I beg to differ...
  2369.  
  2370. I have one quad here that's dicky.  I had trouble getting the PRI to stop
  2371. sending it calls, so I started a download, aborted, and left it in a
  2372. non-operational state.
  2373.  
  2374. A week or two later I wanted to try something, so I jumped into TCM and
  2375. flashed away...
  2376.  
  2377. > Normally, We do a save to NVRAM, Restore from Defaults, Restore fom
  2378. > NVRAM after we upgrade any firmware.
  2379.  
  2380. That's probably the problem - you're saving the old values, doing a reset,
  2381. and then putting the old values over the top.  In effect, you've done
  2382. nothing.
  2383.  
  2384. What we do is flash the card, reset to hardware flow control defaults,
  2385. make any local changes, and save to NVRAM.  Works for us.
  2386.  
  2387. > I guess no one else is aware of having intermittent slow connections
  2388. > due to faulty quads in their hubs. Personally, I find it a little
  2389. > scary that a quad card can sit there in a such a state without any
  2390. > indication of a problem.....
  2391.  
  2392. Never seen it here in production.  I've seen it once when I forgot to
  2393. reset a card to factory defaults after an upgrade though.
  2394.  
  2395. Regards,
  2396.  
  2397. Bob Purdon,
  2398. Technical Manager,
  2399. Southern Internet Services.
  2400.  
  2401.  
  2402. -
  2403.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2404.  with "unsubscribe usr-tc" in the body of the message.
  2405.  For information on digests or retrieving files and old messages send
  2406.  "help" to the same address.  Do not use quotes in your message.
  2407.  
  2408.  
  2409. -------------------------------------------------------------------------------
  2410.  
  2411. From: Bob Purdon <bobp@southcom.com.au>
  2412. Subject: Re: (usr-tc) 3Com Problems.
  2413. Date: 02 Mar 1999 09:32:05 +1100 (EST)
  2414.  
  2415.  
  2416. > > I can still buy Cisco 2500's, that's older hardware technology than the
  2417. > > NETServers by a generation or two.
  2418. > 
  2419. > Cisco has EOL'd the 4000 and 4500's. There is no upgrade path.
  2420. > What are owners of that technology to do?
  2421.  
  2422. Keep their gear.  Cisco still provide IOS for those boxes, and still
  2423. actively support them (as far as I'm aware anyway).
  2424.  
  2425. I'd be happy for 3COM to do the same.
  2426.  
  2427. Regards,
  2428.  
  2429. Bob Purdon,
  2430. Technical Manager,
  2431. Southern Internet Services.
  2432.  
  2433.  
  2434. -
  2435.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2436.  with "unsubscribe usr-tc" in the body of the message.
  2437.  For information on digests or retrieving files and old messages send
  2438.  "help" to the same address.  Do not use quotes in your message.
  2439.  
  2440.  
  2441. -------------------------------------------------------------------------------
  2442.  
  2443. From: Bob Purdon <bobp@southcom.com.au>
  2444. Subject: Re: (usr-tc) ALERT - Widespread Problem with Quads...
  2445. Date: 02 Mar 1999 09:34:02 +1100 (EST)
  2446.  
  2447.  
  2448. > Can you use a NIC on the back of the chassis on the digital quad modem? 
  2449.  
  2450. Yes.
  2451.  
  2452. > That would be a useful NIC to keep around if it would work.
  2453.  
  2454. Definitely.
  2455.  
  2456. Regards,
  2457.  
  2458. Bob Purdon,
  2459. Technical Manager,
  2460. Southern Internet Services.
  2461.  
  2462.  
  2463. -
  2464.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2465.  with "unsubscribe usr-tc" in the body of the message.
  2466.  For information on digests or retrieving files and old messages send
  2467.  "help" to the same address.  Do not use quotes in your message.
  2468.  
  2469.  
  2470. -------------------------------------------------------------------------------
  2471.  
  2472. From: Ricky Beam <jfbeam@enterprise.interpath.net>
  2473. Subject: Re: (usr-tc) 3Com Problems.
  2474. Date: 01 Mar 1999 17:42:29 -0500 (EST)
  2475.  
  2476. Bob Purdon was heard to say:
  2477. >> Cisco has EOL'd the 4000 and 4500's. There is no upgrade path.
  2478. >> What are owners of that technology to do?
  2479. >
  2480. >Keep their gear.  Cisco still provide IOS for those boxes, and still
  2481. >actively support them (as far as I'm aware anyway).
  2482.  
  2483. For now anyway.  Cisco may eventually stop generating IOS for it, but I
  2484. somehow doubt it unless IOS sees some major changes in coming years.
  2485.  
  2486. >I'd be happy for 3COM to do the same.
  2487.  
  2488. So would I and most of the Netserver owners.  48port TC hardware is good
  2489. for lots of places.  3Com seems to be going after the top end of the dialup
  2490. spectrum.  Placing a 200Mhz 603e in a chassis to run 48 or even 96 ports
  2491. seems a little like overkill.  If they wrote nice, clean, efficient code
  2492. for the 486dx4-100 netservers, the 10 year old technology could last another
  2493. 10 years.  (I still have a 13-year-old Ford Tempo :-))
  2494.  
  2495. --Ricky
  2496.  
  2497.  
  2498. -
  2499.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2500.  with "unsubscribe usr-tc" in the body of the message.
  2501.  For information on digests or retrieving files and old messages send
  2502.  "help" to the same address.  Do not use quotes in your message.
  2503.  
  2504.  
  2505. -------------------------------------------------------------------------------
  2506.  
  2507. From: Dan Hollis <goemon@sasami.anime.net>
  2508. Subject: Re: (usr-tc) 3Com Problems.
  2509. Date: 01 Mar 1999 14:43:37 -0800 (PST)
  2510.  
  2511. On Mon, 1 Mar 1999, MegaZone wrote:
  2512. > People shout 'sue' quite a bit, usually I blast them for being crazy.
  2513. > Like the folks who think suing over less than perfect PCM modem connects
  2514. > is a good idea - that's stupid.  But in this case I'm surprised it hasn't
  2515. > happened yet.
  2516.  
  2517. Actually the person I would most like to sue is the idiot engineer who
  2518. dreamed up the plague that is now 'analogue 56k'. If that wasnt a
  2519. hyper-extended promise then I dont know what is. 56k is the single biggest
  2520. headache in ISP history. Ever. Period.
  2521.  
  2522. Actually you can include all the marketing teams who trumpeted 56k like
  2523. the second coming.
  2524.  
  2525. -Dan
  2526.  
  2527.  
  2528. -
  2529.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2530.  with "unsubscribe usr-tc" in the body of the message.
  2531.  For information on digests or retrieving files and old messages send
  2532.  "help" to the same address.  Do not use quotes in your message.
  2533.  
  2534.  
  2535. -------------------------------------------------------------------------------
  2536.  
  2537. From: Ricky Beam <jfbeam@enterprise.interpath.net>
  2538. Subject: Re: (usr-tc) 3Com Problems.
  2539. Date: 01 Mar 1999 17:52:33 -0500 (EST)
  2540.  
  2541. Dan Hollis was heard to say:
  2542. >Actually the person I would most like to sue is the idiot engineer who
  2543. >dreamed up the plague that is now 'analogue 56k'. If that wasnt a
  2544. >hyper-extended promise then I dont know what is. 56k is the single biggest
  2545. >headache in ISP history. Ever. Period.
  2546.  
  2547. (It's engineer_s_.)  Heh, the theory is sound!  And it works perfectly in
  2548. the lab -- and in the field if you break a few laws in the US.
  2549.  
  2550. >Actually you can include all the marketing teams who trumpeted 56k like
  2551. >the second coming.
  2552.  
  2553. I just adds something to it, tho' doesn't it.
  2554.  
  2555. --Ricky
  2556.  
  2557.  
  2558. -
  2559.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2560.  with "unsubscribe usr-tc" in the body of the message.
  2561.  For information on digests or retrieving files and old messages send
  2562.  "help" to the same address.  Do not use quotes in your message.
  2563.  
  2564.  
  2565. -------------------------------------------------------------------------------
  2566.  
  2567. From: Allen Marsalis <am@shreve.net>
  2568. Subject: Re: (usr-tc) 3Com Problems.
  2569. Date: 01 Mar 1999 17:04:04 -0600
  2570.  
  2571. At 01:53 PM 3/1/99 -0800, Dan Hollis wrote:
  2572. >On Mon, 1 Mar 1999, Richard Stuplich wrote:
  2573. >> The analogy isn't relevant.  To 'stick' us with the USR/3COM crap and say
  2574. >> "everyone EOLs products" is irresponsible.  I smell a class action law
  2575. suit.
  2576. >
  2577. >Ahh, the good old american pastime -- sue! Litigate! Doesnt it just give
  2578. >you warm fuzzies. Living up to the american stereotype.
  2579.  
  2580. really it's the most expensive and least productive solution IMHO..
  2581. especially
  2582. on the short term, where most of the damage is caused, and good help is needed
  2583. the most..  But it you want ultimate justice and don't care how long it takes
  2584. or how much it costs, then sue away...  it's just my ego and principles can't
  2585. afford that..  and my customers can't wait..
  2586.  
  2587. It also doesn't hurt to think smart and hussle a little..  I saw this coming
  2588. a year ago and dumps that crap fast..  and at a good price..  probably
  2589. couldn't
  2590. give away a netserver nowadays unless someone wanted it for the trade-up
  2591. program...  Now there is another idea for you Jeff!  Find another isp as
  2592. pissed
  2593. as you are and buy his netservers and trade up..  sell the resulting hdms if
  2594. you don't want/need them and you have a lifetime supply of arcs for (nearly)
  2595. free...  That's lots easier than sueing or even writing letters to 3com
  2596. management IMHO..
  2597.  
  2598. anyway, just trying to help..  I'd like for all TC users to be as happy as
  2599. we are..  (not that we are THAT happy mind you)..   :)
  2600.  
  2601.  
  2602. Allen
  2603.  
  2604.  
  2605.  
  2606. >
  2607. >-Dan
  2608. >
  2609. >
  2610. >-
  2611. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2612. > with "unsubscribe usr-tc" in the body of the message.
  2613. > For information on digests or retrieving files and old messages send
  2614. > "help" to the same address.  Do not use quotes in your message.
  2615. >
  2616. >
  2617.  
  2618. -
  2619.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2620.  with "unsubscribe usr-tc" in the body of the message.
  2621.  For information on digests or retrieving files and old messages send
  2622.  "help" to the same address.  Do not use quotes in your message.
  2623.  
  2624.  
  2625. -------------------------------------------------------------------------------
  2626.  
  2627. From: Dan Hollis <goemon@sasami.anime.net>
  2628. Subject: Re: (usr-tc) 3Com Problems.
  2629. Date: 01 Mar 1999 15:20:22 -0800 (PST)
  2630.  
  2631. On Mon, 1 Mar 1999, Ricky Beam wrote:
  2632. > Dan Hollis was heard to say:
  2633. > >Actually the person I would most like to sue is the idiot engineer who
  2634. > >dreamed up the plague that is now 'analogue 56k'. If that wasnt a
  2635. > >hyper-extended promise then I dont know what is. 56k is the single biggest
  2636. > >headache in ISP history. Ever. Period.
  2637. > (It's engineer_s_.)  Heh, the theory is sound!  And it works perfectly in
  2638. > the lab -- and in the field if you break a few laws in the US.
  2639.  
  2640. There is always a mastermind behind the scheme, no matter how one might
  2641. try to obscure and hide it behind layers of management. Even in committee,
  2642. someone is always the first to speak up with a proposal even if the rest
  2643. just go along with it.
  2644.  
  2645. I want to know who that person is. The single person responsible for
  2646. masterminding "analogue 56k". There is a person out there, somewhere.
  2647. Perhaps hiding (for good reason :-)
  2648.  
  2649. -Dan
  2650.  
  2651.  
  2652. -
  2653.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2654.  with "unsubscribe usr-tc" in the body of the message.
  2655.  For information on digests or retrieving files and old messages send
  2656.  "help" to the same address.  Do not use quotes in your message.
  2657.  
  2658.  
  2659. -------------------------------------------------------------------------------
  2660.  
  2661. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  2662. Subject: Re: (usr-tc) connecting to hdm console or quad/dsp for outbound
  2663. Date: 01 Mar 1999 19:26:20 -0600 (CST)
  2664.  
  2665.  
  2666. > Mike Andrews <mandrews@termfrost.org> writes:
  2667. > 
  2668. > > On Sun, 28 Feb 1999, Mike Andrews wrote:
  2669. > > 
  2670. > > > Great, just what I needed.  Now why would a Quad modem get a DSP Interrupt
  2671. > > > Timeout when trying to answer a call...
  2672. > (...)
  2673. > > ATI6, under "failure to connect reason".  I think I get a DTE Ring No
  2674. > > Answer snmp trap around the same time -- I'm not sure because I changed
  2675. > > that Dual PRI card to fixed assignment and routed calls around the dud
  2676. > > modem.  I put it back online today though so we'll see if it's cleared
  2677. > > itself or not.
  2678. > 
  2679. > An occasional DSP interrupt timeout can just be a software problem,
  2680. > potentially if the code got into a bad state - for which a slot reset
  2681. > (not just a modem reset) should clean things up.
  2682. > 
  2683.  
  2684. I agree. 
  2685.  
  2686. > However, it could also be an indication of a failing DSP chip
  2687. > (failing to generate a programmed interrupt), in which case it will
  2688. > probably be the failure cause for the majority of calls handled by
  2689. > that modem, and you'll want to replace the hardware.
  2690. > 
  2691. One of the indications that you can see is if this particular port has 
  2692. any failures on the hiper arc side.  If you see the interface is down 
  2693. then that would be a indication
  2694.  
  2695. krish
  2696.  
  2697.  
  2698.  
  2699. > -- David
  2700. > 
  2701. > /-----------------------------------------------------------------------\
  2702. >  \               David Bolen              \  Internet: db3l@ans.net    /
  2703. >   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  2704. >  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  2705. > \-----------------------------------------------------------------------/
  2706. > 
  2707.  
  2708. -
  2709.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2710.  with "unsubscribe usr-tc" in the body of the message.
  2711.  For information on digests or retrieving files and old messages send
  2712.  "help" to the same address.  Do not use quotes in your message.
  2713.  
  2714.  
  2715. -------------------------------------------------------------------------------
  2716.  
  2717. From: jeff.binkley@asacomp.com (Jeff Binkley)
  2718. Subject: RE: (usr-tc) geo-book con
  2719. Date: 01 Mar 1999 19:52:00 -0500
  2720.  
  2721.  
  2722.  
  2723.  
  2724. Wayne,
  2725.  
  2726. This is a different problem.  I'd see if krish will work with you on a 
  2727. debug trace.  I am going to work with him on the webramp problem 
  2728. tomorrow.  When did this start ?  Was she working before or new ?
  2729.  
  2730. Jeff Binkley
  2731. ASA Network Computing
  2732.  
  2733.  
  2734. u>Jeff,
  2735.  
  2736. u>Do you have any other advice for connecting GeoBook users? I just
  2737. u>changed to 4.1.59-5 of the HiperARC software, but my one GeoBook owner
  2738. u>still cannot stay connected. She gets connected and my radius software
  2739. u>claims she authenticates successfully, but she then gets dropped right
  2740. u>away.  The latest attempt saw seven successful authentications in a
  2741. u>row for the same call. She still didn't stay connected.
  2742.  
  2743. u>I am running a mix of 12 quads (5.9.9) and 1 DSP (1.2.60).
  2744.  
  2745. u>Thanks,
  2746. u>Wayne Barber
  2747. u>Coastal Telco Services
  2748.  
  2749. u>> -----Original Message-----
  2750. u>> From: owner-usr-tc@lists.xmission.com
  2751. u>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
  2752. u>> Sent: Thursday, February 25, 1999 10:59 PM
  2753. u>> To: usr-tc@lists.xmission.com
  2754. u>> Subject: (usr-tc) geo-book connect
  2755. u>>
  2756. u>>
  2757. u>> -> Greetings,
  2758. u>> ->   I am having trouble connecting a client who is using a
  2759. u>> Brother Geo-Book.
  2760. u>> -> I'm using a TC chassis with HiPer ARC and DSP. No trouble with
  2761. u>> Anyone before
  2762. u>> -> this. The Brother folks say I need to assign IP and mask and
  2763. u>> gateway but I
  2764. u>> -> work with a pool.
  2765. u>> ->   Anyone have a suggestion?
  2766. u>>
  2767. u>> Talk to Krish.  he and I worked on this and you must have 4.1.64
  2768. u>> of HiPerArc
  2769. u>> code or higher.
  2770. u>>
  2771. u>> Jeff Binkley
  2772. u>> ASA Network Computing
  2773. u>>
  2774. u>> -
  2775. u>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2776. u>>  with "unsubscribe usr-tc" in the body of the message.
  2777. u>>  For information on digests or retrieving files and old messages
  2778. u>>  send "help" to the same address.  Do not use quotes in your
  2779. u>message. >
  2780.  
  2781.  
  2782. u>-
  2783. u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2784. u> with "unsubscribe usr-tc" in the body of the message.
  2785. u> For information on digests or retrieving files and old messages send
  2786. u> "help" to the same address.  Do not use quotes in your message.
  2787.  
  2788. u>                                                            
  2789.  
  2790. CMPQwk 1.42-21 9999
  2791.  
  2792.  
  2793. -
  2794.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2795.  with "unsubscribe usr-tc" in the body of the message.
  2796.  For information on digests or retrieving files and old messages send
  2797.  "help" to the same address.  Do not use quotes in your message.
  2798.  
  2799.  
  2800. -------------------------------------------------------------------------------
  2801.  
  2802. From: Mike Andrews <mandrews@termfrost.org>
  2803. Subject: Re: (usr-tc) 3Com Problems.
  2804. Date: 01 Mar 1999 20:16:44 -0500 (EST)
  2805.  
  2806. On Mon, 1 Mar 1999, Dan Hollis wrote:
  2807.  
  2808. > On Mon, 1 Mar 1999, Ricky Beam wrote:
  2809. > > Dan Hollis was heard to say:
  2810. > > >Actually the person I would most like to sue is the idiot engineer who
  2811. > > >dreamed up the plague that is now 'analogue 56k'. If that wasnt a
  2812. > > >hyper-extended promise then I dont know what is. 56k is the single biggest
  2813. > > >headache in ISP history. Ever. Period.
  2814. > > (It's engineer_s_.)  Heh, the theory is sound!  And it works perfectly in
  2815. > > the lab -- and in the field if you break a few laws in the US.
  2816. > 
  2817. > There is always a mastermind behind the scheme, no matter how one might
  2818. > try to obscure and hide it behind layers of management. Even in committee,
  2819. > someone is always the first to speak up with a proposal even if the rest
  2820. > just go along with it.
  2821. > 
  2822. > I want to know who that person is. The single person responsible for
  2823. > masterminding "analogue 56k". There is a person out there, somewhere.
  2824. > Perhaps hiding (for good reason :-)
  2825.  
  2826. "Brent Townshend" is the name you're looking for.
  2827.  
  2828.  
  2829. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  2830. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  2831. getting beaten by the police, put down the video camera and come help me!"
  2832.  
  2833.  
  2834. -
  2835.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2836.  with "unsubscribe usr-tc" in the body of the message.
  2837.  For information on digests or retrieving files and old messages send
  2838.  "help" to the same address.  Do not use quotes in your message.
  2839.  
  2840.  
  2841. -------------------------------------------------------------------------------
  2842.  
  2843. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  2844. Subject: (usr-tc) Caveat Emptor
  2845. Date: 01 Mar 1999 20:56:15 -0500 (EST)
  2846.  
  2847.  
  2848. So I was looking for some weed one day and I inquired as to what was
  2849. available to my favorite drug dealer. He said he had some and it was
  2850. really really top-notch stuff.
  2851.  
  2852. Then I asked around and found out a much more interesting story. It
  2853. seems that the weed he had wasn't really that good. And the reason
  2854. for that was that he was developing his own super-weed...the stuff
  2855. he had at the moment was just some crap he bought down in the projects.
  2856. The idea was to sell that stuff to meet the demand while he worked
  2857. on his own stuff.
  2858.  
  2859. I didn't buy any, but a lot of my friends did. I figured that I'd just
  2860. wait for the super-weed...and if I couldn't wait, well, I could always
  2861. go down to the projects myself and grab some from the source.
  2862.  
  2863. And wait I did, and my dealer came out with the super-weed.
  2864.  
  2865. It had some serious drawbacks. First, it is a little harsh for the
  2866. uninitiated; only an experienced smoker has any real hope of realizing
  2867. the full potential of the high. Second, my dealer also wants me to
  2868. pay a significant percentage of the price every year so I can occasionally
  2869. call and get him to help me smoke it...I still don't know what that's
  2870. all about. And third, I also have to realize that with this new
  2871. super-weed, I'm suddenly not his target market anymore. He's got mob
  2872. families who are getting really interested and hungry for this stuff.
  2873. Even if I bought a few hundred pounds of his stuff, I'd still not be
  2874. a drop in the bucket compared to the new potential revenue stream...
  2875. and the new target market doesn't bellyache about the yearly "support"
  2876. extortion either, they've been around and are used to that as a form
  2877. of business and don't mind paying it...indeed, they expect to pay it.
  2878. So I do realize that my dealer doesn't care about me anymore.
  2879.  
  2880. But it's SUPER-WEED. It KICKS ASS. With some of it, I could have a
  2881. competitive edge over the other guy in town.
  2882.  
  2883. Given that I can handle the harshness, and the 'help you smoke it'
  2884. extortion can be reasonably worked around by doing a couple of things
  2885. differently, I chose to go with the super-weed. And I'm lovin' it.
  2886.  
  2887. The only problem I have is that now, whenever I go to a party, everyone
  2888. is grumping and bellyaching about how our dealer "forgot" about us,
  2889. the people he knew on the street. The ones who foolishly bought the
  2890. crap he was selling while he was developing his super-weed are even
  2891. whining about how he should give them some super-weed for free. (what
  2892. have *they* been smoking???)
  2893.  
  2894. While I can identify with the problem, and I don't apologize for the
  2895. dealer...I do indeed think the way he's acting of late sucks pretty
  2896. badly...I also understand that business is business, and I'm only
  2897. responsible for my own. If I had bought the crap, I'd accept the fact
  2898. that *I* screwed up. Putting the blame on the dealer is a cop-out.
  2899. *Anyone* who had properly researched their purchase would have been
  2900. able to see what was going to happen in the relatively near future;
  2901. complaining about it now amounts to little more than outright whining.
  2902. Yeah, yeah, I know that back then, the dealer said that the crappy weed
  2903. was the greatest stuff since the discovery of the mushroom, but one
  2904. would have to be a total fool to believe everything a dealer says
  2905. without checking it out...
  2906.  
  2907. ...wouldn't they?
  2908.  
  2909.  
  2910. [NOTE TO THE HUMOR-IMPAIRED: The above message is satire, and was
  2911. written with the intention of making my point in the ongoing discussion
  2912. by using humorous analogy. If you don't find it humorous, please
  2913. accept my apology. It was, however, officially deemed to be at least
  2914. slightly humorous in the opinion of several test subjects. Your mileage
  2915. may vary. Whatever you feel, be certain to realize that I'm not
  2916. condoning the smoking of illegal drugs, neither am I a consumer of
  2917. them (the price/performace on em didn't look good after I got out
  2918. of college and had to pay for things with my own money).]
  2919.  
  2920. [NOTE TO THE NITPICKER-ENHANCED: Yes, I realize that referring to
  2921. a certain venerable system from another dealer as 'crap from the
  2922. projects' is stretching the analogy....we all know it's not that
  2923. bad. But it fit, okay?]
  2924.  
  2925. [NOTE TO PEOPLE LIKE MYSELF WHO WISH THIS LIST WAS MORE TECH TALK
  2926. ABOUT TC SYSTEMS AND LESS POLITICAL BITCHING: Y'know, I was thinking
  2927. that you could rig another telephone number to point to the head
  2928. of your hunt group. Then, you could rig your HDSP modem to configure
  2929. itself differently based on the called number. Easy enough so far,
  2930. right? The twist is that one of the configurations is an extremely
  2931. optimized configuration, so that people with the newest code and
  2932. the fancy modems can feel the power. The other config is one that
  2933. has all the fancy stuff off...like the compression that freaks out
  2934. all the winmodems and the like...a work-with-anything config. Then
  2935. you just put it in your setup info....'if you have trouble accessing
  2936. with the first number, try with the second yaddayadda'. I haven't
  2937. tried this yet, but it is apparently simple enough on the surface.
  2938. WDYT?]
  2939.  
  2940. Lon Stockton
  2941. MoonStar
  2942.  
  2943.  
  2944.  
  2945. -
  2946.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  2947.  with "unsubscribe usr-tc" in the body of the message.
  2948.  For information on digests or retrieving files and old messages send
  2949.  "help" to the same address.  Do not use quotes in your message.
  2950.  
  2951.  
  2952. -------------------------------------------------------------------------------
  2953.  
  2954. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  2955. Subject: RE: (usr-tc) geo-book con
  2956. Date: 01 Mar 1999 20:33:16 -0600 (CST)
  2957.  
  2958. On Mon, 1 Mar 1999, Jeff Binkley wrote:
  2959.  
  2960. > 
  2961. > 
  2962. > 
  2963. > Wayne,
  2964. > 
  2965. > This is a different problem.  I'd see if krish will work with you on a 
  2966. > debug trace.  I am going to work with him on the webramp problem 
  2967. > tomorrow.  When did this start ?  Was she working before or new ?
  2968.  
  2969. This could be a chap/pap problem  on the geo.  Take a mon ppp and end it 
  2970. to me.
  2971.  
  2972. krish
  2973.  
  2974.  
  2975. > 
  2976. > Jeff Binkley
  2977. > ASA Network Computing
  2978. > 
  2979. > 
  2980. > u>Jeff,
  2981. > 
  2982. > u>Do you have any other advice for connecting GeoBook users? I just
  2983. > u>changed to 4.1.59-5 of the HiperARC software, but my one GeoBook owner
  2984. > u>still cannot stay connected. She gets connected and my radius software
  2985. > u>claims she authenticates successfully, but she then gets dropped right
  2986. > u>away.  The latest attempt saw seven successful authentications in a
  2987. > u>row for the same call. She still didn't stay connected.
  2988. > 
  2989. > u>I am running a mix of 12 quads (5.9.9) and 1 DSP (1.2.60).
  2990. > 
  2991. > u>Thanks,
  2992. > u>Wayne Barber
  2993. > u>Coastal Telco Services
  2994. > 
  2995. > u>> -----Original Message-----
  2996. > u>> From: owner-usr-tc@lists.xmission.com
  2997. > u>> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jeff Binkley
  2998. > u>> Sent: Thursday, February 25, 1999 10:59 PM
  2999. > u>> To: usr-tc@lists.xmission.com
  3000. > u>> Subject: (usr-tc) geo-book connect
  3001. > u>>
  3002. > u>>
  3003. > u>> -> Greetings,
  3004. > u>> ->   I am having trouble connecting a client who is using a
  3005. > u>> Brother Geo-Book.
  3006. > u>> -> I'm using a TC chassis with HiPer ARC and DSP. No trouble with
  3007. > u>> Anyone before
  3008. > u>> -> this. The Brother folks say I need to assign IP and mask and
  3009. > u>> gateway but I
  3010. > u>> -> work with a pool.
  3011. > u>> ->   Anyone have a suggestion?
  3012. > u>>
  3013. > u>> Talk to Krish.  he and I worked on this and you must have 4.1.64
  3014. > u>> of HiPerArc
  3015. > u>> code or higher.
  3016. > u>>
  3017. > u>> Jeff Binkley
  3018. > u>> ASA Network Computing
  3019. > u>>
  3020. > u>> -
  3021. > u>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3022. > u>>  with "unsubscribe usr-tc" in the body of the message.
  3023. > u>>  For information on digests or retrieving files and old messages
  3024. > u>>  send "help" to the same address.  Do not use quotes in your
  3025. > u>message. >
  3026. > 
  3027. > 
  3028. > u>-
  3029. > u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3030. > u> with "unsubscribe usr-tc" in the body of the message.
  3031. > u> For information on digests or retrieving files and old messages send
  3032. > u> "help" to the same address.  Do not use quotes in your message.
  3033. > 
  3034. > u>                                                            
  3035. > 
  3036. > CMPQwk 1.42-21 9999
  3037. > 
  3038. > 
  3039. > -
  3040. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3041. >  with "unsubscribe usr-tc" in the body of the message.
  3042. >  For information on digests or retrieving files and old messages send
  3043. >  "help" to the same address.  Do not use quotes in your message.
  3044. > 
  3045.  
  3046. -
  3047.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3048.  with "unsubscribe usr-tc" in the body of the message.
  3049.  For information on digests or retrieving files and old messages send
  3050.  "help" to the same address.  Do not use quotes in your message.
  3051.  
  3052.  
  3053. -------------------------------------------------------------------------------
  3054.  
  3055. From: Jeff Mcadams <jeffm@iglou.com>
  3056. Subject: Re: (usr-tc) Caveat Emptor
  3057. Date: 02 Mar 1999 08:05:59 -0500 (EST)
  3058.  
  3059. Thus spake Lon R. Stockton, Jr.
  3060. >So I was looking for some weed one day and I inquired as to what was
  3061. >available to my favorite drug dealer. He said he had some and it was
  3062. >really really top-notch stuff.
  3063.  
  3064. [snip]
  3065.  
  3066. >But it's SUPER-WEED. It KICKS ASS. With some of it, I could have a
  3067. >competitive edge over the other guy in town.
  3068.  
  3069. Here's the problem with your analogy.  I don't *need*, the "super-weed."
  3070. The crappy weed from the projects should get me all the high I need and
  3071. want, and paid for!
  3072.  
  3073. So, to extend your analogy here.  I paid for a high that 10 pounds of
  3074. weed from the projects should give me.  I'm not getting that high, so I
  3075. went back to the dealer to fix it.  He said he can't do anything with
  3076. that weed anymore (his dealer in the projects got busted), but if I pay
  3077. him even more money to get some of the super-weed, I should be able to
  3078. get the high that the 10 pounds of weed from the projects should have
  3079. given me in the first place and that I already paid for!
  3080.  
  3081. >The only problem I have is that now, whenever I go to a party, everyone
  3082. >is grumping and bellyaching about how our dealer "forgot" about us,
  3083. >the people he knew on the street. The ones who foolishly bought the
  3084. >crap he was selling while he was developing his super-weed are even
  3085. >whining about how he should give them some super-weed for free. (what
  3086. >have *they* been smoking???)
  3087.  
  3088. The dealer can either come up with a way that I can get the high that I
  3089. already paid for from the weed he already sold me, or he can give me
  3090. some of the super-weed to make up for the deficiencies of the weed from
  3091. the projects.  That's even accounting that the weed came from the
  3092. projects and that its going to not be as good weed as the super-weed
  3093. anyway, but the weed from the projects didn't even live up to what it
  3094. was supposed to do as weed from the projects!
  3095.  
  3096. [snip]
  3097.  
  3098. >If I had bought the crap, I'd accept the fact
  3099. >that *I* screwed up. 
  3100.  
  3101. Whoa...and this is the crux of where you're bad analogy comes from.  The
  3102. customer didn't screw up here.  The dealer most definitely did!  The
  3103. weed is definitely defective, even for weed from the projects.  The
  3104. dealer's handling of the situation was appalling, and all I want is the
  3105. high that I originally paid for and *still* haven't gotten and the
  3106. dealer still seems to be making excuses for.
  3107.  
  3108. >Putting the blame on the dealer is a cop-out.
  3109.  
  3110. Wrong...the dealer screwed up big time.  Again, all I want is the
  3111. functionality I paid for, nothing more.  I don't *need* an upgrade to
  3112. HiPer Arcs, the NETServers as a hardware product work just fine, its the
  3113. software that's broken and its the software that I really want fixed.
  3114. If 3Com doesn't want to give me some of the "super-weed", then they can
  3115. give me a software fix...oh, but they screwed that up too.
  3116.  
  3117. Again, *I JUST WANT THE FUNCTIONALITY THAT I'VE ALREADY PAID FOR!*  I
  3118. DON'T NEED AN UPGRADE!
  3119.  
  3120. >*Anyone* who had properly researched their purchase would have been
  3121. >able to see what was going to happen in the relatively near future;
  3122.  
  3123. First off...we've been purchasing NETServers for 2 to 3 years
  3124. now...before the HiPer equipment was ever a glimmer in 3Com's eye, so
  3125. that argument falls flat on its face.  Second, the HiPer Arc did not do
  3126. what we needed until version 4.1.59-2, so purchasing HiPer Arcs instead
  3127. was not an option, even when they were available.
  3128.  
  3129. >complaining about it now amounts to little more than outright whining.
  3130.  
  3131. No, complaining about it now is an attempt to get 3Com to do the right
  3132. thing, since they seem really hesitant to ever do that.
  3133.  
  3134. >If you don't find it humorous, please accept my apology.
  3135.  
  3136. I did find it rather humorous...though horribly flawed as an analogy.
  3137.  
  3138. >[NOTE TO PEOPLE LIKE MYSELF WHO WISH THIS LIST WAS MORE TECH TALK
  3139. >ABOUT TC SYSTEMS AND LESS POLITICAL BITCHING: Y'know, I was thinking
  3140. >that you could rig another telephone number to point to the head
  3141. >of your hunt group. Then, you could rig your HDSP modem to configure
  3142. >itself differently based on the called number. Easy enough so far,
  3143. >right? The twist is that one of the configurations is an extremely
  3144. >optimized configuration, so that people with the newest code and
  3145. >the fancy modems can feel the power. The other config is one that
  3146. >has all the fancy stuff off...like the compression that freaks out
  3147. >all the winmodems and the like...a work-with-anything config. Then
  3148. >you just put it in your setup info....'if you have trouble accessing
  3149. >with the first number, try with the second yaddayadda'. I haven't
  3150. >tried this yet, but it is apparently simple enough on the surface.
  3151. >WDYT?]
  3152.  
  3153. Hrmm...interesting thought...I know the Arc can "authenticate" based on
  3154. DNIS, so it could change the behavior of the port that way, though that
  3155. doesn't take care of modem connect problems because the modems have
  3156. already connected, or failed to connect by the time the Arc sees the
  3157. DNIS I believe.  I'm unaware of any way to have the modem on the DSP
  3158. reconfigure on the fly based on DNIS at this point, though I'm not
  3159. extremely knowledgeable about them yet.  That would be pretty cool to
  3160. do, but I think it would require some changes in the DSP's to do it (I
  3161. would be happy to learn that I'm wrong).
  3162. -- 
  3163. Jeff McAdams                            Email: jeffm@iglou.com
  3164. Head Network Administrator              Voice: (502) 966-3848
  3165. IgLou Internet Services                        (800) 436-4456
  3166.  
  3167. -
  3168.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3169.  with "unsubscribe usr-tc" in the body of the message.
  3170.  For information on digests or retrieving files and old messages send
  3171.  "help" to the same address.  Do not use quotes in your message.
  3172.  
  3173.  
  3174. -------------------------------------------------------------------------------
  3175.  
  3176. From: Brian <signal@shreve.net>
  3177. Subject: Re: (usr-tc) Caveat Emptor
  3178. Date: 02 Mar 1999 07:49:13 -0600 (CST)
  3179.  
  3180. On Tue, 2 Mar 1999, Jeff Mcadams wrote:
  3181.  
  3182. > Thus spake Lon R. Stockton, Jr.
  3183. > >So I was looking for some weed one day and I inquired as to what was
  3184. > >available to my favorite drug dealer. He said he had some and it was
  3185. > >really really top-notch stuff.
  3186. > 
  3187. > [snip]
  3188. > 
  3189. > >But it's SUPER-WEED. It KICKS ASS. With some of it, I could have a
  3190. > >competitive edge over the other guy in town.
  3191. > 
  3192. > Here's the problem with your analogy.  I don't *need*, the "super-weed."
  3193. > The crappy weed from the projects should get me all the high I need and
  3194. > want, and paid for!
  3195.  
  3196.  
  3197. Look, I think you are all missing the real issue, which is, when working
  3198. on 3Com/USR Total Control chassis, *any* kind of drugs are good to have.
  3199. > -- 
  3200. > Jeff McAdams                            Email: jeffm@iglou.com
  3201. > Head Network Administrator              Voice: (502) 966-3848
  3202. > IgLou Internet Services                        (800) 436-4456
  3203. > 
  3204. > -
  3205. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3206. >  with "unsubscribe usr-tc" in the body of the message.
  3207. >  For information on digests or retrieving files and old messages send
  3208. >  "help" to the same address.  Do not use quotes in your message.
  3209. > 
  3210.  
  3211. Brian Feeny (BF304)     signal@shreve.net   
  3212. 318-222-2638 x 109    http://www.shreve.net/~signal      
  3213. Network Administrator   ShreveNet Inc. (ASN 11881)           
  3214.  
  3215.  
  3216. -
  3217.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3218.  with "unsubscribe usr-tc" in the body of the message.
  3219.  For information on digests or retrieving files and old messages send
  3220.  "help" to the same address.  Do not use quotes in your message.
  3221.  
  3222.  
  3223. -------------------------------------------------------------------------------
  3224.  
  3225. From: "Behrens, William" <WBehrens@Paracom.com>
  3226. Subject: RE: (usr-tc) Caveat Emptor
  3227. Date: 02 Mar 1999 08:32:01 -0600 
  3228.  
  3229. This is good stuff gentlemen.....
  3230.  
  3231.  
  3232. >Thus spake Lon R. Stockton, Jr.
  3233. >So I was looking for some weed one day and I inquired as to what was
  3234. >available to my favorite drug dealer. He said he had some and it was
  3235. >really really top-notch stuff.
  3236.  
  3237. >[snip]
  3238.  
  3239. >But it's SUPER-WEED. It KICKS ASS. With some of it, I could have a
  3240. >competitive edge over the other guy in town.
  3241.  
  3242. >Here's the problem with your analogy.  I don't *need*, the "super-weed."
  3243. >The crappy weed from the projects should get me all the high I need and
  3244. >want, and paid for!
  3245.  
  3246. >So, to extend your analogy here.  I paid for a high that 10 pounds of
  3247. >weed from the projects should give me.  I'm not getting that high, so I
  3248. >went back to the dealer to fix it.  He said he can't do anything with
  3249. >that weed anymore (his dealer in the projects got busted), but if I pay
  3250.  
  3251.  
  3252. {SUPER-SNIP}
  3253.  
  3254. Well If I got "lame" weed that was passed off as "SUPER" weed from a dealer
  3255. I would:
  3256.  
  3257. 1. Rip the dealer off for the amount he cost me or hold him at gun point for
  3258. my money back then...Shoot the dealer or NARC on him
  3259. 2. Find a new dealer (as the first one is in jail or dead)
  3260.  
  3261. I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting note
  3262. Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com
  3263. support the netserver?
  3264.  
  3265. William Behrens
  3266.  
  3267. -
  3268.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3269.  with "unsubscribe usr-tc" in the body of the message.
  3270.  For information on digests or retrieving files and old messages send
  3271.  "help" to the same address.  Do not use quotes in your message.
  3272.  
  3273.  
  3274. -------------------------------------------------------------------------------
  3275.  
  3276. From: "Wayne Barber" <barberw@tidewater.net>
  3277. Subject: RE: (usr-tc) geo-book con
  3278. Date: 02 Mar 1999 09:39:48 -0500
  3279.  
  3280. I just worked with her again and it turns out she had the wrong settings for
  3281. the mail server. Once we fixed that, she appears to be working fine.
  3282.  
  3283. Thanks for the help Krish and Jeff.
  3284.  
  3285. I still haven't seen the GeoBook, other than on the web page, but I did talk
  3286. with a techsupport person at Brother and the GeoBook is just a DOS machine
  3287. with text-only web browsing. I wonder if it's just Minuet?
  3288.  
  3289. Wayne Barber
  3290. Coastal Telco Services
  3291.  
  3292.  
  3293. -
  3294.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3295.  with "unsubscribe usr-tc" in the body of the message.
  3296.  For information on digests or retrieving files and old messages send
  3297.  "help" to the same address.  Do not use quotes in your message.
  3298.  
  3299.  
  3300. -------------------------------------------------------------------------------
  3301.  
  3302. From: "Ronald E. Kushner" <ron@glis.net>
  3303. Subject: Re: (usr-tc) Caveat Emptor
  3304. Date: 02 Mar 1999 09:53:09 -0500
  3305.  
  3306.  
  3307.  
  3308. "Behrens, William" wrote:
  3309.  
  3310. > 
  3311. > I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting note
  3312. > Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com
  3313. > support the netserver?
  3314.  
  3315. >From what I've read, 3Com does not have access to the code that runs on the
  3316. netserver anylonger.  Why this is, I have not seen posted other than the
  3317. license ran out. Were they told it would cost some unrealistic number to
  3318. relicense it, or are they just being cheap because now they have their own
  3319. code?
  3320.  
  3321. Bitching and moaning will not help if the owners of the code are unwilling
  3322. to relicense it. What's the real story?
  3323.  
  3324. -Ron
  3325. GLISnet, Inc
  3326. +1 810/939.9885
  3327.  
  3328. -
  3329.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3330.  with "unsubscribe usr-tc" in the body of the message.
  3331.  For information on digests or retrieving files and old messages send
  3332.  "help" to the same address.  Do not use quotes in your message.
  3333.  
  3334.  
  3335. -------------------------------------------------------------------------------
  3336.  
  3337. From: Charles Sprickman <spork@inch.com>
  3338. Subject: Re: (usr-tc) Caveat Emptor
  3339. Date: 02 Mar 1999 10:52:16 -0500 (EST)
  3340.  
  3341.  
  3342. On Tue, 2 Mar 1999, Jeff Mcadams wrote:
  3343. > Thus spake Lon R. Stockton, Jr.
  3344. [snip]
  3345. > >If I had bought the crap, I'd accept the fact
  3346. > >that *I* screwed up. 
  3347. > 
  3348. > Whoa...and this is the crux of where you're bad analogy comes from.  The
  3349. > customer didn't screw up here.  The dealer most definitely did!  The
  3350. > weed is definitely defective, even for weed from the projects.  The
  3351. > dealer's handling of the situation was appalling, and all I want is the
  3352. > high that I originally paid for and *still* haven't gotten and the
  3353. > dealer still seems to be making excuses for.
  3354.  
  3355. Actually I think the analogy works...  What Lon is saying is that 3com
  3356. sales and marketing is about as honest and good-intentioned as your
  3357. average street dealer.  Street sense should tell you to go to Amsterdam 
  3358. and buy a nice PM4 or 5300 at the RAS bar there and stay away from the
  3359. twitching street corner 3Com reps.
  3360.  
  3361. And the 3Com drug of choice is most likely something dirty like inhaling
  3362. Glade air freshener, not weed.
  3363.  
  3364. I wonder when data over voice will appear in the US market?  Around the
  3365. same time as OSPF?
  3366.  
  3367. Charles
  3368.  
  3369.  
  3370. -
  3371.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3372.  with "unsubscribe usr-tc" in the body of the message.
  3373.  For information on digests or retrieving files and old messages send
  3374.  "help" to the same address.  Do not use quotes in your message.
  3375.  
  3376.  
  3377. -------------------------------------------------------------------------------
  3378.  
  3379. From: Jeff Mcadams <jeffm@iglou.com>
  3380. Subject: Re: (usr-tc) Caveat Emptor
  3381. Date: 02 Mar 1999 11:07:03 -0500 (EST)
  3382.  
  3383. Thus spake Charles Sprickman
  3384. >On Tue, 2 Mar 1999, Jeff Mcadams wrote:
  3385. >> Thus spake Lon R. Stockton, Jr.
  3386. >[snip]
  3387. >> >If I had bought the crap, I'd accept the fact
  3388. >> >that *I* screwed up. 
  3389.  
  3390. >> Whoa...and this is the crux of where you're bad analogy comes from.  The
  3391. >> customer didn't screw up here.  The dealer most definitely did!  The
  3392. >> weed is definitely defective, even for weed from the projects.  The
  3393. >> dealer's handling of the situation was appalling, and all I want is the
  3394. >> high that I originally paid for and *still* haven't gotten and the
  3395. >> dealer still seems to be making excuses for.
  3396.  
  3397. >Actually I think the analogy works...  What Lon is saying is that 3com
  3398. >sales and marketing is about as honest and good-intentioned as your
  3399. >average street dealer.  
  3400.  
  3401. Marketing maybe...not sales...at least not my sales rep.  I think its
  3402. the higher ups that make decisions such as what is being discussed that
  3403. is the problem, not the lower folks that actually go out and talk to the
  3404. customers.
  3405.  
  3406. >I wonder when data over voice will appear in the US market?  Around the
  3407. >same time as OSPF?
  3408.  
  3409. That would be nice actually since OSPF is nearly here (no joking there)
  3410. -- 
  3411. Jeff McAdams                            Email: jeffm@iglou.com
  3412. Head Network Administrator              Voice: (502) 966-3848
  3413. IgLou Internet Services                        (800) 436-4456
  3414.  
  3415. -
  3416.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3417.  with "unsubscribe usr-tc" in the body of the message.
  3418.  For information on digests or retrieving files and old messages send
  3419.  "help" to the same address.  Do not use quotes in your message.
  3420.  
  3421.  
  3422. -------------------------------------------------------------------------------
  3423.  
  3424. From: "Behrens, William" <WBehrens@Paracom.com>
  3425. Subject: RE: (usr-tc) Caveat Emptor
  3426. Date: 02 Mar 1999 10:30:06 -0600 
  3427.  
  3428.     
  3429.     Yes the Netserver code was licensed from Livingston (lucent). 3com's
  3430. position is the hardware in the netserver class NAS is legacy due to the
  3431. release of the HARC class NAS. Therefore they will no longer support the NAS
  3432. (in general) due to the inability to support the software and the release of
  3433. the new HARC. Features that do not work as advertised will not be fixed. The
  3434. standard reply is if you want "x" feature to work correctly then buy a HARC.
  3435. That's basically a load of shit. 
  3436.  
  3437.     Supporting a particular platform for its lifespan is a cost of doing
  3438. business. If they (3com) had not been selling netserver class NAS's for a
  3439. couple of years I could maybe see the support drying up, but they were
  3440. selling this box (thru distributors) up in till the end of this last year.
  3441. That's not the customers problem, again a cost of doing business. Fix the
  3442. distributor pipeline (i.e. don't fill it with product you know you won't
  3443. support).
  3444.  
  3445.     For the most part people are pissed off due to 3com's desire for its
  3446. customers to pay for its poor business practices and lack of foresight. If
  3447. you purchased an automobile with an engine that was manufactured by a 3rd
  3448. party and 3 months later the OEM said "sorry we don't support your
  3449. automobile anymore because the engine is old, but you can buy this NEW
  3450. automobile to fix your problem" would you be pissed ? You bet your ass you
  3451. would. You would get an attorney and have a heyday with the auto maker in
  3452. question. There is an implied warranty. If you can prove the manufacturer
  3453. was not doing business with you in good faith at the time of purchase then
  3454. he would be held accountable for his actions in a court of law.
  3455.  
  3456.     These people who are "whining and moaning" have a legetament gripe.
  3457. They feel they have been screwed. Buying a NAS is not like buying a computer
  3458. or OS as an earlier poster had suggested. PC's don't cost 10K+ (at least not
  3459. desktops). I am not whining as my Netserver's are working for me and I don't
  3460. need the support for some of the software features, but this act buy 3com of
  3461. not supporting there customers in a "good faith" manner has made me think of
  3462. "fork lifting" my NAS's back to Lucent and PM4's.
  3463.  
  3464. William Behrens
  3465.  
  3466. >"Behrens, William" wrote:
  3467.  
  3468.  
  3469. >> I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting note
  3470. >> Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com
  3471. >> support the netserver?
  3472.  
  3473. >From what I've read, 3Com does not have access to the code that runs on the
  3474. >netserver anylonger.  Why this is, I have not seen posted other than the
  3475. >license ran out. Were they told it would cost some unrealistic number to
  3476. >relicense it, or are they just being cheap because now they have their own
  3477. >code?
  3478.  
  3479. >Bitching and moaning will not help if the owners of the code are unwilling
  3480. >to relicense it. What's the real story?
  3481.  
  3482. >-Ron
  3483. >GLISnet, Inc
  3484. >+1 810/939.9885
  3485.  
  3486.  
  3487. -
  3488.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3489.  with "unsubscribe usr-tc" in the body of the message.
  3490.  For information on digests or retrieving files and old messages send
  3491.  "help" to the same address.  Do not use quotes in your message.
  3492.  
  3493.  
  3494. -------------------------------------------------------------------------------
  3495.  
  3496. From: matthew de Jongh <matthew.de.jongh@the-spa.com>
  3497. Subject: (usr-tc) platypus & tc port numbers
  3498. Date: 02 Mar 1999 11:47:38 -0500
  3499.  
  3500.  
  3501.  we are setting up platypus and i was looking for any info on the port
  3502. numbers to put for both
  3503.  the older netserver and hiper arc chassis's
  3504.  
  3505.  matthew
  3506.  
  3507.  
  3508. -
  3509.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3510.  with "unsubscribe usr-tc" in the body of the message.
  3511.  For information on digests or retrieving files and old messages send
  3512.  "help" to the same address.  Do not use quotes in your message.
  3513.  
  3514.  
  3515. -------------------------------------------------------------------------------
  3516.  
  3517. From: "Paul Jr. (AlaWeb Support)" <jr@alaweb.com>
  3518. Subject: Re: (usr-tc) Port Density
  3519. Date: 02 Mar 1999 10:54:49 -0600
  3520.  
  3521. Just wondering if everyone has heard about 3com's latest bundle.  You can
  3522. purchase the Double play bundle which is two DSP cards for 8,995.00 and also
  3523. trade in 48 Quads for 2 extra DSP's for no extra money.
  3524.  
  3525. The price above is from my vendor.
  3526.  
  3527. I just thought this was a attractive offer and thought I would share it with
  3528. everyone.
  3529.  
  3530. Thanks
  3531. Paul JR.
  3532.  
  3533.  
  3534.  Original Message -----
  3535. Sent: Tuesday, March 02, 1999 10:30 AM
  3536.  
  3537.  
  3538. >
  3539. > Yes the Netserver code was licensed from Livingston (lucent). 3com's
  3540. >position is the hardware in the netserver class NAS is legacy due to the
  3541. >release of the HARC class NAS. Therefore they will no longer support the
  3542. NAS
  3543. >(in general) due to the inability to support the software and the release
  3544. of
  3545. >the new HARC. Features that do not work as advertised will not be fixed.
  3546. The
  3547. >standard reply is if you want "x" feature to work correctly then buy a
  3548. HARC.
  3549. >That's basically a load of shit.
  3550. >
  3551. > Supporting a particular platform for its lifespan is a cost of doing
  3552. >business. If they (3com) had not been selling netserver class NAS's for a
  3553. >couple of years I could maybe see the support drying up, but they were
  3554. >selling this box (thru distributors) up in till the end of this last year.
  3555. >That's not the customers problem, again a cost of doing business. Fix the
  3556. >distributor pipeline (i.e. don't fill it with product you know you won't
  3557. >support).
  3558. >
  3559. > For the most part people are pissed off due to 3com's desire for its
  3560. >customers to pay for its poor business practices and lack of foresight. If
  3561. >you purchased an automobile with an engine that was manufactured by a 3rd
  3562. >party and 3 months later the OEM said "sorry we don't support your
  3563. >automobile anymore because the engine is old, but you can buy this NEW
  3564. >automobile to fix your problem" would you be pissed ? You bet your ass you
  3565. >would. You would get an attorney and have a heyday with the auto maker in
  3566. >question. There is an implied warranty. If you can prove the manufacturer
  3567. >was not doing business with you in good faith at the time of purchase then
  3568. >he would be held accountable for his actions in a court of law.
  3569. >
  3570. > These people who are "whining and moaning" have a legetament gripe.
  3571. >They feel they have been screwed. Buying a NAS is not like buying a
  3572. computer
  3573. >or OS as an earlier poster had suggested. PC's don't cost 10K+ (at least
  3574. not
  3575. >desktops). I am not whining as my Netserver's are working for me and I
  3576. don't
  3577. >need the support for some of the software features, but this act buy 3com
  3578. of
  3579. >not supporting there customers in a "good faith" manner has made me think
  3580. of
  3581. >"fork lifting" my NAS's back to Lucent and PM4's.
  3582. >
  3583. >William Behrens
  3584. >
  3585. >>"Behrens, William" wrote:
  3586. >
  3587. >
  3588. >>> I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting
  3589. note
  3590. >>> Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com
  3591. >>> support the netserver?
  3592. >
  3593. >>From what I've read, 3Com does not have access to the code that runs on
  3594. the
  3595. >>netserver anylonger.  Why this is, I have not seen posted other than the
  3596. >>license ran out. Were they told it would cost some unrealistic number to
  3597. >>relicense it, or are they just being cheap because now they have their own
  3598. >>code?
  3599. >
  3600. >>Bitching and moaning will not help if the owners of the code are unwilling
  3601. >>to relicense it. What's the real story?
  3602. >
  3603. >>-Ron
  3604. >>GLISnet, Inc
  3605. >>+1 810/939.9885
  3606. >
  3607. >
  3608. >-
  3609. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3610. > with "unsubscribe usr-tc" in the body of the message.
  3611. > For information on digests or retrieving files and old messages send
  3612. > "help" to the same address.  Do not use quotes in your message.
  3613. >
  3614.  
  3615.  
  3616.  
  3617.  
  3618. -
  3619.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3620.  with "unsubscribe usr-tc" in the body of the message.
  3621.  For information on digests or retrieving files and old messages send
  3622.  "help" to the same address.  Do not use quotes in your message.
  3623.  
  3624.  
  3625. -------------------------------------------------------------------------------
  3626.  
  3627. From: Jeff Mcadams <jeffm@iglou.com>
  3628. Subject: Re: (usr-tc) Port Density
  3629. Date: 02 Mar 1999 12:14:20 -0500 (EST)
  3630.  
  3631. Thus spake Paul Jr.
  3632. >Just wondering if everyone has heard about 3com's latest bundle.  You can
  3633. >purchase the Double play bundle which is two DSP cards for 8,995.00 and also
  3634. >trade in 48 Quads for 2 extra DSP's for no extra money.
  3635.  
  3636. >The price above is from my vendor.
  3637.  
  3638. Oh good...this is out now.  :)
  3639.  
  3640. This bundle was thought up in an effort to increase port densities
  3641. directly as a result of our situation.  The bundle was created in an
  3642. effort to increase port density and thus require the purchasing of fewer
  3643. HiPer Arcs to do the upgrade.
  3644.  
  3645. Someone apparently didn't do their math though because this isn't even
  3646. *close* to being cost effective to do this.
  3647.  
  3648. This bundle is good if 1) you have Arc's running 48 or 96 ports of
  3649. modems currently, then doing this would probably be cost effective by 
  3650. letting the Arc then run 144 ports thus giving you another 48 ports without
  3651. having to buy another Arc; of if 2) you're just trying to increase port
  3652. density for its own sake.
  3653.  
  3654. This bundle is definitely *not* cost effective for trying to do the
  3655. upgrade to HiPer Arcs from NETServers compared to just using the (now
  3656. discontinued) 1 Arc + 1 DSP in exchange for a NETServer bundle.
  3657.  
  3658. >I just thought this was a attractive offer and thought I would share it with
  3659. >everyone.
  3660.  
  3661. It is good if you're looking to increase the total number of ports you
  3662. have, definitely.
  3663. -- 
  3664. Jeff McAdams                            Email: jeffm@iglou.com
  3665. Head Network Administrator              Voice: (502) 966-3848
  3666. IgLou Internet Services                        (800) 436-4456
  3667.  
  3668. -
  3669.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3670.  with "unsubscribe usr-tc" in the body of the message.
  3671.  For information on digests or retrieving files and old messages send
  3672.  "help" to the same address.  Do not use quotes in your message.
  3673.  
  3674.  
  3675. -------------------------------------------------------------------------------
  3676.  
  3677. From: Steve Johnson <linuxnut@sonic.net>
  3678. Subject: (usr-tc) Mailing List Archive
  3679. Date: 02 Mar 1999 09:40:40 -0800 (PST)
  3680.  
  3681.  
  3682. Is there a mailing list archive for this list?
  3683.  
  3684.  
  3685. -Steve
  3686.  
  3687.  
  3688. ----
  3689.       "Knowing others is wisdom, knowing your self is Enlightenment."
  3690.                                                    -- Lao-Tzu
  3691.  
  3692.  
  3693.  
  3694.  
  3695. -
  3696.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3697.  with "unsubscribe usr-tc" in the body of the message.
  3698.  For information on digests or retrieving files and old messages send
  3699.  "help" to the same address.  Do not use quotes in your message.
  3700.  
  3701.  
  3702. -------------------------------------------------------------------------------
  3703.  
  3704. From: Bob Purdon <bobp@southcom.com.au>
  3705. Subject: Re: (usr-tc) Caveat Emptor
  3706. Date: 03 Mar 1999 07:31:28 +1100 (EST)
  3707.  
  3708.  
  3709. > From what I've read, 3Com does not have access to the code that runs
  3710. > on the netserver anylonger.  Why this is, I have not seen posted other
  3711. > than the license ran out. Were they told it would cost some
  3712. > unrealistic number to relicense it, or are they just being cheap
  3713. > because now they have their own code?
  3714.  
  3715. What's stopping them porting their new code to the NETserver - just like
  3716. Cisco build the 2501 IOS from the same code base (I believe) as the higher
  3717. end routers?
  3718.  
  3719. They can't be bothered?  They won't sell as many of their shiny new Arc's?
  3720. I dunno...
  3721.  
  3722. Regards,
  3723.  
  3724. Bob Purdon,
  3725. Technical Manager,
  3726. Southern Internet Services.
  3727.  
  3728.  
  3729. -
  3730.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3731.  with "unsubscribe usr-tc" in the body of the message.
  3732.  For information on digests or retrieving files and old messages send
  3733.  "help" to the same address.  Do not use quotes in your message.
  3734.  
  3735.  
  3736. -------------------------------------------------------------------------------
  3737.  
  3738. From: "Ronald E. Kushner" <ron@glis.net>
  3739. Subject: Re: (usr-tc) Caveat Emptor
  3740. Date: 02 Mar 1999 16:00:58 -0500
  3741.  
  3742.  
  3743.  
  3744. Bob Purdon wrote:
  3745. > 
  3746. > > From what I've read, 3Com does not have access to the code that runs
  3747. > > on the netserver anylonger.  Why this is, I have not seen posted other
  3748. > > than the license ran out. Were they told it would cost some
  3749. > > unrealistic number to relicense it, or are they just being cheap
  3750. > > because now they have their own code?
  3751. > 
  3752. > What's stopping them porting their new code to the NETserver - just like
  3753. > Cisco build the 2501 IOS from the same code base (I believe) as the higher
  3754. > end routers?
  3755. > 
  3756. > They can't be bothered?  They won't sell as many of their shiny new Arc's?
  3757. > I dunno...
  3758.  
  3759. Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486
  3760. DX2/66, there may be performance issues on running the HARC code on the
  3761. Netserver. 
  3762.  
  3763. How much RAM did the Netservers have, 8MB?  
  3764.  
  3765. Sometimes it's not easy to take something designed for one platform and move
  3766. it to another. Do you want to pay Cisco prices for 3Com equipment? There is
  3767. a reason why Cisco equipment in general costs 40% more than anyone elses. 
  3768.  
  3769. Do you commonly ask BMW to drop in a Volkswagen engine into your car because
  3770. you already have the engine or to fix a stalling problem?
  3771.  
  3772. -Ron
  3773. GLISnet, Inc.
  3774. +1 810/939.9885
  3775.  
  3776. -
  3777.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3778.  with "unsubscribe usr-tc" in the body of the message.
  3779.  For information on digests or retrieving files and old messages send
  3780.  "help" to the same address.  Do not use quotes in your message.
  3781.  
  3782.  
  3783. -------------------------------------------------------------------------------
  3784.  
  3785. From: Mike Andrews <mandrews@termfrost.org>
  3786. Subject: Re: (usr-tc) Caveat Emptor
  3787. Date: 02 Mar 1999 16:12:41 -0500 (EST)
  3788.  
  3789. On Tue, 2 Mar 1999, Ronald E. Kushner wrote:
  3790.  
  3791. > Bob Purdon wrote:
  3792. > > 
  3793. > > > From what I've read, 3Com does not have access to the code that runs
  3794. > > > on the netserver anylonger.  Why this is, I have not seen posted other
  3795. > > > than the license ran out. Were they told it would cost some
  3796. > > > unrealistic number to relicense it, or are they just being cheap
  3797. > > > because now they have their own code?
  3798. > > 
  3799. > > What's stopping them porting their new code to the NETserver - just like
  3800. > > Cisco build the 2501 IOS from the same code base (I believe) as the higher
  3801. > > end routers?
  3802. > > 
  3803. > > They can't be bothered?  They won't sell as many of their shiny new Arc's?
  3804. > > I dunno...
  3805. > 
  3806. > Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486
  3807. > DX2/66, there may be performance issues on running the HARC code on the
  3808. > Netserver. 
  3809.  
  3810. 486/100 I thought...  but still, that's the best argument I've heard so
  3811. far for not doing it.  However...  they HAVE ported it to the NETserver/8
  3812. and NETserver/16 line, and the USR Viper DSL.  All of those run on 486's.
  3813. They don't have to deal with a packet bus, however, or with more than 16
  3814. ports...  maybe it doesn't scale up to 96 ports well.
  3815.  
  3816.  
  3817. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  3818. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  3819. getting beaten by the police, put down the video camera and come help me!"
  3820.  
  3821.  
  3822. -
  3823.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3824.  with "unsubscribe usr-tc" in the body of the message.
  3825.  For information on digests or retrieving files and old messages send
  3826.  "help" to the same address.  Do not use quotes in your message.
  3827.  
  3828.  
  3829. -------------------------------------------------------------------------------
  3830.  
  3831. From: Jeff Mcadams <jeffm@iglou.com>
  3832. Subject: Re: (usr-tc) Caveat Emptor
  3833. Date: 02 Mar 1999 16:22:45 -0500 (EST)
  3834.  
  3835. Thus spake Ronald E. Kushner
  3836. >Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486
  3837. >DX2/66, there may be performance issues on running the HARC code on the
  3838. >Netserver. 
  3839.  
  3840. Of course, none of this changes the whole core of the issue.  That being
  3841. that 3Com is trying to make me pay for hardware in order to get a 
  3842. software fix.
  3843.  
  3844. >How much RAM did the Netservers have, 8MB?  
  3845.  
  3846. I think the earliest ones came with 4 MB, but could be easily (SIMM swap
  3847. out) be upgraded to at least 16.  Later ones came with at least 16
  3848. already on board.
  3849.  
  3850. >Sometimes it's not easy to take something designed for one platform and move
  3851. >it to another. Do you want to pay Cisco prices for 3Com equipment? There is
  3852. >a reason why Cisco equipment in general costs 40% more than anyone elses. 
  3853.  
  3854. Heh...so you're saying that 3Com had a total lack of foresight
  3855. basically.  That's all I'm really saying...and that they're trying to
  3856. make *me* pay because *they* screwed up.
  3857.  
  3858. >Do you commonly ask BMW to drop in a Volkswagen engine into your car because
  3859. >you already have the engine or to fix a stalling problem?
  3860.  
  3861. No, but if BMW has to replace that engine with a new engine of their own
  3862. to fix a stalling problem (particularly under warranty!) I would darn sure 
  3863. expect them to do that.
  3864.  
  3865. Again...here's what it comes down to.
  3866.  
  3867. I bought NETServers and want to get cross-chassis bundling working, 
  3868. and 3Com is telling me I have to buy new hardware to do that.  You
  3869. *CANNOT* argue that the NETServer hardware is incapable of handling
  3870. cross-chassis bundling.  Therefore, 3Com is guilty of Bait and Switch
  3871. tactics here.  I just don't see how it can be argued any other way.
  3872. -- 
  3873. Jeff McAdams                            Email: jeffm@iglou.com
  3874. Head Network Administrator              Voice: (502) 966-3848
  3875. IgLou Internet Services                        (800) 436-4456
  3876.  
  3877. -
  3878.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3879.  with "unsubscribe usr-tc" in the body of the message.
  3880.  For information on digests or retrieving files and old messages send
  3881.  "help" to the same address.  Do not use quotes in your message.
  3882.  
  3883.  
  3884. -------------------------------------------------------------------------------
  3885.  
  3886. From: "Richard Gamberg" <bbhi@shaka.com>
  3887. Subject: (usr-tc) Updates / 56k=v.Unreliable
  3888. Date: 02 Mar 1999 11:24:11 -1000
  3889.  
  3890. I name 3Com as having 'the "most connectable" client and server modems' in
  3891. the latest update to the Interoperability page....
  3892.  
  3893. New Pages & Recent updates at the 56k=v.Unreliable site
  3894. http://808hi.com/56k/  [mirrored at http://808news.com/56k]
  3895.  
  3896. What's a 56k-compatible line? -     http://808hi.com/56k/56kline.htm
  3897. V.90 Interoperability status  -  http://808hi.com/56k/x2-interop.htm
  3898. Modems & Call Waiting -             http://808hi.com/56k/callwait.htm
  3899. RBS & 56k update -                  http://808hi.com/56k/rbs2.htm
  3900. Inexpensive, Decent 56k modems -    http://808hi.com/56k/buy56k.htm
  3901. Useful Links -                      http://808hi.com/56k/links.htm
  3902. How to Flashback 3Com/USR modems -  http://808hi.com/56k/flashback.htm
  3903.  
  3904. 56k TROUBLESHOOTING-  http://808hi.com/56k/r-rnut-x2-3.htm
  3905. Check Your Throughput -             http://808hi.com/56k/x2-thru.htm
  3906. Limiting Your Connect Speed -   http://808hi.com/56k/x2-linklimit.htm
  3907. Who Manufactured Your Modem? -      http://808hi.com/56k/whomadeit.htm
  3908. 3Com Diagnostic Screens -           http://808hi.com/56k/diag3com.htm
  3909. If you get 115.2k connects -        http://808hi.com/56k/x2-inf1.htm
  3910.  
  3911. LUCENT LT Winmodem / latest driver/firmware
  3912. http://808hi.com/56k/x2-lucent.htm
  3913.  
  3914. NEWS & UPDATES -       http://808hi.com/56k/news.htm
  3915. LATEST UPDATES -       http://808hi.com/56k/latest.htm
  3916.  
  3917. Why 56k=v.Unreliable - http://808hi.com/56k/why56kis.htm
  3918.  
  3919. From the guestbook -   http://808hi.com/56k/guestbook.htm
  3920. "AWESOME site...."
  3921. "Your page on limiting connection speed put me on the right track..."
  3922. "When you are totally frustrated this is a great place to go see that
  3923. you aren't alone!!!"
  3924. "Excellent page. I am the administrator for a regional cable/dialup
  3925. ISP and this is one of the most informative pages on 56k I have ever
  3926. read. I have gleaned much more useful information from your pages in
  3927. 30 minutes than I have ever received from 3Com (and that's having
  3928. direct access to one of their SE's). Thanks!"
  3929.  
  3930. Aloha,
  3931. Richard
  3932.  
  3933.  
  3934.  
  3935. -
  3936.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3937.  with "unsubscribe usr-tc" in the body of the message.
  3938.  For information on digests or retrieving files and old messages send
  3939.  "help" to the same address.  Do not use quotes in your message.
  3940.  
  3941.  
  3942. -------------------------------------------------------------------------------
  3943.  
  3944. From: Jeff Mcadams <jeffm@iglou.com>
  3945. Subject: Re: (usr-tc) Caveat Emptor
  3946. Date: 02 Mar 1999 16:25:40 -0500 (EST)
  3947.  
  3948. Thus spake Mike Andrews
  3949. >On Tue, 2 Mar 1999, Ronald E. Kushner wrote:
  3950. >> Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486
  3951. >> DX2/66, there may be performance issues on running the HARC code on the
  3952. >> Netserver. 
  3953.  
  3954. >486/100 I thought...  but still, that's the best argument I've heard so
  3955. >far for not doing it.  However...  they HAVE ported it to the NETserver/8
  3956. >and NETserver/16 line, and the USR Viper DSL.  All of those run on 486's.
  3957. >They don't have to deal with a packet bus, however, or with more than 16
  3958. >ports...  maybe it doesn't scale up to 96 ports well.
  3959.  
  3960. Yeah, that's the best argument yet...but that's not saying much.  The
  3961. arguments put forth so far have been pathetic at best.  Of course...when
  3962. has something not scaling to its design criteria stopped 3Com from
  3963. putting it out?  They put out the NETServer to handle 96 ports and it
  3964. didn't handle it.  Besides...I don't need it to support 96 ports, I just
  3965. need 48.
  3966. -- 
  3967. Jeff McAdams                            Email: jeffm@iglou.com
  3968. Head Network Administrator              Voice: (502) 966-3848
  3969. IgLou Internet Services                        (800) 436-4456
  3970.  
  3971. -
  3972.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  3973.  with "unsubscribe usr-tc" in the body of the message.
  3974.  For information on digests or retrieving files and old messages send
  3975.  "help" to the same address.  Do not use quotes in your message.
  3976.  
  3977.  
  3978. -------------------------------------------------------------------------------
  3979.  
  3980. From: David Bolen <db3l@ans.net>
  3981. Subject: Re: (usr-tc) Caveat Emptor
  3982. Date: 02 Mar 1999 16:35:06 EST
  3983.  
  3984. "Ronald E. Kushner" <ron@glis.net> writes:
  3985.  
  3986. > Well, seeing how the HARC is PPC 603e based, and the Netserver is a 486
  3987. > DX2/66, there may be performance issues on running the HARC code on the
  3988. > Netserver. 
  3989.  
  3990. Yeah, except that the first platform for this code base was the 486
  3991. based NETServer 16 product.
  3992.  
  3993. There was a long thread on this a while back (should be in the
  3994. archives) and let's just say there isn't any good technical reason not
  3995. to support the NETServer with the same code base.  But the business
  3996. decision is behind us now.
  3997.  
  3998. -- David
  3999.  
  4000. /-----------------------------------------------------------------------\
  4001.  \               David Bolen              \  Internet: db3l@ans.net    /
  4002.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  4003.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  4004. \-----------------------------------------------------------------------/
  4005.  
  4006. -
  4007.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4008.  with "unsubscribe usr-tc" in the body of the message.
  4009.  For information on digests or retrieving files and old messages send
  4010.  "help" to the same address.  Do not use quotes in your message.
  4011.  
  4012.  
  4013. -------------------------------------------------------------------------------
  4014.  
  4015. From: Dave Martin <dpm@netcetera.com>
  4016. Subject: (usr-tc) USR RADIUS attribute 38978 (x9842)
  4017. Date: 02 Mar 1999 13:46:25 -0800
  4018.  
  4019. Anybody know what this is?  If so, where did you find it.  I've searched
  4020. all of the HARC and RADIUS server docs I can find, o no avail...
  4021.  
  4022. Dave Martin                 Netcetera, Inc.            dpm@netcetera.com
  4023.                "Infinity Welcomes Careful Drivers"
  4024.  
  4025.  
  4026.  
  4027. -
  4028.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4029.  with "unsubscribe usr-tc" in the body of the message.
  4030.  For information on digests or retrieving files and old messages send
  4031.  "help" to the same address.  Do not use quotes in your message.
  4032.  
  4033.  
  4034. -------------------------------------------------------------------------------
  4035.  
  4036. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  4037. Subject: Re: (usr-tc) USR RADIUS attribute 38978 (x9842)
  4038. Date: 02 Mar 1999 16:15:06 -0600 (CST)
  4039.  
  4040.  Modem-Training-Time             0x9842  integer
  4041.  
  4042.  
  4043. this is a vsa
  4044.  
  4045. krish
  4046.  
  4047.         \    T.S.V. Krishnan  \
  4048.          \      Network System Engineer \ ( : - : )
  4049.           \     3Com ............   \
  4050.         ----------------------------------------------/
  4051. tkrishna@bubba.ae.usr.com  
  4052. ----------------------------/ http://interproc.ae.usr.com ----/
  4053. The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html
  4054.     Any Sufficiently advanced bug is indistinguishable for a feature.
  4055.                         - Rick Kulawiec
  4056.  
  4057. On Tue, 2 Mar 1999, Dave Martin wrote:
  4058.  
  4059. > Anybody know what this is?  If so, where did you find it.  I've searched
  4060. > all of the HARC and RADIUS server docs I can find, o no avail...
  4061. > 
  4062. > ------------------------------------------------------------------------
  4063. > Dave Martin                 Netcetera, Inc.            dpm@netcetera.com
  4064. >                "Infinity Welcomes Careful Drivers"
  4065. > ------------------------------------------------------------------------
  4066. > 
  4067. > 
  4068. > 
  4069. > -
  4070. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4071. >  with "unsubscribe usr-tc" in the body of the message.
  4072. >  For information on digests or retrieving files and old messages send
  4073. >  "help" to the same address.  Do not use quotes in your message.
  4074. > 
  4075.  
  4076. -
  4077.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4078.  with "unsubscribe usr-tc" in the body of the message.
  4079.  For information on digests or retrieving files and old messages send
  4080.  "help" to the same address.  Do not use quotes in your message.
  4081.  
  4082.  
  4083. -------------------------------------------------------------------------------
  4084.  
  4085. From: "Matt Harper" <Matt_Harper@mw.3com.com>
  4086. Subject: Re: (usr-tc) USR RADIUS attribute 38978 (x9842)
  4087. Date: 02 Mar 1999 16:10:42 -0600
  4088.  
  4089.  
  4090.  
  4091. 0x9842 is modem training time
  4092.  
  4093. -- Matt
  4094.  
  4095.  
  4096.  
  4097.  
  4098.  
  4099. Dave Martin <dpm@netcetera.com> on 03/02/99 03:46:25 PM
  4100.  
  4101. Please respond to usr-tc@lists.xmission.com
  4102.  
  4103. cc:    (Matt Harper/MW/US/3Com)
  4104.  
  4105.  
  4106.  
  4107.  
  4108. Anybody know what this is?  If so, where did you find it.  I've searched
  4109. all of the HARC and RADIUS server docs I can find, o no avail...
  4110.  
  4111. Dave Martin                 Netcetera, Inc.            dpm@netcetera.com
  4112.                "Infinity Welcomes Careful Drivers"
  4113.  
  4114.  
  4115.  
  4116. -
  4117.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4118.  with "unsubscribe usr-tc" in the body of the message.
  4119.  For information on digests or retrieving files and old messages send
  4120.  "help" to the same address.  Do not use quotes in your message.
  4121.  
  4122.  
  4123.  
  4124.  
  4125.  
  4126.  
  4127.  
  4128.  
  4129. -
  4130.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4131.  with "unsubscribe usr-tc" in the body of the message.
  4132.  For information on digests or retrieving files and old messages send
  4133.  "help" to the same address.  Do not use quotes in your message.
  4134.  
  4135.  
  4136. -------------------------------------------------------------------------------
  4137.  
  4138. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  4139. Subject: RE: (usr-tc) USR RADIUS attribute 38978 (x9842)
  4140. Date: 02 Mar 1999 16:03:23 -0600
  4141.  
  4142.  
  4143.  
  4144. |-----Original Message-----
  4145. |From: owner-usr-tc@lists.xmission.com
  4146. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dave Martin
  4147. |Sent: Tuesday, March 02, 1999 3:46 PM
  4148. |To: usr-tc@lists.xmission.com
  4149. |Subject: (usr-tc) USR RADIUS attribute 38978 (x9842)
  4150. |
  4151. |
  4152. |Anybody know what this is?  If so, where did you find it.  I've searched
  4153. |all of the HARC and RADIUS server docs I can find, o no avail...
  4154.  
  4155. USR_VSA    Modem-Training-Time    0x9842    integer
  4156.  
  4157. -M
  4158.  
  4159.  
  4160.  
  4161. -
  4162.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4163.  with "unsubscribe usr-tc" in the body of the message.
  4164.  For information on digests or retrieving files and old messages send
  4165.  "help" to the same address.  Do not use quotes in your message.
  4166.  
  4167.  
  4168. -------------------------------------------------------------------------------
  4169.  
  4170. From: <sagarwal@crash.ae.usr.com>
  4171. Subject: Re: (usr-tc) USR RADIUS attribute 38978 (x9842)
  4172. Date: 02 Mar 1999 16:10:21 -0600 (CST)
  4173.  
  4174. Dave,
  4175.  
  4176. Attribute 0x9842 is a VSA and stands for Modem Training Time. It is the
  4177. delay in seconds between the time when a call arrives and is actually
  4178. connected.
  4179.  
  4180. Details about it can be found in Hiper ARc user manual ( Appendix E).
  4181.  
  4182. Regards
  4183.  
  4184. Sanjay Agarwal 
  4185.  
  4186.  
  4187. On Tue, 2 Mar 1999, Dave Martin wrote:
  4188.  
  4189. > Anybody know what this is?  If so, where did you find it.  I've searched
  4190. > all of the HARC and RADIUS server docs I can find, o no avail...
  4191. > 
  4192. > ------------------------------------------------------------------------
  4193. > Dave Martin                 Netcetera, Inc.            dpm@netcetera.com
  4194. >                "Infinity Welcomes Careful Drivers"
  4195. > ------------------------------------------------------------------------
  4196. > 
  4197. > 
  4198. > 
  4199. > -
  4200. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4201. >  with "unsubscribe usr-tc" in the body of the message.
  4202. >  For information on digests or retrieving files and old messages send
  4203. >  "help" to the same address.  Do not use quotes in your message.
  4204. > 
  4205.  
  4206.  
  4207. -
  4208.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4209.  with "unsubscribe usr-tc" in the body of the message.
  4210.  For information on digests or retrieving files and old messages send
  4211.  "help" to the same address.  Do not use quotes in your message.
  4212.  
  4213.  
  4214. -------------------------------------------------------------------------------
  4215.  
  4216. From: Bob Purdon <bobp@southcom.com.au>
  4217. Subject: Re: (usr-tc) Caveat Emptor
  4218. Date: 03 Mar 1999 09:11:21 +1100 (EST)
  4219.  
  4220.  
  4221. > 486/100 I thought...
  4222.  
  4223. Ours are 486/100, with 20mb RAM.
  4224.  
  4225. > but still, that's the best argument I've heard so far for not doing
  4226. > it.
  4227.  
  4228. Didn't they state originally that they were going to do it?
  4229.  
  4230. > However...  they HAVE ported it to the NETserver/8 and NETserver/16
  4231. > line, and the USR Viper DSL.  All of those run on 486's. They don't
  4232. > have to deal with a packet bus, however, or with more than 16 ports...
  4233.  
  4234. I don't know how the packet bus is designed, but I'd have expected it tp
  4235. be pretty efficient, having being purpose designed.  Perhaps more
  4236. efficient that normal serial comms...
  4237.  
  4238. Regards,
  4239.  
  4240. Bob Purdon,
  4241. Technical Manager,
  4242. Southern Internet Services.
  4243.  
  4244.  
  4245. -
  4246.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4247.  with "unsubscribe usr-tc" in the body of the message.
  4248.  For information on digests or retrieving files and old messages send
  4249.  "help" to the same address.  Do not use quotes in your message.
  4250.  
  4251.  
  4252. -------------------------------------------------------------------------------
  4253.  
  4254. From: Jeff Mcadams <jeffm@iglou.com>
  4255. Subject: Re: (usr-tc) Caveat Emptor
  4256. Date: 02 Mar 1999 17:19:08 -0500 (EST)
  4257.  
  4258. Thus spake Bob Purdon
  4259. >> but still, that's the best argument I've heard so far for not doing
  4260. >> it.
  4261.  
  4262. >Didn't they state originally that they were going to do it?
  4263.  
  4264. Yes.
  4265.  
  4266. >> However...  they HAVE ported it to the NETserver/8 and NETserver/16
  4267. >> line, and the USR Viper DSL.  All of those run on 486's. They don't
  4268. >> have to deal with a packet bus, however, or with more than 16 ports...
  4269.  
  4270. >I don't know how the packet bus is designed, but I'd have expected it tp
  4271. >be pretty efficient, having being purpose designed.  Perhaps more
  4272. >efficient that normal serial comms...
  4273.  
  4274. Well, being a packet bus...you can basically think of it as a very high
  4275. speed ethernet.  Ethernet is a packet bus type of technology really...at
  4276. least in concept.  I can't imagine that it would cause much load on the
  4277. NETServer at all...I would assume (maybe I should learn better than to
  4278. assume with 3Com) that the pbus interface is done almost completely in
  4279. hardware, as it would really be a waste to do it completely in software.
  4280. -- 
  4281. Jeff McAdams                            Email: jeffm@iglou.com
  4282. Head Network Administrator              Voice: (502) 966-3848
  4283. IgLou Internet Services                        (800) 436-4456
  4284.  
  4285. -
  4286.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4287.  with "unsubscribe usr-tc" in the body of the message.
  4288.  For information on digests or retrieving files and old messages send
  4289.  "help" to the same address.  Do not use quotes in your message.
  4290.  
  4291.  
  4292. -------------------------------------------------------------------------------
  4293.  
  4294. From: Brian <signal@shreve.net>
  4295. Subject: (usr-tc) DUN and 4.1.59-1
  4296. Date: 02 Mar 1999 16:19:37 -0600 (CST)
  4297.  
  4298.  
  4299. I am told by tech support here, that certain versions of DUN/Windows don't
  4300. work with our equipment, and when they see this problem, they have the
  4301. customer download DUN 1.3 and fix the problem.
  4302.  
  4303. We are about to take on a customer base from an ISP we bought, of about
  4304. 2500 customers.  Tech support is worried that alot of these customers have
  4305. older dialers and will not work.
  4306.  
  4307. My question is, if the user has DUN 1.0, 1.2, 1.3, 95a, 95b, whatever, are
  4308. their any issues known between native DUN/95 and 4.1.59-1?  Is their a
  4309. more stable arc code that I should be on as far as compatibility?
  4310.  
  4311. Brian
  4312.  
  4313.  
  4314. Brian Feeny (BF304)     signal@shreve.net   
  4315. 318-222-2638 x 109    http://www.shreve.net/~signal      
  4316. Network Administrator   ShreveNet Inc. (ASN 11881)           
  4317.  
  4318.  
  4319. -
  4320.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4321.  with "unsubscribe usr-tc" in the body of the message.
  4322.  For information on digests or retrieving files and old messages send
  4323.  "help" to the same address.  Do not use quotes in your message.
  4324.  
  4325.  
  4326. -------------------------------------------------------------------------------
  4327.  
  4328. From: Dave Martin <dpm@netcetera.com>
  4329. Subject: Re: (usr-tc) USR RADIUS attribute 38978 (x9842)
  4330. Date: 02 Mar 1999 14:41:42 -0800
  4331.  
  4332. Thanks to everyone who responded with the answer.  Special thanks to those
  4333. who told me where to find it.  It turns out *not* to be in the HiPerARC
  4334. reference manual or addendum that are in the Document Library area of the
  4335. 3com website.  It *is* in the harc41user.pdf version of the User's manual
  4336. distributed with the HiPerARC code itself.
  4337.  
  4338. Future thanks to the 3com webmaster who, I'm sure, will add this document
  4339. to the Document Library ASAP... :-)
  4340.  
  4341.  
  4342. Dave Martin                 Netcetera, Inc.            dpm@netcetera.com
  4343.                "Infinity Welcomes Careful Drivers"
  4344.  
  4345.  
  4346.  
  4347. -
  4348.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4349.  with "unsubscribe usr-tc" in the body of the message.
  4350.  For information on digests or retrieving files and old messages send
  4351.  "help" to the same address.  Do not use quotes in your message.
  4352.  
  4353.  
  4354. -------------------------------------------------------------------------------
  4355.  
  4356. From: "Mark Starr" <squid@greenapple.com>
  4357. Subject: (usr-tc) Setting in TCM call control options
  4358. Date: 02 Mar 1999 17:39:50 -0500
  4359.  
  4360. Hello,
  4361.  What is/does the setting for T1 Tone Type (S47.1) in the call control
  4362. options for the modems of
  4363. a hiper card do? The two choices are mfTones and dtmfTones?
  4364. Thanks,
  4365. Mark
  4366.  
  4367.  
  4368.  
  4369.  
  4370.  
  4371. To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4372. with "unsubscribe usr-tc" in the body of the message.
  4373. For information on digests or retrieving files and old messages send
  4374. "help" to the same address.  Do not use quotes in your message.
  4375.  
  4376.  
  4377.  
  4378. -
  4379.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4380.  with "unsubscribe usr-tc" in the body of the message.
  4381.  For information on digests or retrieving files and old messages send
  4382.  "help" to the same address.  Do not use quotes in your message.
  4383.  
  4384.  
  4385. -------------------------------------------------------------------------------
  4386.  
  4387. From: Brian <signal@shreve.net>
  4388. Subject: Re: (usr-tc) Setting in TCM call control options
  4389. Date: 02 Mar 1999 17:02:07 -0600 (CST)
  4390.  
  4391. On Tue, 2 Mar 1999, Mark Starr wrote:
  4392.  
  4393. > Hello,
  4394. >  What is/does the setting for T1 Tone Type (S47.1) in the call control
  4395. > options for the modems of
  4396. > a hiper card do? The two choices are mfTones and dtmfTones?
  4397.  
  4398. When you provision a T1, it has a tone type, this can either be dtmf or
  4399. mf.
  4400.  
  4401. Brian
  4402.  
  4403.  
  4404.  
  4405. > Thanks,
  4406. > Mark
  4407. > 
  4408. > 
  4409. > 
  4410. > 
  4411. > 
  4412. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4413. > with "unsubscribe usr-tc" in the body of the message.
  4414. > For information on digests or retrieving files and old messages send
  4415. > "help" to the same address.  Do not use quotes in your message.
  4416. > 
  4417. > 
  4418. > 
  4419. > -
  4420. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4421. >  with "unsubscribe usr-tc" in the body of the message.
  4422. >  For information on digests or retrieving files and old messages send
  4423. >  "help" to the same address.  Do not use quotes in your message.
  4424. > 
  4425.  
  4426. Brian Feeny (BF304)     signal@shreve.net   
  4427. 318-222-2638 x 109    http://www.shreve.net/~signal      
  4428. Network Administrator   ShreveNet Inc. (ASN 11881)           
  4429.  
  4430.  
  4431. -
  4432.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4433.  with "unsubscribe usr-tc" in the body of the message.
  4434.  For information on digests or retrieving files and old messages send
  4435.  "help" to the same address.  Do not use quotes in your message.
  4436.  
  4437.  
  4438. -------------------------------------------------------------------------------
  4439.  
  4440. From: "Mark Starr" <squid@greenapple.com>
  4441. Subject: RE: (usr-tc) Setting in TCM call control options
  4442. Date: 02 Mar 1999 18:21:50 -0500
  4443.  
  4444. On Tue, 2 Mar 1999, Mark Starr wrote:
  4445. >
  4446. > > Hello,
  4447. > >  What is/does the setting for T1 Tone Type (S47.1) in the call control
  4448. > > options for the modems of
  4449. > > a hiper card do? The two choices are mfTones and dtmfTones?
  4450. >
  4451. > When you provision a T1, it has a tone type, this can either be dtmf or
  4452. > mf.
  4453. >
  4454. > Brian
  4455. >
  4456. > I'm using PRI lines from Ameritech for this. Any idea on which they might
  4457. be?
  4458.   Mark
  4459.  
  4460.  
  4461.  
  4462. -
  4463.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4464.  with "unsubscribe usr-tc" in the body of the message.
  4465.  For information on digests or retrieving files and old messages send
  4466.  "help" to the same address.  Do not use quotes in your message.
  4467.  
  4468.  
  4469. -------------------------------------------------------------------------------
  4470.  
  4471. From: David Bolen <db3l@ans.net>
  4472. Subject: RE: (usr-tc) Setting in TCM call control options
  4473. Date: 02 Mar 1999 18:36:37 EST
  4474.  
  4475. "Mark Starr" <squid@greenapple.com> writes:
  4476.  
  4477. > I'm using PRI lines from Ameritech for this. Any idea on which they might
  4478. > be?
  4479.  
  4480. Not applicable.  The tone type configuration is used for channelized
  4481. T1 circuits (ground start, loop start, E&M) for which the transmission
  4482. of information such as DNIS arrives in-band over the same DS0 as the
  4483. call, in advance of the start of the actual call data.  In such a
  4484. case, information is transmitted via one of the two types of tones.
  4485.  
  4486. For a PRI span, ISDN signaling is used over the D channel (common
  4487. channel or out of band) independent of the actual call path, and the
  4488. information is not transmitted via tones on the call path itself.  So
  4489. for that configuration, the parameter is ignored.
  4490.  
  4491. -- David
  4492.  
  4493. /-----------------------------------------------------------------------\
  4494.  \               David Bolen              \  Internet: db3l@ans.net    /
  4495.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  4496.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  4497. \-----------------------------------------------------------------------/
  4498.  
  4499. -
  4500.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4501.  with "unsubscribe usr-tc" in the body of the message.
  4502.  For information on digests or retrieving files and old messages send
  4503.  "help" to the same address.  Do not use quotes in your message.
  4504.  
  4505.  
  4506. -------------------------------------------------------------------------------
  4507.  
  4508. From: Steve Johnson <linuxnut@sonic.net>
  4509. Subject: (usr-tc) Security Holes.
  4510. Date: 02 Mar 1999 16:08:02 -0800 (PST)
  4511.  
  4512.  
  4513. I'm, trying to find out if there are any security issues I should be
  4514. worrying about on my Hiper Access Router card.  What is the latest system
  4515. version (most stable?)
  4516.  
  4517. -Steve
  4518.  
  4519.  
  4520. ----
  4521.       "Knowing others is wisdom, knowing your self is Enlightenment."
  4522.                                                    -- Lao-Tzu
  4523.  
  4524.  
  4525.  
  4526.  
  4527. -
  4528.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4529.  with "unsubscribe usr-tc" in the body of the message.
  4530.  For information on digests or retrieving files and old messages send
  4531.  "help" to the same address.  Do not use quotes in your message.
  4532.  
  4533.  
  4534. -------------------------------------------------------------------------------
  4535.  
  4536. From: "Ray Bellis" <rpb@community.net.uk>
  4537. Subject: RE: (usr-tc) USR RADIUS attribute 38978 (x9842)
  4538. Date: 03 Mar 1999 08:51:38 -0000
  4539.  
  4540. This is a multi-part message in MIME format.
  4541.  
  4542. ------=_NextPart_000_0003_01BE6553.0CE24940
  4543. Content-Type: text/plain;
  4544.     charset="iso-8859-1"
  4545. Content-Transfer-Encoding: 7bit
  4546.  
  4547. > Attribute 0x9842 is a VSA and stands for Modem Training Time. It is the
  4548. > delay in seconds between the time when a call arrives and is actually
  4549. > connected.
  4550. >
  4551. > Details about it can be found in Hiper ARc user manual ( Appendix E).
  4552.  
  4553. Is there any support for this on the NETserver?  It would be very useful for
  4554. some Radius accounting work I'm doing at the moment.
  4555.  
  4556. thanks,
  4557.  
  4558. Ray.
  4559.  
  4560. --
  4561. Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc
  4562. Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ   UK
  4563.       Telephone: +44-1865-856000  Fax: +44-1865-856001
  4564. Email: ray.bellis@community.net.uk   URL: http://www.community.co.uk/
  4565.  
  4566. ------=_NextPart_000_0003_01BE6553.0CE24940
  4567. Content-Type: text/x-vcard;
  4568.     name="Ray Bellis.vcf"
  4569. Content-Transfer-Encoding: quoted-printable
  4570. Content-Disposition: attachment;
  4571.     filename="Ray Bellis.vcf"
  4572.  
  4573. BEGIN:VCARD
  4574. VERSION:2.1
  4575. N:Bellis;Ray;;
  4576. FN:Ray Bellis
  4577. ORG:Oxford CommUnity Internet plc;
  4578. TITLE:Technical Director
  4579. TEL;WORK;VOICE:+44 (1865) 856000
  4580. TEL;WORK;FAX:+44 (1865) 856001
  4581. ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Windsor House=3D0D=3D0A12 High =
  4582. Street;Kidlington;Oxfordshire;OX5 2PJ;United Ki=3D
  4583. ngdom
  4584. LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Windsor House=3D0D=3D0A12 High =
  4585. Street=3D0D=3D0AKidlington, Oxfordshire OX5 2PJ=3D0D=3D
  4586. =3D0AUnited Kingdom
  4587. URL:
  4588. URL:http://www.community.co.uk/
  4589. EMAIL;PREF;INTERNET:rpb@community.net.uk
  4590. EMAIL;INTERNET:rpb@community.net.uk
  4591. EMAIL;INTERNET:rpb@community.co.uk
  4592. REV:19990205T105103Z
  4593. END:VCARD
  4594.  
  4595. ------=_NextPart_000_0003_01BE6553.0CE24940--
  4596.  
  4597.  
  4598. -
  4599.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4600.  with "unsubscribe usr-tc" in the body of the message.
  4601.  For information on digests or retrieving files and old messages send
  4602.  "help" to the same address.  Do not use quotes in your message.
  4603.  
  4604.  
  4605. -------------------------------------------------------------------------------
  4606.  
  4607. From: "Terry Kennedy" <terry@olypen.com>
  4608. Subject: (usr-tc) 1.2.59-1
  4609. Date: 03 Mar 1999 09:01:33 -0800
  4610.  
  4611. Upgraded to this code 2 weeks ago and except for one problem
  4612. it seems to work rather well for us. The problem is that we are 
  4613. hearing an increasing amount of complaints about sudden and
  4614. unwanted disconnects. I don't have more info than that right now
  4615. but I've started to. In the mean time anyone else had this problem?
  4616. If so, any quick ways to fix this aside from going back to 1.2.68 which 
  4617. had its' own set of problems. These DSP's are running channelized
  4618. T1, not PRI
  4619.  
  4620. Terry Kennedy
  4621. Olypen, Inc.
  4622.  
  4623.  
  4624. -
  4625.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4626.  with "unsubscribe usr-tc" in the body of the message.
  4627.  For information on digests or retrieving files and old messages send
  4628.  "help" to the same address.  Do not use quotes in your message.
  4629.  
  4630.  
  4631. -------------------------------------------------------------------------------
  4632.  
  4633. From: Greg Genge <greg@dynavar.com>
  4634. Subject: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335 US for 48
  4635. Date: 03 Mar 1999 11:06:05 -0700
  4636.  
  4637. I checked the info on the list and found no mention of any problem posting
  4638. items for sale on this list. I'm sure I'll be corrected if I'm wrong and I
  4639. apologize in advance if that's the case but here goes.
  4640.  
  4641. I noticed a couple people posting requesting to buy DSP cards. I have a
  4642. number of 3465 Double ups available for $8335 US delivered. Single cards
  4643. are $4200 each. These are brand new, full warranty, from a certified 3COM
  4644. (USRobotics) VAR. We want to move these quickly so we will beat any quote
  4645. for new cards by 5%. I also have a number or ARC Cards for $2000 each.
  4646. Custom configs are also no problem, AC, DC, 70, 130 AMP, 1 or 2 ARC's 1-14
  4647. DSP's, edgeserver, any combination.
  4648.  
  4649. As for my offer for free support, I have a number of Total Control trained
  4650. engineers on staff, including myself, and I offer free technical support to
  4651. Dynavar customers and even Non-Dynavar customers to show that we can add
  4652. value to you future purchases. We also have a full lab setup here with
  4653. spares galore if anyone ever needs urgent replacement. We also offer
  4654. on-site training, we just completed 2 courses each for a customer (18
  4655. students) Installation and Management, and HiPer ARC at less than 1/2
  4656. 3COM's on-site cost, and within 4 weeks of request.
  4657.  
  4658. Let me know if there is anything I can do for you.
  4659.  
  4660. Regards, Greg
  4661.  
  4662. Gregory F. Genge, President, Dynavar Networking, Inc.
  4663. Toll Free  877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct,
  4664. 5005 Fax, http://www.dynavar.com
  4665. #300, 1550 - 5th Street S.W.,  Calgary, Alberta, Canada, T2R-1K3
  4666. Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard,
  4667. Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran, Compatible,
  4668. Microcom (Compaq), Garrett, Sonic, Cobalt.
  4669.  
  4670. -
  4671.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4672.  with "unsubscribe usr-tc" in the body of the message.
  4673.  For information on digests or retrieving files and old messages send
  4674.  "help" to the same address.  Do not use quotes in your message.
  4675.  
  4676.  
  4677. -------------------------------------------------------------------------------
  4678.  
  4679. From: Mike Andrews <mandrews@termfrost.org>
  4680. Subject: Re: (usr-tc) 1.2.59-1
  4681. Date: 03 Mar 1999 13:08:11 -0500 (EST)
  4682.  
  4683. Turn v.42bis compression off on your DSPs -- that cured it for us.
  4684.  
  4685. I still haven't heard a definitive answer as to whether there's really a
  4686. v.42bis bug in the latest DSP code.  It sure seems like there is.  Even
  4687. Couriers get dropped spontaneously with it turned on...
  4688.  
  4689.  
  4690. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  4691. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  4692. getting beaten by the police, put down the video camera and come help me!"
  4693.  
  4694. On Wed, 3 Mar 1999, Terry Kennedy wrote:
  4695.  
  4696. > Upgraded to this code 2 weeks ago and except for one problem
  4697. > it seems to work rather well for us. The problem is that we are 
  4698. > hearing an increasing amount of complaints about sudden and
  4699. > unwanted disconnects. I don't have more info than that right now
  4700. > but I've started to. In the mean time anyone else had this problem?
  4701. > If so, any quick ways to fix this aside from going back to 1.2.68 which 
  4702. > had its' own set of problems. These DSP's are running channelized
  4703. > T1, not PRI
  4704. > 
  4705. > Terry Kennedy
  4706. > Olypen, Inc.
  4707. > 
  4708. > 
  4709. > -
  4710. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4711. >  with "unsubscribe usr-tc" in the body of the message.
  4712. >  For information on digests or retrieving files and old messages send
  4713. >  "help" to the same address.  Do not use quotes in your message.
  4714. > 
  4715.  
  4716.  
  4717. -
  4718.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4719.  with "unsubscribe usr-tc" in the body of the message.
  4720.  For information on digests or retrieving files and old messages send
  4721.  "help" to the same address.  Do not use quotes in your message.
  4722.  
  4723.  
  4724. -------------------------------------------------------------------------------
  4725.  
  4726. From: K Mitchell <mitch@keyconn.net>
  4727. Subject: Re: (usr-tc) 1.2.59-1
  4728. Date: 03 Mar 1999 13:34:27 -0500
  4729.  
  4730. At 01:08 PM 3/3/99 -0500, Mike Andrews <mandrews@termfrost.org> wrote:
  4731. >Turn v.42bis compression off on your DSPs -- that cured it for us.
  4732.  
  4733. How will this affect other users that aren't experiencing random drops, etc?
  4734.  
  4735. >I still haven't heard a definitive answer as to whether there's really a
  4736. >v.42bis bug in the latest DSP code.  It sure seems like there is.  Even
  4737. >Couriers get dropped spontaneously with it turned on...
  4738.  
  4739.  
  4740.  
  4741. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  4742. Keystone Connect                http://www.keyconn.net
  4743. Altoona, PA   814-941-5000         We Unlock the World
  4744.  
  4745.  
  4746. -
  4747.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4748.  with "unsubscribe usr-tc" in the body of the message.
  4749.  For information on digests or retrieving files and old messages send
  4750.  "help" to the same address.  Do not use quotes in your message.
  4751.  
  4752.  
  4753. -------------------------------------------------------------------------------
  4754.  
  4755. From: Charles Sprickman <spork@inch.com>
  4756. Subject: (usr-tc) more SNMP questions...
  4757. Date: 03 Mar 1999 13:42:05 -0500 (EST)
  4758.  
  4759. Hi,
  4760.  
  4761. I just finished a little perl script to poll all of our chassis.  It
  4762. checks whether all cards are installed, whether all interfaces are
  4763. up/available, power supply status, environ. status, modem availability,
  4764. and error count on the T1 lines.  I just don't trust traps, so I poke the
  4765. chassis instead to see that these values are OK.
  4766.  
  4767. After I clean it up a bit (I'm very new to perl) I'd like to post/share it
  4768. for comments and improvements.  I'd also like to get some feedback on what
  4769. else I can monitor.  I'm pretty happy with what I have so far, as I think
  4770. I could catch most problems before any customers might notice, but I'm
  4771. sure there's more to look at.
  4772.  
  4773. One thing I know I'm missing is the ability to catch a modem that is
  4774. having difficulties connecting (basically I'd like to count
  4775. connections/hour and warn if it's high), but I'm not sure how to go about
  4776. that until we finish installing Radiator and start db logging of calls.
  4777.  
  4778. Any ideas (David??)
  4779.  
  4780. Thanks,
  4781.  
  4782. Charles
  4783.  
  4784. -- 
  4785. =-----------------=                                        = 
  4786. | Charles Sprickman                       Internet Channel |
  4787. | INCH System Administration Team         (212)243-5200    |
  4788. | spork@inch.com                          access@inch.com  |
  4789. =                                         =----------------=
  4790.  
  4791.  
  4792. -
  4793.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4794.  with "unsubscribe usr-tc" in the body of the message.
  4795.  For information on digests or retrieving files and old messages send
  4796.  "help" to the same address.  Do not use quotes in your message.
  4797.  
  4798.  
  4799. -------------------------------------------------------------------------------
  4800.  
  4801. From: "Terry Kennedy" <terry@olypen.com>
  4802. Subject: Re: (usr-tc) 1.2.59-1
  4803. Date: 03 Mar 1999 10:53:53 -0800
  4804.  
  4805. Mike,
  4806.  
  4807. Thanks for the reply---
  4808.  
  4809. But, I feel stupid -- How do you do that ? I have looked at the line data
  4810. compression
  4811. which are set to autoenable, but cannot find V.42bis any where. What am I
  4812. missing?
  4813. I thought that it would be in the signal converter options but I can't find
  4814. it there either.
  4815. I found v.42 in the call control options but only for 12- 24 and 9600, also
  4816. no bis, just
  4817. v.42- Modem error control settings maybe - v.42/mnp (v.42
  4818. disableV.42enablemnp)?
  4819. -----Original Message-----
  4820.  
  4821.  
  4822. >Turn v.42bis compression off on your DSPs -- that cured it for us.
  4823. >
  4824. >I still haven't heard a definitive answer as to whether there's really a
  4825. >v.42bis bug in the latest DSP code.  It sure seems like there is.  Even
  4826. >Couriers get dropped spontaneously with it turned on...
  4827. >
  4828. >
  4829. >Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  4830. >mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  4831. >getting beaten by the police, put down the video camera and come help me!"
  4832. >
  4833. >On Wed, 3 Mar 1999, Terry Kennedy wrote:
  4834. >
  4835. >> Upgraded to this code 2 weeks ago and except for one problem
  4836. >> it seems to work rather well for us. The problem is that we are
  4837. >> hearing an increasing amount of complaints about sudden and
  4838. >> unwanted disconnects. I don't have more info than that right now
  4839. >> but I've started to. In the mean time anyone else had this problem?
  4840. >> If so, any quick ways to fix this aside from going back to 1.2.68 which
  4841. >> had its' own set of problems. These DSP's are running channelized
  4842. >> T1, not PRI
  4843. >>
  4844. >> Terry Kennedy
  4845. >> Olypen, Inc.
  4846. >>
  4847. >>
  4848. >> -
  4849. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4850. >>  with "unsubscribe usr-tc" in the body of the message.
  4851. >>  For information on digests or retrieving files and old messages send
  4852. >>  "help" to the same address.  Do not use quotes in your message.
  4853. >>
  4854. >
  4855. >
  4856. >-
  4857. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4858. > with "unsubscribe usr-tc" in the body of the message.
  4859. > For information on digests or retrieving files and old messages send
  4860. > "help" to the same address.  Do not use quotes in your message.
  4861. >
  4862.  
  4863.  
  4864. -
  4865.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4866.  with "unsubscribe usr-tc" in the body of the message.
  4867.  For information on digests or retrieving files and old messages send
  4868.  "help" to the same address.  Do not use quotes in your message.
  4869.  
  4870.  
  4871. -------------------------------------------------------------------------------
  4872.  
  4873. From: Mike Andrews <mandrews@termfrost.org>
  4874. Subject: Re: (usr-tc) 1.2.59-1
  4875. Date: 03 Mar 1999 14:03:50 -0500 (EST)
  4876.  
  4877. If you're using TCM, highlight all your modems, go to Configure, then
  4878. Programmed Settings, and it's under "Data Compression Settings" (not
  4879. signal convertor or anything else)-- in fact it's the only setting in that
  4880. category.  Change from "autoenable" to "none".
  4881.  
  4882.  
  4883. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  4884. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  4885. getting beaten by the police, put down the video camera and come help me!"
  4886.  
  4887. On Wed, 3 Mar 1999, Terry Kennedy wrote:
  4888.  
  4889. > Mike,
  4890. > 
  4891. > Thanks for the reply---
  4892. > 
  4893. > But, I feel stupid -- How do you do that ? I have looked at the line data
  4894. > compression
  4895. > which are set to autoenable, but cannot find V.42bis any where. What am I
  4896. > missing?
  4897. > I thought that it would be in the signal converter options but I can't find
  4898. > it there either.
  4899. > I found v.42 in the call control options but only for 12- 24 and 9600, also
  4900. > no bis, just
  4901. > v.42- Modem error control settings maybe - v.42/mnp (v.42
  4902. > disableV.42enablemnp)?
  4903. > -----Original Message-----
  4904. > From: Mike Andrews <mandrews@termfrost.org>
  4905. > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  4906. > Date: Wednesday, March 03, 1999 10:17 AM
  4907. > Subject: Re: (usr-tc) 1.2.59-1
  4908. > 
  4909. > 
  4910. > >Turn v.42bis compression off on your DSPs -- that cured it for us.
  4911. > >
  4912. > >I still haven't heard a definitive answer as to whether there's really a
  4913. > >v.42bis bug in the latest DSP code.  It sure seems like there is.  Even
  4914. > >Couriers get dropped spontaneously with it turned on...
  4915. > >
  4916. > >
  4917. > >Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  4918. > >mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  4919. > >getting beaten by the police, put down the video camera and come help me!"
  4920. > >
  4921. > >On Wed, 3 Mar 1999, Terry Kennedy wrote:
  4922. > >
  4923. > >> Upgraded to this code 2 weeks ago and except for one problem
  4924. > >> it seems to work rather well for us. The problem is that we are
  4925. > >> hearing an increasing amount of complaints about sudden and
  4926. > >> unwanted disconnects. I don't have more info than that right now
  4927. > >> but I've started to. In the mean time anyone else had this problem?
  4928. > >> If so, any quick ways to fix this aside from going back to 1.2.68 which
  4929. > >> had its' own set of problems. These DSP's are running channelized
  4930. > >> T1, not PRI
  4931. > >>
  4932. > >> Terry Kennedy
  4933. > >> Olypen, Inc.
  4934. > >>
  4935. > >>
  4936. > >> -
  4937. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4938. > >>  with "unsubscribe usr-tc" in the body of the message.
  4939. > >>  For information on digests or retrieving files and old messages send
  4940. > >>  "help" to the same address.  Do not use quotes in your message.
  4941. > >>
  4942. > >
  4943. > >
  4944. > >-
  4945. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4946. > > with "unsubscribe usr-tc" in the body of the message.
  4947. > > For information on digests or retrieving files and old messages send
  4948. > > "help" to the same address.  Do not use quotes in your message.
  4949. > >
  4950. > 
  4951. > 
  4952. > -
  4953. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4954. >  with "unsubscribe usr-tc" in the body of the message.
  4955. >  For information on digests or retrieving files and old messages send
  4956. >  "help" to the same address.  Do not use quotes in your message.
  4957. > 
  4958.  
  4959.  
  4960. -
  4961.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  4962.  with "unsubscribe usr-tc" in the body of the message.
  4963.  For information on digests or retrieving files and old messages send
  4964.  "help" to the same address.  Do not use quotes in your message.
  4965.  
  4966.  
  4967. -------------------------------------------------------------------------------
  4968.  
  4969. From: Steve Lynn <stevelynn@mindspring.net>
  4970. Subject: Re: (usr-tc) more SNMP questions...
  4971. Date: 03 Mar 1999 19:04:04 +0000
  4972.  
  4973. This variable is a good indicator of faulty modems.
  4974. It gives a count of incoming connect fails since last reboot.
  4975.  
  4976. mdmEvInConnAttemptFails
  4977. .1.3.6.1.4.1.429.1.6.10.1.1.24
  4978. The number of times the modem has reported a inbound connect
  4979. attempt failure event. This does not include those connect attempt
  4980. failues that are reported due to no dial time and no loop current.
  4981.  
  4982. And to catch the incoming call attempts that do not make it to
  4983. the modem you may want to use this one.
  4984.  
  4985. usrinCallmodemNotAvail
  4986. .1.3.6.1.4.1.429.1.27.2.1.10
  4987. Incremented every time an incoming call can not be completed due
  4988. to no idle modem available.
  4989.  
  4990.  
  4991. -Steve
  4992.  
  4993.  
  4994. Charles Sprickman wrote:
  4995.  
  4996. > Hi,
  4997. >
  4998. > I just finished a little perl script to poll all of our chassis.  It
  4999. > checks whether all cards are installed, whether all interfaces are
  5000. > up/available, power supply status, environ. status, modem availability,
  5001. > and error count on the T1 lines.  I just don't trust traps, so I poke the
  5002. > chassis instead to see that these values are OK.
  5003. >
  5004. > After I clean it up a bit (I'm very new to perl) I'd like to post/share it
  5005. > for comments and improvements.  I'd also like to get some feedback on what
  5006. > else I can monitor.  I'm pretty happy with what I have so far, as I think
  5007. > I could catch most problems before any customers might notice, but I'm
  5008. > sure there's more to look at.
  5009. >
  5010. > One thing I know I'm missing is the ability to catch a modem that is
  5011. > having difficulties connecting (basically I'd like to count
  5012. > connections/hour and warn if it's high), but I'm not sure how to go about
  5013. > that until we finish installing Radiator and start db logging of calls.
  5014. >
  5015. > Any ideas (David??)
  5016. >
  5017. > Thanks,
  5018. >
  5019. > Charles
  5020. >
  5021. > --
  5022. > =-----------------=                                        =
  5023. > | Charles Sprickman                       Internet Channel |
  5024. > | INCH System Administration Team         (212)243-5200    |
  5025. > | spork@inch.com                          access@inch.com  |
  5026. > =                                         =----------------=
  5027. >
  5028. > -
  5029. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5030. >  with "unsubscribe usr-tc" in the body of the message.
  5031. >  For information on digests or retrieving files and old messages send
  5032. >  "help" to the same address.  Do not use quotes in your message.
  5033.  
  5034.  
  5035. -
  5036.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5037.  with "unsubscribe usr-tc" in the body of the message.
  5038.  For information on digests or retrieving files and old messages send
  5039.  "help" to the same address.  Do not use quotes in your message.
  5040.  
  5041.  
  5042. -------------------------------------------------------------------------------
  5043.  
  5044. From: Jim Johnson <jim@perigee.net>
  5045. Subject: Re: (usr-tc) 1.2.59-1
  5046. Date: 03 Mar 1999 14:04:38 -0500
  5047.  
  5048.  
  5049.  
  5050. 1) What setting do you use in TCM to disable v.42bis compression?
  5051. 2) Will this cause any other problems?
  5052. 3) If it doesn't work well, shouldn't 3COM disable it in the default
  5053. settings?  
  5054. 4) Is there a searchable archive of this list?
  5055.  
  5056. Thanks,
  5057.  
  5058. Jim
  5059.  
  5060. K Mitchell wrote:
  5061. > 
  5062. > At 01:08 PM 3/3/99 -0500, Mike Andrews <mandrews@termfrost.org> wrote:
  5063. > >Turn v.42bis compression off on your DSPs -- that cured it for us.
  5064. > 
  5065. > How will this affect other users that aren't experiencing random drops, etc?
  5066. > 
  5067. > >I still haven't heard a definitive answer as to whether there's really a
  5068. > >v.42bis bug in the latest DSP code.  It sure seems like there is.  Even
  5069. > >Couriers get dropped spontaneously with it turned on...
  5070. > 
  5071. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  5072. > Keystone Connect                http://www.keyconn.net
  5073. > Altoona, PA   814-941-5000         We Unlock the World
  5074. > 
  5075. > -
  5076. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5077. >  with "unsubscribe usr-tc" in the body of the message.
  5078. >  For information on digests or retrieving files and old messages send
  5079. >  "help" to the same address.  Do not use quotes in your message.
  5080.  
  5081. -
  5082.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5083.  with "unsubscribe usr-tc" in the body of the message.
  5084.  For information on digests or retrieving files and old messages send
  5085.  "help" to the same address.  Do not use quotes in your message.
  5086.  
  5087.  
  5088. -------------------------------------------------------------------------------
  5089.  
  5090. From: Mike Andrews <mandrews@termfrost.org>
  5091. Subject: Re: (usr-tc) 1.2.59-1
  5092. Date: 03 Mar 1999 14:09:54 -0500 (EST)
  5093.  
  5094. On Wed, 3 Mar 1999, Jim Johnson wrote:
  5095.  
  5096. > 1) What setting do you use in TCM to disable v.42bis compression?
  5097.  
  5098. See previous posting; it's under data compression options...
  5099.  
  5100.  
  5101. > 2) Will this cause any other problems?
  5102.  
  5103. Slows down transfer of stuff that compresses well (text), but otherwise no
  5104. impact.
  5105.  
  5106.  
  5107. > 3) If it doesn't work well, shouldn't 3COM disable it in the default
  5108. > settings?  
  5109.  
  5110. It seemed to work in previous versions, and still works great on Quads.
  5111.  
  5112.  
  5113. > 4) Is there a searchable archive of this list?
  5114.  
  5115. http://usr-tc.datasys.net/
  5116.  
  5117.  
  5118. -
  5119.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5120.  with "unsubscribe usr-tc" in the body of the message.
  5121.  For information on digests or retrieving files and old messages send
  5122.  "help" to the same address.  Do not use quotes in your message.
  5123.  
  5124.  
  5125. -------------------------------------------------------------------------------
  5126.  
  5127. From: "Ronald E. Kushner" <ron@glis.net>
  5128. Subject: Re: (usr-tc) 1.2.59-1
  5129. Date: 03 Mar 1999 14:36:00 -0500
  5130.  
  5131.  
  5132.  
  5133. Mike Andrews wrote:
  5134. > 
  5135. > If you're using TCM, highlight all your modems, go to Configure, then
  5136. > Programmed Settings, and it's under "Data Compression Settings" (not
  5137. > signal convertor or anything else)-- in fact it's the only setting in that
  5138. > category.  Change from "autoenable" to "none".
  5139. > 
  5140.  
  5141. That is the improper way to turn off V.42bis. When you reboot the card it
  5142. will come back on even if you save the settings to NVRAM.
  5143.  
  5144. You have to go into the HiPer ARC, type this in:
  5145.  
  5146. SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0 
  5147. SAVE ALL
  5148.  
  5149. Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards
  5150. after they load their NVRAM settings.
  5151.  
  5152. -Ron
  5153. GLISnet, Inc.
  5154. +1 810/939.9885
  5155.  
  5156. -
  5157.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5158.  with "unsubscribe usr-tc" in the body of the message.
  5159.  For information on digests or retrieving files and old messages send
  5160.  "help" to the same address.  Do not use quotes in your message.
  5161.  
  5162.  
  5163. -------------------------------------------------------------------------------
  5164.  
  5165. From: Mike Andrews <mandrews@termfrost.org>
  5166. Subject: Re: (usr-tc) 1.2.59-1
  5167. Date: 03 Mar 1999 14:47:30 -0500 (EST)
  5168.  
  5169. On Wed, 3 Mar 1999, Ronald E. Kushner wrote:
  5170.  
  5171. > Mike Andrews wrote:
  5172. > > 
  5173. > > If you're using TCM, highlight all your modems, go to Configure, then
  5174. > > Programmed Settings, and it's under "Data Compression Settings" (not
  5175. > > signal convertor or anything else)-- in fact it's the only setting in that
  5176. > > category.  Change from "autoenable" to "none".
  5177. > > 
  5178. > 
  5179. > That is the improper way to turn off V.42bis. When you reboot the card it
  5180. > will come back on even if you save the settings to NVRAM.
  5181. > 
  5182. > You have to go into the HiPer ARC, type this in:
  5183. > 
  5184. > SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0 
  5185. > SAVE ALL
  5186. > 
  5187. > Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards
  5188. > after they load their NVRAM settings.
  5189.  
  5190. You've gotta be kidding me... where's that documented?  The default string
  5191. is just ATS0X0... how does that turn v.42bis on?  If that's not it, what's
  5192. the mechanism for doing it?  I don't like things that go and spontaneously
  5193. change my modem settings behind my back from what I've set 'em all to...
  5194.  
  5195. Besides, doing it that way would turn it off on all the Quads I have (I
  5196. have some racks with both quads and dsp's), and v.42bis compression works
  5197. fine on the Quads and I'd rather not turn it off.  (In fact I'd rather not
  5198. have to turn it off on ANYTHING, but there seems to be a major bug here
  5199. even though nobody has acknowledged it...)
  5200.  
  5201.  
  5202. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  5203. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  5204. getting beaten by the police, put down the video camera and come help me!"
  5205.  
  5206.  
  5207. -
  5208.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5209.  with "unsubscribe usr-tc" in the body of the message.
  5210.  For information on digests or retrieving files and old messages send
  5211.  "help" to the same address.  Do not use quotes in your message.
  5212.  
  5213.  
  5214. -------------------------------------------------------------------------------
  5215.  
  5216. From: Charles Sprickman <spork@inch.com>
  5217. Subject: Re: (usr-tc) more SNMP questions...
  5218. Date: 03 Mar 1999 14:49:42 -0500 (EST)
  5219.  
  5220. On Wed, 3 Mar 1999, Steve Lynn wrote:
  5221.  
  5222. > mdmEvInConnAttemptFails
  5223. > .1.3.6.1.4.1.429.1.6.10.1.1.24
  5224. > The number of times the modem has reported a inbound connect
  5225. > attempt failure event. This does not include those connect attempt
  5226. > failues that are reported due to no dial time and no loop current.
  5227.  
  5228. This is interesting...  I'm looking at a chassis that includes quads and
  5229. DSPs, and the DSPs are reporting at least double the number of failures.
  5230. Quads are averaging about 18, while the DSPs are averaging about 58...
  5231.  
  5232. > And to catch the incoming call attempts that do not make it to
  5233. > the modem you may want to use this one.
  5234. > 
  5235. > usrinCallmodemNotAvail
  5236. > .1.3.6.1.4.1.429.1.27.2.1.10
  5237.  
  5238. Thanks very much, this is great stuff.  I'm still a bit new to snmp, but
  5239. it never ceases to amaze me.  Next is PHP with the snmp module for some
  5240. "on-demand" stats/usernames/whatever.
  5241.  
  5242. Keep 'em comin,
  5243.  
  5244. Charles
  5245.  
  5246. > Incremented every time an incoming call can not be completed due
  5247. > to no idle modem available.
  5248. > 
  5249. > 
  5250. > -Steve
  5251. > 
  5252. > 
  5253. > Charles Sprickman wrote:
  5254. > 
  5255. > > Hi,
  5256. > >
  5257. > > I just finished a little perl script to poll all of our chassis.  It
  5258. > > checks whether all cards are installed, whether all interfaces are
  5259. > > up/available, power supply status, environ. status, modem availability,
  5260. > > and error count on the T1 lines.  I just don't trust traps, so I poke the
  5261. > > chassis instead to see that these values are OK.
  5262. > >
  5263. > > After I clean it up a bit (I'm very new to perl) I'd like to post/share it
  5264. > > for comments and improvements.  I'd also like to get some feedback on what
  5265. > > else I can monitor.  I'm pretty happy with what I have so far, as I think
  5266. > > I could catch most problems before any customers might notice, but I'm
  5267. > > sure there's more to look at.
  5268. > >
  5269. > > One thing I know I'm missing is the ability to catch a modem that is
  5270. > > having difficulties connecting (basically I'd like to count
  5271. > > connections/hour and warn if it's high), but I'm not sure how to go about
  5272. > > that until we finish installing Radiator and start db logging of calls.
  5273. > >
  5274. > > Any ideas (David??)
  5275. > >
  5276. > > Thanks,
  5277. > >
  5278. > > Charles
  5279. > >
  5280. > > --
  5281. > > =-----------------=                                        =
  5282. > > | Charles Sprickman                       Internet Channel |
  5283. > > | INCH System Administration Team         (212)243-5200    |
  5284. > > | spork@inch.com                          access@inch.com  |
  5285. > > =                                         =----------------=
  5286. > >
  5287. > > -
  5288. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5289. > >  with "unsubscribe usr-tc" in the body of the message.
  5290. > >  For information on digests or retrieving files and old messages send
  5291. > >  "help" to the same address.  Do not use quotes in your message.
  5292. > 
  5293. > 
  5294. > -
  5295. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5296. >  with "unsubscribe usr-tc" in the body of the message.
  5297. >  For information on digests or retrieving files and old messages send
  5298. >  "help" to the same address.  Do not use quotes in your message.
  5299. > 
  5300.  
  5301.  
  5302. -
  5303.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5304.  with "unsubscribe usr-tc" in the body of the message.
  5305.  For information on digests or retrieving files and old messages send
  5306.  "help" to the same address.  Do not use quotes in your message.
  5307.  
  5308.  
  5309. -------------------------------------------------------------------------------
  5310.  
  5311. From: Steve Johnson <linuxnut@sonic.net>
  5312. Subject: (usr-tc) TCM
  5313. Date: 03 Mar 1999 12:54:54 -0800 (PST)
  5314.  
  5315.  
  5316. What is the latest version of TCM, and can someone tell me where I can get
  5317. it?
  5318.  
  5319. -Steve
  5320.  
  5321.  
  5322. ----
  5323.       "Knowing others is wisdom, knowing your self is Enlightenment."
  5324.                                                    -- Lao-Tzu
  5325.  
  5326.  
  5327.  
  5328.  
  5329. -
  5330.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5331.  with "unsubscribe usr-tc" in the body of the message.
  5332.  For information on digests or retrieving files and old messages send
  5333.  "help" to the same address.  Do not use quotes in your message.
  5334.  
  5335.  
  5336. -------------------------------------------------------------------------------
  5337.  
  5338. From: "Ronald E. Kushner" <ron@glis.net>
  5339. Subject: Re: (usr-tc) 1.2.59-1
  5340. Date: 03 Mar 1999 16:10:32 -0500
  5341.  
  5342.  
  5343.  
  5344. Mike Andrews wrote:
  5345. > 
  5346. > On Wed, 3 Mar 1999, Ronald E. Kushner wrote:
  5347. > 
  5348. > > Mike Andrews wrote:
  5349. > > >
  5350. > > > If you're using TCM, highlight all your modems, go to Configure, then
  5351. > > > Programmed Settings, and it's under "Data Compression Settings" (not
  5352. > > > signal convertor or anything else)-- in fact it's the only setting in that
  5353. > > > category.  Change from "autoenable" to "none".
  5354. > > >
  5355. > >
  5356. > > That is the improper way to turn off V.42bis. When you reboot the card it
  5357. > > will come back on even if you save the settings to NVRAM.
  5358. > >
  5359. > > You have to go into the HiPer ARC, type this in:
  5360. > >
  5361. > > SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0
  5362. > > SAVE ALL
  5363. > >
  5364. > > Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards
  5365. > > after they load their NVRAM settings.
  5366. > 
  5367. > You've gotta be kidding me... where's that documented?  The default string
  5368. > is just ATS0X0... how does that turn v.42bis on?  If that's not it, what's
  5369. > the mechanism for doing it?  I don't like things that go and spontaneously
  5370. > change my modem settings behind my back from what I've set 'em all to...
  5371. > 
  5372. > Besides, doing it that way would turn it off on all the Quads I have (I
  5373. > have some racks with both quads and dsp's), and v.42bis compression works
  5374. > fine on the Quads and I'd rather not turn it off.  (In fact I'd rather not
  5375. > have to turn it off on ANYTHING, but there seems to be a major bug here
  5376. > even though nobody has acknowledged it...)
  5377.  
  5378. V.42bis does not work fine on the Quads. It's generally the client modems
  5379. that are all screwed up, alot of Rockwell modems that date as far back as
  5380. V.32bis will disconnect at unknown times when talking V.42bis to the Quads.
  5381. I have disabled V.42bis, as far back as 1991 when we first started seeing
  5382. those rockwell junk modems in the market with buggy V.42bis code.
  5383.  
  5384. Anyways, this ATS0=0&K0 not documented anywhere I could find. But after
  5385. snooping around and making a few calls to 3Com I come to find out the HiPer
  5386. ARC sends an init string to the modems when the modem card after it
  5387. registers with the HARC. This init string is:
  5388.  
  5389. ATH0S0=0S72.0=1E0Q0V0&A0&K1&L0&N0&TX0S47.5=1S2=255
  5390.  
  5391. Well, guess what &K1 does....
  5392.  
  5393. You're better off turning off V.42bis and turning on Microsoft Compression
  5394. anyways. Microsoft compression has a much higher compression ratio than
  5395. V.42bis. If you're running both MS and V.42bis, V.42bis is just wasting
  5396. processing time to determine it can not be compressed again - this might
  5397. slightly increase throughput or reduce lag.
  5398.  
  5399. -Ron
  5400. GLISnet, Inc.
  5401. +1 810/939.9885
  5402.  
  5403. -
  5404.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5405.  with "unsubscribe usr-tc" in the body of the message.
  5406.  For information on digests or retrieving files and old messages send
  5407.  "help" to the same address.  Do not use quotes in your message.
  5408.  
  5409.  
  5410. -------------------------------------------------------------------------------
  5411.  
  5412. From: Brian <signal@shreve.net>
  5413. Subject: Re: (usr-tc) 1.2.59-1
  5414. Date: 03 Mar 1999 15:18:09 -0600 (CST)
  5415.  
  5416. On Wed, 3 Mar 1999, Ronald E. Kushner wrote:
  5417.  
  5418. > 
  5419. > 
  5420. > Mike Andrews wrote:
  5421. > > 
  5422. > > If you're using TCM, highlight all your modems, go to Configure, then
  5423. > > Programmed Settings, and it's under "Data Compression Settings" (not
  5424. > > signal convertor or anything else)-- in fact it's the only setting in that
  5425. > > category.  Change from "autoenable" to "none".
  5426. > > 
  5427. > 
  5428. > That is the improper way to turn off V.42bis. When you reboot the card it
  5429. > will come back on even if you save the settings to NVRAM.
  5430. > 
  5431. > You have to go into the HiPer ARC, type this in:
  5432. > 
  5433. > SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0 
  5434. > SAVE ALL
  5435.  
  5436.  
  5437. hmm, so your saying that the hiper arc has a script it runs AFTER the
  5438. modems are init'ed, and sets things up on the modems?  How do we list all
  5439. that this script does?
  5440.  
  5441.  
  5442. > 
  5443. > Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards
  5444. > after they load their NVRAM settings.
  5445. > 
  5446. > -Ron
  5447. > GLISnet, Inc.
  5448. > +1 810/939.9885
  5449. > 
  5450. > -
  5451. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5452. >  with "unsubscribe usr-tc" in the body of the message.
  5453. >  For information on digests or retrieving files and old messages send
  5454. >  "help" to the same address.  Do not use quotes in your message.
  5455. > 
  5456.  
  5457. Brian Feeny (BF304)     signal@shreve.net   
  5458. 318-222-2638 x 109    http://www.shreve.net/~signal      
  5459. Network Administrator   ShreveNet Inc. (ASN 11881)           
  5460.  
  5461.  
  5462. -
  5463.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5464.  with "unsubscribe usr-tc" in the body of the message.
  5465.  For information on digests or retrieving files and old messages send
  5466.  "help" to the same address.  Do not use quotes in your message.
  5467.  
  5468.  
  5469. -------------------------------------------------------------------------------
  5470.  
  5471. From: Carl Ansley <carl@caverock.com>
  5472. Subject: (usr-tc) Acct-Session-Time problem
  5473. Date: 03 Mar 1999 17:04:45 +1300 (NZDT)
  5474.  
  5475.  
  5476. Hi,
  5477.  
  5478. We've just moved from Netserver to HARC, so apologies in advance for a
  5479. potentially newbie question.  We're seeing some strange Acct-Session-Times
  5480. being reported every now and then with radius stop packets (~1 out of
  5481. every thousand).  It's a bit of a worry because we do time accounting
  5482. (i.e. charge users) based on this information.  We're running 4.1.11.
  5483.  
  5484. example:
  5485.  
  5486. 02/03/1999:13:02:08
  5487.         User-Name = "joebloggs"
  5488.         NAS-IP-Address = x.x.x.x
  5489.         Acct-Status-Type = Stop
  5490.         Acct-Session-Id = "17558"
  5491.         Acct-Delay-Time = 0
  5492.         Acct-Authentic = RADIUS
  5493.         Service-Type = Framed-User
  5494.         NAS-Port-Type = ISDN
  5495.         NAS-Port-Id = 1
  5496.         Calling-Station-Id = ""
  5497.         Called-Station-Id = "0330"
  5498.         Framed-Protocol = PPP
  5499.         Framed-IP-Address = x.x.x.x
  5500.         Acct-Session-Time = -85082   <----
  5501.         Acct-Terminate-Cause = User-Request
  5502.         Acct-Input-Octets = 22409
  5503.         Acct-Output-Octets = 243560
  5504.         Acct-Input-Packets = 1038
  5505.         Acct-Output-Packets = 796
  5506.  
  5507. We see this on both ISDN and analogue calls.  Is this a bug/feature anyone
  5508. else has seen?
  5509.  
  5510. btw another strange thing is that NAS-Port-Id is always reported as 1 on
  5511. accounting packets for dialin users, but is ok on authentication packets.
  5512. Probably some configuration thing, but damned if i can work out what.
  5513.  
  5514. --
  5515. Carl Ansley (carl@caverock.com)                Phone: +64 3 3664242
  5516. Cave Rock Software / Cave Rock Internet          Fax: +64 3 3665478
  5517. Unit 1a, 492 Moorhouse Ave, PO Box 22488, Christchurch, New Zealand
  5518.  
  5519. -
  5520.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5521.  with "unsubscribe usr-tc" in the body of the message.
  5522.  For information on digests or retrieving files and old messages send
  5523.  "help" to the same address.  Do not use quotes in your message.
  5524.  
  5525.  
  5526. -------------------------------------------------------------------------------
  5527.  
  5528. From: Carl Litt <carl@execulink.com>
  5529. Subject: (usr-tc) Anyone else have this problem?
  5530. Date: 02 Mar 1999 16:51:47 -0500 (EST)
  5531.  
  5532.  
  5533. (Sorry if anyone gets annoyed by this, but I couldn't resist.
  5534.  The screwdriver really bugs me sometimes :)
  5535.  
  5536.  
  5537. Is anyone else having trouble with their 3Com screwdriver?
  5538.  
  5539. When I enable the flat-head attachment, I have a lot of trouble
  5540. getting it to work.  It keeps wanting to fall out off the handle.
  5541. I don't understand it... I have an older USR screwdriver, and it
  5542. works great.
  5543.  
  5544. It also isn't compatable with all flat-head screws.  I have a
  5545. Dofasco 1/4" flat-head screw, and the damn screwdriver keeps slipping
  5546. out of the groove, forcing me to reseat it.  I can only get a couple
  5547. of turns on it before it falls out of the groove.  I don't expect
  5548. Dofasco can do anything, since all they have to do is provide a
  5549. groove for the screwdriver to fit in.  But then, I have heard of others
  5550. with this problem, so I wonder if maybe the flat-head-screwdriver
  5551. standard needs more development.  Either way, 3Com claims it works,
  5552. and I expect it to perform as advertised.
  5553.  
  5554. I called 3Com tech support on these matters, and they suggested
  5555. I tighten the screw holding the attachment to the handle.  I told
  5556. them I've tightened it as far as it will go and it still won't stay
  5557. on.  After making sure I'm turning the screw the right way, and
  5558. getting me to reseat it several times, he asks for the IP and SNMP
  5559. community of the screwdriver.  I try to explain to him that my screwdriver
  5560. is not routed on the Internet, and he responds that he can't really help
  5561. me until he can bring up the TCM on it.
  5562.  
  5563. As far as the Dofacso interoperatability issue, he says that the
  5564. screwdriver is pretty straight forward, and thus if I have picked the
  5565. right attachment, it should work.  Must be Dofasco's fault.
  5566.  
  5567. I called Dofasco, and they thought it was absurd that it was suggested
  5568. they were the source of the problem.  After testing with another 
  5569. screwdriver (a one-piece unit), I didn't have as much trouble as before.
  5570.  
  5571. I'm pretty fed up.  It's really tempting to go up to a nice
  5572. Snap-On, but they're really pricey.  But I think I'll stick it out a
  5573. bit longer.  There might be an engineering release.
  5574.  
  5575. -
  5576.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5577.  with "unsubscribe usr-tc" in the body of the message.
  5578.  For information on digests or retrieving files and old messages send
  5579.  "help" to the same address.  Do not use quotes in your message.
  5580.  
  5581.  
  5582. -------------------------------------------------------------------------------
  5583.  
  5584. From: "Chris Ashcraft" <Chris_Ashcraft@mw.3com.com>
  5585. Subject: (usr-tc) Re: connecting to hdm console or quad/dsp for outbound
  5586. Date: 02 Mar 1999 09:12:17 -0600
  5587.  
  5588.  
  5589.  
  5590. Hi Mike,
  5591.  
  5592. FYI
  5593. 3Com plans to support the HiPer DSP remote console (command line interface) with
  5594. Total Control system release 3.6.  Sometime in the next four months you should
  5595. hear more about this.
  5596.  
  5597. Chris Ashcraft
  5598. 3Com Corp.
  5599.  
  5600.  
  5601.  
  5602.  
  5603. Chris Ashcraft/MW/US/3Com
  5604. 03/01/99 10:39 AM
  5605.  
  5606.  
  5607. cc:
  5608.  
  5609. Hi Mike,
  5610.  
  5611. I'll get back to you about remotely accessing the HDM console. Regarding channel
  5612. testing, refer to Appendix C of the Quad Modem doc set. It is entitled Modem
  5613. Testing. There you should find the information you need.
  5614.  
  5615. All the best,
  5616. /Chris
  5617. 3Com Corp.
  5618.  
  5619. >From usr-tc
  5620.  
  5621.  
  5622.  
  5623. I've seen some hints in ARC documentation/release notes that say there's a
  5624. way to connect to an HDM console through the ARC somehow (presumably over
  5625. the packet bus)...  but I can't find the exact syntax anywhere.  This
  5626. would save me a few serial ports...
  5627.  
  5628. I'm also trying to figure out how to connect to a particular Quad (or DSP)
  5629. to feed it AT commands.  I have a channel on a Quad I suspect is dead and
  5630. I'm trying to poke at it a bit to see if it's really dead...
  5631.  
  5632. Someone want to point me at the relevant chunk of documentation?  Maybe
  5633. "search" in Acrobat just doesn't work well, but I'm having trouble finding
  5634. it.  (Call me blind.)
  5635.  
  5636.  
  5637. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  5638. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  5639. getting beaten by the police, put down the video camera and come help me!"
  5640.  
  5641. -
  5642.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5643.  with "unsubscribe usr-tc" in the body of the message.
  5644.  For information on digests or retrieving files and old messages send
  5645.  "help" to the same address.  Do not use quotes in your message.
  5646.  
  5647.  
  5648. -------------------------------------------------------------------------------
  5649.  
  5650. From: "Paul Jr. (AlaWeb Support)" <jr@alaweb.com>
  5651. Subject: Re: (usr-tc) Anyone else have this problem?
  5652. Date: 03 Mar 1999 15:32:21 -0600
  5653.  
  5654. That was real cute. :o)
  5655.  
  5656.  
  5657. Thanks
  5658. Paul JR.
  5659. AlaWeb Network Admin.
  5660. 1800-427-8896
  5661. http://www.alaweb.com/support.html
  5662.  
  5663.  
  5664.  
  5665.  
  5666. ----- Original Message -----
  5667. Sent: Tuesday, March 02, 1999 3:51 PM
  5668.  
  5669.  
  5670. >
  5671. >(Sorry if anyone gets annoyed by this, but I couldn't resist.
  5672. > The screwdriver really bugs me sometimes :)
  5673. >
  5674. >
  5675. >Is anyone else having trouble with their 3Com screwdriver?
  5676. >
  5677. >When I enable the flat-head attachment, I have a lot of trouble
  5678. >getting it to work.  It keeps wanting to fall out off the handle.
  5679. >I don't understand it... I have an older USR screwdriver, and it
  5680. >works great.
  5681. >
  5682. >It also isn't compatable with all flat-head screws.  I have a
  5683. >Dofasco 1/4" flat-head screw, and the damn screwdriver keeps slipping
  5684. >out of the groove, forcing me to reseat it.  I can only get a couple
  5685. >of turns on it before it falls out of the groove.  I don't expect
  5686. >Dofasco can do anything, since all they have to do is provide a
  5687. >groove for the screwdriver to fit in.  But then, I have heard of others
  5688. >with this problem, so I wonder if maybe the flat-head-screwdriver
  5689. >standard needs more development.  Either way, 3Com claims it works,
  5690. >and I expect it to perform as advertised.
  5691. >
  5692. >I called 3Com tech support on these matters, and they suggested
  5693. >I tighten the screw holding the attachment to the handle.  I told
  5694. >them I've tightened it as far as it will go and it still won't stay
  5695. >on.  After making sure I'm turning the screw the right way, and
  5696. >getting me to reseat it several times, he asks for the IP and SNMP
  5697. >community of the screwdriver.  I try to explain to him that my screwdriver
  5698. >is not routed on the Internet, and he responds that he can't really help
  5699. >me until he can bring up the TCM on it.
  5700. >
  5701. >As far as the Dofacso interoperatability issue, he says that the
  5702. >screwdriver is pretty straight forward, and thus if I have picked the
  5703. >right attachment, it should work.  Must be Dofasco's fault.
  5704. >
  5705. >I called Dofasco, and they thought it was absurd that it was suggested
  5706. >they were the source of the problem.  After testing with another
  5707. >screwdriver (a one-piece unit), I didn't have as much trouble as before.
  5708. >
  5709. >I'm pretty fed up.  It's really tempting to go up to a nice
  5710. >Snap-On, but they're really pricey.  But I think I'll stick it out a
  5711. >bit longer.  There might be an engineering release.
  5712. >
  5713. >-
  5714. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5715. > with "unsubscribe usr-tc" in the body of the message.
  5716. > For information on digests or retrieving files and old messages send
  5717. > "help" to the same address.  Do not use quotes in your message.
  5718. >
  5719.  
  5720.  
  5721.  
  5722.  
  5723. -
  5724.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5725.  with "unsubscribe usr-tc" in the body of the message.
  5726.  For information on digests or retrieving files and old messages send
  5727.  "help" to the same address.  Do not use quotes in your message.
  5728.  
  5729.  
  5730. -------------------------------------------------------------------------------
  5731.  
  5732. From: "Chris Ashcraft" <Chris_Ashcraft@mw.3com.com>
  5733. Subject: (usr-tc) connecting to hdm console or quad/dsp for outbound
  5734. Date: 01 Mar 1999 10:39:20 -0600
  5735.  
  5736.  
  5737.  
  5738. Hi Mike,
  5739.  
  5740. I'll get back to you about remotely accessing the HDM console. Regarding channel
  5741. testing, refer to Appendix C of the Quad Modem doc set. It is entitled Modem
  5742. Testing. There you should find the information you need.
  5743.  
  5744. All the best,
  5745. /Chris
  5746. 3Com Corp.
  5747.  
  5748. >From usr-tc
  5749.  
  5750.  
  5751.  
  5752. I've seen some hints in ARC documentation/release notes that say there's a
  5753. way to connect to an HDM console through the ARC somehow (presumably over
  5754. the packet bus)...  but I can't find the exact syntax anywhere.  This
  5755. would save me a few serial ports...
  5756.  
  5757. I'm also trying to figure out how to connect to a particular Quad (or DSP)
  5758. to feed it AT commands.  I have a channel on a Quad I suspect is dead and
  5759. I'm trying to poke at it a bit to see if it's really dead...
  5760.  
  5761. Someone want to point me at the relevant chunk of documentation?  Maybe
  5762. "search" in Acrobat just doesn't work well, but I'm having trouble finding
  5763. it.  (Call me blind.)
  5764.  
  5765.  
  5766. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  5767. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  5768. getting beaten by the police, put down the video camera and come help me!"
  5769.  
  5770. -
  5771.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5772.  with "unsubscribe usr-tc" in the body of the message.
  5773.  For information on digests or retrieving files and old messages send
  5774.  "help" to the same address.  Do not use quotes in your message.
  5775.  
  5776.  
  5777. -------------------------------------------------------------------------------
  5778.  
  5779. From: Jeff Mcadams <jeffm@iglou.com>
  5780. Subject: Re: (usr-tc) 1.2.59-1
  5781. Date: 03 Mar 1999 16:47:37 -0500 (EST)
  5782.  
  5783. Thus spake Ronald E. Kushner
  5784. >You're better off turning off V.42bis and turning on Microsoft Compression
  5785. >anyways. Microsoft compression has a much higher compression ratio than
  5786. >V.42bis. If you're running both MS and V.42bis, V.42bis is just wasting
  5787. >processing time to determine it can not be compressed again - this might
  5788. >slightly increase throughput or reduce lag.
  5789.  
  5790. I would disagree with this statement, at least in part.  Software
  5791. Compression (CCP) has benefits as does v.42bis modem compression...they
  5792. are not mutually exclusive, and each provides benefits and drawbacks
  5793. different from the other.
  5794.  
  5795. The main drawback of CCP is that its done by and large in software.
  5796. v.42bis is done in hardware in the modem.  CCP can bring an access
  5797. server to its knees potentially...the NETServer I believe will only run
  5798. CCP on about 12 or so lines...any further lines beyond that, the
  5799. NETServer will reject CCP on to prevent overloading the processor (at
  5800. least I've been told that in the past).
  5801. -- 
  5802. Jeff McAdams                            Email: jeffm@iglou.com
  5803. Head Network Administrator              Voice: (502) 966-3848
  5804. IgLou Internet Services                        (800) 436-4456
  5805.  
  5806. -
  5807.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5808.  with "unsubscribe usr-tc" in the body of the message.
  5809.  For information on digests or retrieving files and old messages send
  5810.  "help" to the same address.  Do not use quotes in your message.
  5811.  
  5812.  
  5813. -------------------------------------------------------------------------------
  5814.  
  5815. From: Brian <signal@shreve.net>
  5816. Subject: (usr-tc) MPIP server under UNIX
  5817. Date: 03 Mar 1999 15:57:30 -0600 (CST)
  5818.  
  5819.  
  5820. Has attempts to make an MPIP server under UNIX that will support the ARC's
  5821. abandoned or is their still work in this area?  I think it would be real
  5822. nice to have an mpipd for UNIX, rather than running it off an ARC.
  5823.  
  5824. brian
  5825.  
  5826.  
  5827. Brian Feeny (BF304)     signal@shreve.net   
  5828. 318-222-2638 x 109    http://www.shreve.net/~signal      
  5829. Network Administrator   ShreveNet Inc. (ASN 11881)           
  5830.  
  5831.  
  5832. -
  5833.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5834.  with "unsubscribe usr-tc" in the body of the message.
  5835.  For information on digests or retrieving files and old messages send
  5836.  "help" to the same address.  Do not use quotes in your message.
  5837.  
  5838.  
  5839. -------------------------------------------------------------------------------
  5840.  
  5841. From: Bob Purdon <bobp@southcom.com.au>
  5842. Subject: Re: (usr-tc) Anyone else have this problem?
  5843. Date: 04 Mar 1999 08:57:41 +1100 (EST)
  5844.  
  5845.  
  5846. > Is anyone else having trouble with their 3Com screwdriver?
  5847. > 
  5848. > When I enable the flat-head attachment, I have a lot of trouble
  5849. > getting it to work.  It keeps wanting to fall out off the handle.
  5850. > I don't understand it... I have an older USR screwdriver, and it
  5851. > works great.
  5852.  
  5853. Unfortunately 3COM no longer have access to the design for this model
  5854. screwdriver, so they are unable to fix it.  They have a new HiperDriver
  5855. though, and for only $9995 (upgrade bundle, includes new chassis), you too
  5856. can have one.
  5857.  
  5858. I'll bet they told you that you could reliably unscrew screws with the one
  5859. you've got, but as you've found, it doesn't work right.
  5860.  
  5861. Oh, btw, that model was end-of-lifed late last year.  Sorry.
  5862.  
  5863. Regards,
  5864.  
  5865. Bob Purdon,
  5866. Technical Manager,
  5867. Southern Internet Services.
  5868.  
  5869.  
  5870. -
  5871.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5872.  with "unsubscribe usr-tc" in the body of the message.
  5873.  For information on digests or retrieving files and old messages send
  5874.  "help" to the same address.  Do not use quotes in your message.
  5875.  
  5876.  
  5877. -------------------------------------------------------------------------------
  5878.  
  5879. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  5880. Subject: RE: (usr-tc) Acct-Session-Time problem
  5881. Date: 03 Mar 1999 16:05:45 -0600
  5882.  
  5883.  
  5884.  
  5885. |-----Original Message-----
  5886. |From: owner-usr-tc@lists.xmission.com
  5887. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Carl Ansley
  5888. |Sent: Tuesday, March 02, 1999 10:05 PM
  5889. |To: usr-tc@lists.xmission.com
  5890. |Subject: (usr-tc) Acct-Session-Time problem
  5891. |
  5892. |
  5893. |
  5894. |Hi,
  5895. |
  5896. |We've just moved from Netserver to HARC, so apologies in advance for a
  5897. |potentially newbie question.  We're seeing some strange Acct-Session-Times
  5898. |being reported every now and then with radius stop packets (~1 out of
  5899. |every thousand).  It's a bit of a worry because we do time accounting
  5900. |(i.e. charge users) based on this information.  We're running 4.1.11.
  5901. |                                                ^^^^^^^^^^^^^^^^^^^^^ This is
  5902. your problem.
  5903.  
  5904. Get the 4.1.59-1 code from Totalservice.  Both issues were resolved a while back.
  5905.  
  5906.  
  5907.  
  5908.  
  5909. -
  5910.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5911.  with "unsubscribe usr-tc" in the body of the message.
  5912.  For information on digests or retrieving files and old messages send
  5913.  "help" to the same address.  Do not use quotes in your message.
  5914.  
  5915.  
  5916. -------------------------------------------------------------------------------
  5917.  
  5918. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  5919. Subject: Re: (usr-tc) Anyone else have this problem?
  5920. Date: 03 Mar 1999 18:12:12 -0500 (EST)
  5921.  
  5922.  
  5923. On Tue, 2 Mar 1999, Carl Litt wrote:
  5924.  
  5925. > Is anyone else having trouble with their 3Com screwdriver?
  5926. > 
  5927. > When I enable the flat-head attachment, I have a lot of trouble
  5928. > getting it to work.  It keeps wanting to fall out off the handle.
  5929.  
  5930. I tried calling tech support about it, but I couldn't find the
  5931. thing's serial number and they refused to assist.
  5932.  
  5933. Do you have this problem with all of the attachments, or just one?
  5934. If it's all of them, I'd suspect clamp on the body...wrap with cloth
  5935. and give a good squeeze with a pair of pliers to close it up a little.
  5936. If it's just one, try wrapping a piece of electrical tape around the
  5937. mating surface of the attachment...stretching tape as necessary to
  5938. get the appropriate thickness. Of course, IANAH (I am not a handyman),
  5939. so be sure to consult with one before doing any of this.
  5940.  
  5941. > It also isn't compatable with all flat-head screws.
  5942.  
  5943. Ensure that you are using the appropriate flat-head attachment, as
  5944. there are many standards and defacto standards and even downright
  5945. non-standards in the industry.
  5946.  
  5947. Other than that, you can either wait until the Open Screwdriver
  5948. Proposed Format (OSPF) is supported, or go with another vendor.
  5949. Interestingly, there do exist 3rd party attachments which will
  5950. properly work with the 3com screwdriver handle; perchance you
  5951. have some laying around?
  5952.  
  5953. > I can only get a couple
  5954. > of turns on it before it falls out of the groove.
  5955.  
  5956. Not to offend, but for completeness it should be stated that the
  5957. above symptom could also be caused by excessive blood-alcohol content
  5958. of the operator. Contact your Human Resources department to see if
  5959. they have any programs which can assist. Also, if the spouse of the
  5960. operator reports a similar-sounding problem, it could indicate a more
  5961. pervasive situation within the operator (him|her)self. In either case,
  5962. the screwdriver is not at fault.
  5963.  
  5964. > I'm pretty fed up.  It's really tempting to go up to a nice
  5965. > Snap-On, but they're really pricey.
  5966.  
  5967. Personally, I'm a fan of Sears Craftsman. In the case of screwdrivers,
  5968. when the time comes that you must use it for a chisel and then find
  5969. out why you shouldn't, you can always take it back and tell 'em that
  5970. you're not satisfied and they'll give you another one. And if I catch
  5971. the guy in the hardware department on a slow night, he'll tell me
  5972. all I ever wanted to know about screwdrivers and how to use 'em...
  5973. FOR FREE!
  5974.  
  5975.  
  5976. Lon Stockton
  5977. MoonStar
  5978.  
  5979.  
  5980.  
  5981. -
  5982.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  5983.  with "unsubscribe usr-tc" in the body of the message.
  5984.  For information on digests or retrieving files and old messages send
  5985.  "help" to the same address.  Do not use quotes in your message.
  5986.  
  5987.  
  5988. -------------------------------------------------------------------------------
  5989.  
  5990. From: "Walt Gnann" <wgnann@islc.net>
  5991. Subject: (usr-tc) TCM troubleshooting guide
  5992. Date: 03 Mar 1999 19:36:17 -0500
  5993.  
  5994. I really like the performance monitor in TCM.  It displays a plethora of
  5995. information about modem performance and analog statistics.  That information
  5996. probably would help me in tech support if I knew what half of it meant.  Is
  5997. there a guide or reasonable explanation of what the information displayed
  5998. there means and how it can be used to troubleshoot modem issues?  The
  5999. information I most interested in is the Call and Analog Statistics and how
  6000. to best use them to trouble shoot modem connections.  Just a simple listing
  6001. of what each of the headings means, normal values, abnormal, etc. would be
  6002. quite helpful.  I know some of these are listed in the help section but the
  6003. information given is quite sparse.
  6004.  
  6005. Thanks.
  6006.  
  6007. Walt
  6008. Walter N. Gnann
  6009. ISLC, Manager
  6010. 843.770.1000
  6011. 843.770.1002 (fax)
  6012. wgnann@islc.net
  6013. http://www.islc.net
  6014. http://www.beaufortonline.com
  6015. http://www.beaufortcomputerclub.org
  6016.  
  6017.  
  6018.  
  6019. -
  6020.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6021.  with "unsubscribe usr-tc" in the body of the message.
  6022.  For information on digests or retrieving files and old messages send
  6023.  "help" to the same address.  Do not use quotes in your message.
  6024.  
  6025.  
  6026. -------------------------------------------------------------------------------
  6027.  
  6028. From: Mike Andrews <mandrews@termfrost.org>
  6029. Subject: Re: (usr-tc) 1.2.59-1
  6030. Date: 03 Mar 1999 21:13:49 -0500 (EST)
  6031.  
  6032. On Wed, 3 Mar 1999, Ronald E. Kushner wrote:
  6033.  
  6034. > > > That is the improper way to turn off V.42bis. When you reboot the card it
  6035. > > > will come back on even if you save the settings to NVRAM.
  6036. > > >
  6037. > > > You have to go into the HiPer ARC, type this in:
  6038. > > >
  6039. > > > SET INIT_SCRIPT USR_int COMMAND ATS0=0&K0
  6040. > > > SAVE ALL
  6041. > > >
  6042. > > > Otherwise the HiPer ARC will turn V.42bis back on when it inits the cards
  6043. > > > after they load their NVRAM settings.
  6044. > > 
  6045. > > You've gotta be kidding me... where's that documented?  The default string
  6046. > > is just ATS0X0... how does that turn v.42bis on?  If that's not it, what's
  6047. > > the mechanism for doing it?  I don't like things that go and spontaneously
  6048. > > change my modem settings behind my back from what I've set 'em all to...
  6049. > > 
  6050. > > Besides, doing it that way would turn it off on all the Quads I have (I
  6051. > > have some racks with both quads and dsp's), and v.42bis compression works
  6052. > > fine on the Quads and I'd rather not turn it off.  (In fact I'd rather not
  6053. > > have to turn it off on ANYTHING, but there seems to be a major bug here
  6054. > > even though nobody has acknowledged it...)
  6055. > 
  6056. > V.42bis does not work fine on the Quads. It's generally the client modems
  6057. > that are all screwed up, alot of Rockwell modems that date as far back as
  6058. > V.32bis will disconnect at unknown times when talking V.42bis to the Quads.
  6059. > I have disabled V.42bis, as far back as 1991 when we first started seeing
  6060. > those rockwell junk modems in the market with buggy V.42bis code.
  6061. > 
  6062. > Anyways, this ATS0=0&K0 not documented anywhere I could find. But after
  6063. > snooping around and making a few calls to 3Com I come to find out the HiPer
  6064. > ARC sends an init string to the modems when the modem card after it
  6065. > registers with the HARC. This init string is:
  6066. > 
  6067. > ATH0S0=0S72.0=1E0Q0V0&A0&K1&L0&N0&TX0S47.5=1S2=255
  6068.  
  6069. I would *love* to know where you found this string...!
  6070.  
  6071. I'm using a homebrew Perl script for checking modem settings (and chassis
  6072. settings for that matter) -- it essentially snmpwalks the whole NMC and
  6073. compares what it gets to a list of expected settings, and fixes (snmpset)
  6074. anything it finds out of whack.  Modem settings, DSP profiles, Dual PRI
  6075. settings, whatever...
  6076.  
  6077. Anyway, that string above explains a LOT of the weird things I've been
  6078. seeing with this utility -- values spontaneously changing themselves on
  6079. DSP's and such.  Looks like the values that were changing are the *exact*
  6080. ones set by that init string above.  (Well, and some trap settings that
  6081. still refuse to stick... but that's another story)  Knowing this sure
  6082. would have saved me a lot of grief.
  6083.  
  6084. This string gets sent to the modem before the init_string does, then?
  6085.  
  6086. So where do they bury this string at, can you edit it, and why don't they
  6087. document it? :)
  6088.  
  6089.  
  6090. I realize that v.42bis is badly broken on a lot of client modems,
  6091. especially old Rockwells, and even some Sportsters...  still, the DSP's
  6092. running 1.2.60 and 1.2.59 hang up on modems that are known to not be
  6093. buggy. (Unless Couriers are buggy and it's just coincidence that I've kept
  6094. Couriers connected at v.34 for over a month straight before...?)
  6095.  
  6096.  
  6097.  
  6098. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  6099. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  6100. getting beaten by the police, put down the video camera and come help me!"
  6101.  
  6102.  
  6103. -
  6104.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6105.  with "unsubscribe usr-tc" in the body of the message.
  6106.  For information on digests or retrieving files and old messages send
  6107.  "help" to the same address.  Do not use quotes in your message.
  6108.  
  6109.  
  6110. -------------------------------------------------------------------------------
  6111.  
  6112. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  6113. Subject: (usr-tc) Dynamic HARC inits
  6114. Date: 03 Mar 1999 22:05:23 -0500 (EST)
  6115.  
  6116.  
  6117. > >Y'know, I was thinking
  6118. > >that you could rig another telephone number to point to the head
  6119. > >of your hunt group. Then, you could rig your HDSP modem to configure
  6120. > >itself differently based on the called number. Easy enough so far,
  6121. > >right? The twist is that one of the configurations is an extremely
  6122. > >optimized configuration, so that people with the newest code and
  6123. > >the fancy modems can feel the power. The other config is one that
  6124. > >has all the fancy stuff off...like the compression that freaks out
  6125. > >all the winmodems and the like...a work-with-anything config. Then
  6126. > >you just put it in your setup info....'if you have trouble accessing
  6127. > >with the first number, try with the second yaddayadda'. I haven't
  6128. > >tried this yet, but it is apparently simple enough on the surface.
  6129. > >WDYT?]
  6130. > 
  6131. > Hrmm...interesting thought...I know the Arc can "authenticate" based on
  6132. > DNIS, so it could change the behavior of the port that way, though that
  6133. > doesn't take care of modem connect problems because the modems have
  6134. > already connected, or failed to connect by the time the Arc sees the
  6135. > DNIS I believe.  I'm unaware of any way to have the modem on the DSP
  6136. > reconfigure on the fly based on DNIS at this point, though I'm not
  6137. > extremely knowledgeable about them yet.  That would be pretty cool to
  6138. > do, but I think it would require some changes in the DSP's to do it (I
  6139. > would be happy to learn that I'm wrong).
  6140.  
  6141. I still haven't done it, but have looked around a little based on this
  6142. and another recent thread about how the inits work.
  6143.  
  6144. The thing I'm talking about is evidently configured on the 'DNIS Access
  6145. Codes' in the HDSP templates (in TCM, select the hdsp card, then hit
  6146. configure button, then pull up DNIS Access Codes....then look at help
  6147. for the items). Apparently, you can actually have up to four different
  6148. ones.
  6149.  
  6150. This init would be issued to the modem prior to it accepting the call
  6151. (but of course after the call hits the span). If everything works
  6152. as advertised *grin*, my aforementioned idea is apparently trivial.
  6153.  
  6154. Regarding the other thread here about init strings, the HARC does
  6155. indeed issue an init string to the modems after each call...perchance
  6156. this is y'all's problem.
  6157.  
  6158. Suggestion from an old bbser:  Standard procedure...put your highly
  6159. researched configuration in your modem. Flash the modem's config in
  6160. a stored profile, and make sure that you've set the modem to revert
  6161. to stored profile when it gets an ATZ.
  6162.  
  6163. Then set the HARC to issue a simple ATZ at the end of each call, and
  6164. rid yourself of the headache of having to remember to change modem
  6165. inits in HARC too.
  6166.  
  6167. I found the configuration of HARC's modem init string and the
  6168. documentation of same in a supiciously obvious place given the
  6169. amount surprise everyone is showing in finding out that it exists.
  6170.  
  6171. In HARM, click on the modem configuration tool (that's the one
  6172. with a picture of a modem as an icon, and it's the first thing
  6173. the window displays.
  6174.  
  6175. Lon Stockton
  6176. MoonStar
  6177.  
  6178.  
  6179.  
  6180. -
  6181.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6182.  with "unsubscribe usr-tc" in the body of the message.
  6183.  For information on digests or retrieving files and old messages send
  6184.  "help" to the same address.  Do not use quotes in your message.
  6185.  
  6186.  
  6187. -------------------------------------------------------------------------------
  6188.  
  6189. From: "Cassandra M. Perkins" <cassy@loop.com>
  6190. Subject: (usr-tc) MPIP Message
  6191. Date: 03 Mar 1999 21:10:38 -0800 (PST)
  6192.  
  6193. Ever since I've setup MPIP, my Netserver control server sends a
  6194. [MPIP_SERVER_PING_REQ] message to syslogd. I don't see any attempt to
  6195. establish a bundle service, so it is probably something I'm missing for
  6196. the configuration.  My Netserver cards have version 3.8.1. I've setup the
  6197. control server with three clients ( including itself ).  Any ideas what
  6198. this could be?
  6199.  
  6200. Thanks.
  6201.  
  6202. | Cassandra M. Perkins             | People usually get what's coming to |
  6203. | Network Operations             | them... unless it's been mailed.    |
  6204. | The Loop Internet Switch Co., LLC  |        -fortune           |
  6205.  
  6206.  
  6207. -
  6208.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6209.  with "unsubscribe usr-tc" in the body of the message.
  6210.  For information on digests or retrieving files and old messages send
  6211.  "help" to the same address.  Do not use quotes in your message.
  6212.  
  6213.  
  6214. -------------------------------------------------------------------------------
  6215.  
  6216. From: Jeff Mcadams <jeffm@iglou.com>
  6217. Subject: Re: (usr-tc) MPIP Message
  6218. Date: 04 Mar 1999 08:04:25 -0500 (EST)
  6219.  
  6220. Thus spake Cassandra M. Perkins
  6221. >Ever since I've setup MPIP, my Netserver control server sends a
  6222. >[MPIP_SERVER_PING_REQ] message to syslogd. I don't see any attempt to
  6223. >establish a bundle service, so it is probably something I'm missing for
  6224. >the configuration.  My Netserver cards have version 3.8.1. I've setup the
  6225. >control server with three clients ( including itself ).  Any ideas what
  6226. >this could be?
  6227.  
  6228. This is just the mechanism that MPIP servers use to confirm that other
  6229. MPIP servers and MPIP clients are still alive.  It sends these out
  6230. periodically just to make sure everything is still up and
  6231. running...nothing to be concerned about.
  6232. -- 
  6233. Jeff McAdams                            Email: jeffm@iglou.com
  6234. Head Network Administrator              Voice: (502) 966-3848
  6235. IgLou Internet Services                        (800) 436-4456
  6236.  
  6237. -
  6238.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6239.  with "unsubscribe usr-tc" in the body of the message.
  6240.  For information on digests or retrieving files and old messages send
  6241.  "help" to the same address.  Do not use quotes in your message.
  6242.  
  6243.  
  6244. -------------------------------------------------------------------------------
  6245.  
  6246. From: "Andres Kroonmaa" <andre@ml.ee>
  6247. Subject: (usr-tc) trapd.conf
  6248. Date: 04 Mar 1999 16:25:28 +0200 EET
  6249.  
  6250.  
  6251.  Hi,
  6252.  
  6253.  Can anybody send me some sane trapd.conf for HPOV unix that
  6254.  can be used to parse traps coming from TC?
  6255.  
  6256.  thanks,
  6257.  
  6258.  
  6259.  ----------------------------------------------------------------------
  6260.   Andres Kroonmaa                                mail: andre@online.ee
  6261.   Network Manager
  6262.   Organization:            MicroLink Online       Tel:        6308 909
  6263.   Tallinn, Sakala 19                              Pho:  +372  6308 909
  6264.   Estonia, EE0001        http://www.online.ee     Fax:  +372  6308 901
  6265.  ----------------------------------------------------------------------
  6266.  
  6267. -
  6268.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6269.  with "unsubscribe usr-tc" in the body of the message.
  6270.  For information on digests or retrieving files and old messages send
  6271.  "help" to the same address.  Do not use quotes in your message.
  6272.  
  6273.  
  6274. -------------------------------------------------------------------------------
  6275.  
  6276. From: Dale Hege <fhege@sover.net>
  6277. Subject: Re: (usr-tc) Port Density
  6278. Date: 04 Mar 1999 09:39:58 -0500 (EST)
  6279.  
  6280. Where can you get information about this? I called 3com and they didn't
  6281. know anything about the quad upgrade part.
  6282.  
  6283. -Dale
  6284.  
  6285. On Tue, 2 Mar 1999, Paul Jr. (AlaWeb Support) wrote:
  6286.  
  6287. > Just wondering if everyone has heard about 3com's latest bundle.  You can
  6288. > purchase the Double play bundle which is two DSP cards for 8,995.00 and also
  6289. > trade in 48 Quads for 2 extra DSP's for no extra money.
  6290. > 
  6291. > The price above is from my vendor.
  6292. > 
  6293. > I just thought this was a attractive offer and thought I would share it with
  6294. > everyone.
  6295. > 
  6296. > Thanks
  6297. > Paul JR.
  6298. > 
  6299. > 
  6300. >  Original Message -----
  6301. > From: Behrens, William <WBehrens@Paracom.com>
  6302. > To: <usr-tc@lists.xmission.com>
  6303. > Sent: Tuesday, March 02, 1999 10:30 AM
  6304. > Subject: RE: (usr-tc) Caveat Emptor
  6305. > 
  6306. > 
  6307. > >
  6308. > > Yes the Netserver code was licensed from Livingston (lucent). 3com's
  6309. > >position is the hardware in the netserver class NAS is legacy due to the
  6310. > >release of the HARC class NAS. Therefore they will no longer support the
  6311. > NAS
  6312. > >(in general) due to the inability to support the software and the release
  6313. > of
  6314. > >the new HARC. Features that do not work as advertised will not be fixed.
  6315. > The
  6316. > >standard reply is if you want "x" feature to work correctly then buy a
  6317. > HARC.
  6318. > >That's basically a load of shit.
  6319. > >
  6320. > > Supporting a particular platform for its lifespan is a cost of doing
  6321. > >business. If they (3com) had not been selling netserver class NAS's for a
  6322. > >couple of years I could maybe see the support drying up, but they were
  6323. > >selling this box (thru distributors) up in till the end of this last year.
  6324. > >That's not the customers problem, again a cost of doing business. Fix the
  6325. > >distributor pipeline (i.e. don't fill it with product you know you won't
  6326. > >support).
  6327. > >
  6328. > > For the most part people are pissed off due to 3com's desire for its
  6329. > >customers to pay for its poor business practices and lack of foresight. If
  6330. > >you purchased an automobile with an engine that was manufactured by a 3rd
  6331. > >party and 3 months later the OEM said "sorry we don't support your
  6332. > >automobile anymore because the engine is old, but you can buy this NEW
  6333. > >automobile to fix your problem" would you be pissed ? You bet your ass you
  6334. > >would. You would get an attorney and have a heyday with the auto maker in
  6335. > >question. There is an implied warranty. If you can prove the manufacturer
  6336. > >was not doing business with you in good faith at the time of purchase then
  6337. > >he would be held accountable for his actions in a court of law.
  6338. > >
  6339. > > These people who are "whining and moaning" have a legetament gripe.
  6340. > >They feel they have been screwed. Buying a NAS is not like buying a
  6341. > computer
  6342. > >or OS as an earlier poster had suggested. PC's don't cost 10K+ (at least
  6343. > not
  6344. > >desktops). I am not whining as my Netserver's are working for me and I
  6345. > don't
  6346. > >need the support for some of the software features, but this act buy 3com
  6347. > of
  6348. > >not supporting there customers in a "good faith" manner has made me think
  6349. > of
  6350. > >"fork lifting" my NAS's back to Lucent and PM4's.
  6351. > >
  6352. > >William Behrens
  6353. > >
  6354. > >>"Behrens, William" wrote:
  6355. > >
  6356. > >
  6357. > >>> I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting
  6358. > note
  6359. > >>> Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't 3com
  6360. > >>> support the netserver?
  6361. > >
  6362. > >>From what I've read, 3Com does not have access to the code that runs on
  6363. > the
  6364. > >>netserver anylonger.  Why this is, I have not seen posted other than the
  6365. > >>license ran out. Were they told it would cost some unrealistic number to
  6366. > >>relicense it, or are they just being cheap because now they have their own
  6367. > >>code?
  6368. > >
  6369. > >>Bitching and moaning will not help if the owners of the code are unwilling
  6370. > >>to relicense it. What's the real story?
  6371. > >
  6372. > >>-Ron
  6373. > >>GLISnet, Inc
  6374. > >>+1 810/939.9885
  6375. > >
  6376. > >
  6377. > >-
  6378. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6379. > > with "unsubscribe usr-tc" in the body of the message.
  6380. > > For information on digests or retrieving files and old messages send
  6381. > > "help" to the same address.  Do not use quotes in your message.
  6382. > >
  6383. > 
  6384. > 
  6385. > 
  6386. > 
  6387. > -
  6388. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6389. >  with "unsubscribe usr-tc" in the body of the message.
  6390. >  For information on digests or retrieving files and old messages send
  6391. >  "help" to the same address.  Do not use quotes in your message.
  6392. > 
  6393.  
  6394.  
  6395. -
  6396.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6397.  with "unsubscribe usr-tc" in the body of the message.
  6398.  For information on digests or retrieving files and old messages send
  6399.  "help" to the same address.  Do not use quotes in your message.
  6400.  
  6401.  
  6402. -------------------------------------------------------------------------------
  6403.  
  6404. From: "Jamie Orzechowski" <mhz@ripnet.com>
  6405. Subject: Re: (usr-tc) Port Density
  6406. Date: 04 Mar 1999 09:50:12 -0500
  6407.  
  6408. you sure that's not 12 Quads for 2 DSP's?? 48 quads = 192 ports
  6409.  
  6410. -----Original Message-----
  6411.  
  6412.  
  6413. >Where can you get information about this? I called 3com and they didn't
  6414. >know anything about the quad upgrade part.
  6415. >
  6416. >-Dale
  6417. >
  6418. >On Tue, 2 Mar 1999, Paul Jr. (AlaWeb Support) wrote:
  6419. >
  6420. >> Just wondering if everyone has heard about 3com's latest bundle.  You can
  6421. >> purchase the Double play bundle which is two DSP cards for 8,995.00 and
  6422. also
  6423. >> trade in 48 Quads for 2 extra DSP's for no extra money.
  6424. >>
  6425. >> The price above is from my vendor.
  6426. >>
  6427. >> I just thought this was a attractive offer and thought I would share it
  6428. with
  6429. >> everyone.
  6430. >>
  6431. >> Thanks
  6432. >> Paul JR.
  6433. >>
  6434. >>
  6435. >>  Original Message -----
  6436. >> From: Behrens, William <WBehrens@Paracom.com>
  6437. >> To: <usr-tc@lists.xmission.com>
  6438. >> Sent: Tuesday, March 02, 1999 10:30 AM
  6439. >> Subject: RE: (usr-tc) Caveat Emptor
  6440. >>
  6441. >>
  6442. >> >
  6443. >> > Yes the Netserver code was licensed from Livingston (lucent). 3com's
  6444. >> >position is the hardware in the netserver class NAS is legacy due to the
  6445. >> >release of the HARC class NAS. Therefore they will no longer support the
  6446. >> NAS
  6447. >> >(in general) due to the inability to support the software and the
  6448. release
  6449. >> of
  6450. >> >the new HARC. Features that do not work as advertised will not be fixed.
  6451. >> The
  6452. >> >standard reply is if you want "x" feature to work correctly then buy a
  6453. >> HARC.
  6454. >> >That's basically a load of shit.
  6455. >> >
  6456. >> > Supporting a particular platform for its lifespan is a cost of doing
  6457. >> >business. If they (3com) had not been selling netserver class NAS's for
  6458. a
  6459. >> >couple of years I could maybe see the support drying up, but they were
  6460. >> >selling this box (thru distributors) up in till the end of this last
  6461. year.
  6462. >> >That's not the customers problem, again a cost of doing business. Fix
  6463. the
  6464. >> >distributor pipeline (i.e. don't fill it with product you know you won't
  6465. >> >support).
  6466. >> >
  6467. >> > For the most part people are pissed off due to 3com's desire for its
  6468. >> >customers to pay for its poor business practices and lack of foresight.
  6469. If
  6470. >> >you purchased an automobile with an engine that was manufactured by a
  6471. 3rd
  6472. >> >party and 3 months later the OEM said "sorry we don't support your
  6473. >> >automobile anymore because the engine is old, but you can buy this NEW
  6474. >> >automobile to fix your problem" would you be pissed ? You bet your ass
  6475. you
  6476. >> >would. You would get an attorney and have a heyday with the auto maker
  6477. in
  6478. >> >question. There is an implied warranty. If you can prove the
  6479. manufacturer
  6480. >> >was not doing business with you in good faith at the time of purchase
  6481. then
  6482. >> >he would be held accountable for his actions in a court of law.
  6483. >> >
  6484. >> > These people who are "whining and moaning" have a legetament gripe.
  6485. >> >They feel they have been screwed. Buying a NAS is not like buying a
  6486. >> computer
  6487. >> >or OS as an earlier poster had suggested. PC's don't cost 10K+ (at least
  6488. >> not
  6489. >> >desktops). I am not whining as my Netserver's are working for me and I
  6490. >> don't
  6491. >> >need the support for some of the software features, but this act buy
  6492. 3com
  6493. >> of
  6494. >> >not supporting there customers in a "good faith" manner has made me
  6495. think
  6496. >> of
  6497. >> >"fork lifting" my NAS's back to Lucent and PM4's.
  6498. >> >
  6499. >> >William Behrens
  6500. >> >
  6501. >> >>"Behrens, William" wrote:
  6502. >> >
  6503. >> >
  6504. >> >>> I'm gonna buy PM4's (new dealer) and dump my netservers. Interesting
  6505. >> note
  6506. >> >>> Lucent still supports the PM2 (hmmmmm talk about legacy). Why can't
  6507. 3com
  6508. >> >>> support the netserver?
  6509. >> >
  6510. >> >>From what I've read, 3Com does not have access to the code that runs on
  6511. >> the
  6512. >> >>netserver anylonger.  Why this is, I have not seen posted other than
  6513. the
  6514. >> >>license ran out. Were they told it would cost some unrealistic number
  6515. to
  6516. >> >>relicense it, or are they just being cheap because now they have their
  6517. own
  6518. >> >>code?
  6519. >> >
  6520. >> >>Bitching and moaning will not help if the owners of the code are
  6521. unwilling
  6522. >> >>to relicense it. What's the real story?
  6523. >> >
  6524. >> >>-Ron
  6525. >> >>GLISnet, Inc
  6526. >> >>+1 810/939.9885
  6527. >> >
  6528. >> >
  6529. >> >-
  6530. >> > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6531. >> > with "unsubscribe usr-tc" in the body of the message.
  6532. >> > For information on digests or retrieving files and old messages send
  6533. >> > "help" to the same address.  Do not use quotes in your message.
  6534. >> >
  6535. >>
  6536. >>
  6537. >>
  6538. >>
  6539. >> -
  6540. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6541. >>  with "unsubscribe usr-tc" in the body of the message.
  6542. >>  For information on digests or retrieving files and old messages send
  6543. >>  "help" to the same address.  Do not use quotes in your message.
  6544. >>
  6545. >
  6546. >
  6547. >-
  6548. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6549. > with "unsubscribe usr-tc" in the body of the message.
  6550. > For information on digests or retrieving files and old messages send
  6551. > "help" to the same address.  Do not use quotes in your message.
  6552. >
  6553. >
  6554.  
  6555.  
  6556. -
  6557.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6558.  with "unsubscribe usr-tc" in the body of the message.
  6559.  For information on digests or retrieving files and old messages send
  6560.  "help" to the same address.  Do not use quotes in your message.
  6561.  
  6562.  
  6563. -------------------------------------------------------------------------------
  6564.  
  6565. From: Richard Stuplich <dick@dwave.net>
  6566. Subject: (usr-tc) Q. Idle (Exactly)
  6567. Date: 04 Mar 1999 09:05:09 -0600
  6568.  
  6569. Is this how it is done?
  6570.  
  6571. set user default IDLE_TIMEOUT nnn
  6572.  
  6573. Is the 'nnn' in minutes or seconds?
  6574.  
  6575.  
  6576. -
  6577.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6578.  with "unsubscribe usr-tc" in the body of the message.
  6579.  For information on digests or retrieving files and old messages send
  6580.  "help" to the same address.  Do not use quotes in your message.
  6581.  
  6582.  
  6583. -------------------------------------------------------------------------------
  6584.  
  6585. From: Charles Sprickman <spork@inch.com>
  6586. Subject: Re: (usr-tc) Q. Idle (Exactly)
  6587. Date: 04 Mar 1999 10:56:40 -0500 (EST)
  6588.  
  6589. On Thu, 4 Mar 1999, Richard Stuplich wrote:
  6590.  
  6591. > Is this how it is done?
  6592. > 
  6593. > set user default IDLE_TIMEOUT nnn
  6594. > 
  6595. > Is the 'nnn' in minutes or seconds?
  6596.  
  6597. According to the ARC at least:
  6598.  
  6599. HiPer-1>> set useR default idLE_TIMEOUT ?
  6600. This field the number of seconds within a Range
  6601.         The valid range is 0-86400                  
  6602.  
  6603. Charles
  6604.  
  6605. > 
  6606. > 
  6607. > -
  6608. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6609. >  with "unsubscribe usr-tc" in the body of the message.
  6610. >  For information on digests or retrieving files and old messages send
  6611. >  "help" to the same address.  Do not use quotes in your message.
  6612. > 
  6613.  
  6614.  
  6615. -
  6616.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6617.  with "unsubscribe usr-tc" in the body of the message.
  6618.  For information on digests or retrieving files and old messages send
  6619.  "help" to the same address.  Do not use quotes in your message.
  6620.  
  6621.  
  6622. -------------------------------------------------------------------------------
  6623.  
  6624. From: Jeff Mcadams <jeffm@iglou.com>
  6625. Subject: Re: (usr-tc) Dynamic HARC inits
  6626. Date: 04 Mar 1999 11:22:48 -0500 (EST)
  6627.  
  6628. Thus spake Lon R. Stockton, Jr.
  6629. >> Hrmm...interesting thought...I know the Arc can "authenticate" based on
  6630. >> DNIS, so it could change the behavior of the port that way, though that
  6631. >> doesn't take care of modem connect problems because the modems have
  6632. >> already connected, or failed to connect by the time the Arc sees the
  6633. >> DNIS I believe.  I'm unaware of any way to have the modem on the DSP
  6634. >> reconfigure on the fly based on DNIS at this point, though I'm not
  6635. >> extremely knowledgeable about them yet.  That would be pretty cool to
  6636. >> do, but I think it would require some changes in the DSP's to do it (I
  6637. >> would be happy to learn that I'm wrong).
  6638.  
  6639. >I still haven't done it, but have looked around a little based on this
  6640. >and another recent thread about how the inits work.
  6641.  
  6642. >The thing I'm talking about is evidently configured on the 'DNIS Access
  6643. >Codes' in the HDSP templates (in TCM, select the hdsp card, then hit
  6644. >configure button, then pull up DNIS Access Codes....then look at help
  6645. >for the items). Apparently, you can actually have up to four different
  6646. >ones.
  6647.  
  6648. Well...that's cool...like i said, I would be happy to learn that I'm
  6649. wrong, and apparently I am.  :)  When we actually get enough DSP's where
  6650. this might be an actual help to us, I'll definitely check it out.
  6651.  
  6652. >This init would be issued to the modem prior to it accepting the call
  6653. >(but of course after the call hits the span). If everything works
  6654. >as advertised *grin*, my aforementioned idea is apparently trivial.
  6655.  
  6656. Heh...big "if" there of course.  :)
  6657.  
  6658. >I found the configuration of HARC's modem init string and the
  6659. >documentation of same in a supiciously obvious place given the
  6660. >amount surprise everyone is showing in finding out that it exists.
  6661.  
  6662. Yup...even in the CLI, I noticed it without even looking for it.  Didn't
  6663. look and find out what the init string it was sending was, but I did
  6664. notice that the Arc had the capability (and looks like it was doing so
  6665. by default) to send an init string to the modem...*shrug*.
  6666. -- 
  6667. Jeff McAdams                            Email: jeffm@iglou.com
  6668. Head Network Administrator              Voice: (502) 966-3848
  6669. IgLou Internet Services                        (800) 436-4456
  6670.  
  6671. -
  6672.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6673.  with "unsubscribe usr-tc" in the body of the message.
  6674.  For information on digests or retrieving files and old messages send
  6675.  "help" to the same address.  Do not use quotes in your message.
  6676.  
  6677.  
  6678. -------------------------------------------------------------------------------
  6679.  
  6680. From: Steve Johnson <linuxnut@sonic.net>
  6681. Subject: (usr-tc) Version Info and Latest Code
  6682. Date: 04 Mar 1999 10:42:26 -0800 (PST)
  6683.  
  6684.  
  6685.  
  6686. Can some one point me in the direction on where to get the version info on
  6687. my HyperArc adn DSP cards?  Also what is the latest release of the code?
  6688. Is it stable?  What is the most stable version at this time,what one are
  6689. you guys happy with?
  6690.  
  6691. -Steve
  6692.  
  6693. ---- 
  6694. Steve Johnson                            Sonic.net, Inc.
  6695. (707)522-1001 (33.6kbps)                (707)522-1000 (Voice)
  6696. mailto:support@sonic.net                http://www.sonic.net
  6697. ----
  6698.       "Knowing others is wisdom, knowing your self is Enlightenment."
  6699.                                                    -- Lao-Tzu
  6700.  
  6701.  
  6702.  
  6703.  
  6704. -
  6705.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6706.  with "unsubscribe usr-tc" in the body of the message.
  6707.  For information on digests or retrieving files and old messages send
  6708.  "help" to the same address.  Do not use quotes in your message.
  6709.  
  6710.  
  6711. -------------------------------------------------------------------------------
  6712.  
  6713. From: "David Cartwright" <David_Cartwright@mw.3com.com>
  6714. Subject: (usr-tc) What is the Newest V90 Code????
  6715. Date: 04 Mar 1999 14:18:11 -0600
  6716.  
  6717.  
  6718.  
  6719. The issue of 3Com's version numbering system has come up on occasion.  Mr.
  6720. McAdams was right on with his note (copied here).  I've just added a little more
  6721. information to his answer.
  6722.  
  6723. Thus spake Paul M. Oster
  6724. >  Maybe someone from 3com can spell this out in REALLY simple english for
  6725. >those of us that still dont see it... I've always been confused by this
  6726. >numbering, but just went by the dates... now I'm curious :)
  6727.  
  6728. For basic releases, the third number goes up, but emergency and service
  6729. releases number them down from the top.
  6730.  
  6731. So, you'll have the regular release (using the HiPer Arc's as an
  6732. example) that start with 4.1.1, 4.1.2, 4.1.3, and eventually in this
  6733. series, got released as 4.1.11.  ER's and SR's start with 4.1.99,
  6734. 4.1.98, 4.1.97, etc.  Having SR's come out in this case at 4.1.72 and
  6735. 4.1.59.
  6736. --
  6737. Jeff McAdams                            Email: jeffm@iglou.com
  6738. Head Network Administrator              Voice: (502) 966-3848
  6739. IgLou Internet Services                        (800) 436-4456
  6740.  
  6741. Thanks
  6742.  
  6743. Dave
  6744. ---------------------- Forwarded by David Cartwright/MW/US/3Com on 03/04/99
  6745. 02:06 PM ---------------------------
  6746.  
  6747.  
  6748. Dave at 3Com <dave@totalservice.usr.com> on 03/04/99 01:53:09 PM
  6749.  
  6750. Please respond to Dave at 3Com <dave@totalservice.usr.com>
  6751.  
  6752. cc:    (David Cartwright/MW/US/3Com)
  6753.  
  6754.  
  6755.  
  6756.  
  6757.  
  6758. To further clarify, code releases have an XX.YY.ZZ version label.  XX.YY
  6759. represents the version of code.  The .ZZ is unique for each code release.
  6760.  
  6761. For regular releases the .ZZ increments, such as 4.1.1, 4.1.2, 4.1.3, and so on.
  6762.  
  6763. For Emergency and Service Releases, the .ZZ starts at 99 and decrements as
  6764. additional releases are required.  If multiple releases are required for one
  6765. feature/MR, then XX.YY.ZZ.CC or XX.YY.ZZ-CC is used.  For example, the HiPer ARC
  6766. service released posted on the Total Control web site is version number 4.1.59-1
  6767.  
  6768. 3Com Customer Support
  6769.  
  6770. 3Com Technician wrote:
  6771.  
  6772. > Released code will move in ascending order however, when an ER or Service
  6773. > Release comes out, such as 4.1.59, the code numbers move in descending order.
  6774. >
  6775. > 3Com Carrier Support
  6776. >
  6777. > > ME wrote in message <7bhplb$lrr$1@tempest.nsd.usr.com>...
  6778. > > >I need to know if what is the newest v90 code for the HiperArc Modems. I
  6779. > > >have been using the 4.1.72 and I see that on the USR site 4.1.59 is newer
  6780. > > >and supposed to be built from 4.1.72????
  6781. > > >Is this correct, an older version number is newer????
  6782. > > >
  6783. > > >--
  6784. > > >Bill Somers
  6785. > > >InterDomain Net Services, Inc.
  6786. > > >
  6787.  
  6788.  
  6789.  
  6790.  
  6791.  
  6792. To Subscribe/Unsubscribe to/from the 3Com Carrier User-Forums -
  6793. http://totalservice.3com.com/forums/
  6794. To access the 3Com Knowledgebase - http://knowledgebase.3com.com
  6795. To access 3Com Carrier documentation - http://totalservice.3com.com/documents/
  6796. To view 3Com Carrier Service Offerings - http://totalservice.3com.com/services/
  6797.  
  6798.  
  6799.  
  6800.  
  6801.  
  6802.  
  6803. -
  6804.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6805.  with "unsubscribe usr-tc" in the body of the message.
  6806.  For information on digests or retrieving files and old messages send
  6807.  "help" to the same address.  Do not use quotes in your message.
  6808.  
  6809.  
  6810. -------------------------------------------------------------------------------
  6811.  
  6812. From: David Bolen <db3l@ans.net>
  6813. Subject: Re: (usr-tc) What is the Newest V90 Code????
  6814. Date: 04 Mar 1999 15:34:33 EST
  6815.  
  6816. "David Cartwright" <David_Cartwright@mw.3com.com> writes:
  6817.  
  6818. > For Emergency and Service Releases, the .ZZ starts at 99 and
  6819. > decrements as additional releases are required.  If multiple
  6820. > releases are required for one feature/MR, then XX.YY.ZZ.CC or
  6821. > XX.YY.ZZ-CC is used.  For example, the HiPer ARC service released
  6822. > posted on the Total Control web site is version number 4.1.59-1
  6823.  
  6824. It's not entirely clear if you're saying that publically released
  6825. versions may differ in the "CC" scheme (I was under the impression
  6826. that didn't happen), or just that the currently released version of
  6827. 4.1.59 is the only one so CC is implicitly "-1", and for any given
  6828. public release there will only be one "CC" value.
  6829.  
  6830. But in case there's any suggestion that, for example, a 4.1.59-x might
  6831. also make it out where x isn't "1", for my 2 cents, letting different
  6832. XX.YY.ZZ-CC releases out of the lab is ludicrous, because there is no
  6833. way (other than for example console commands) to query that version
  6834. information via standard management tools through the NMC, and thus no
  6835. way via such tools to verify what revision of code you have installed.
  6836.  
  6837. I can sort of understand why internal R&D revs of code that are
  6838. anticipated to deliver an ER or SR might use that extra level of
  6839. numbering to help avoid burning the number space, but a unique number
  6840. within the XX.YY.ZZ range should always be assigned before that code
  6841. leaves the lab.  The "-CC" shouldn't be necessary to disambiguate
  6842. generally available code releases.
  6843.  
  6844. Either that, or the standard TC management interfaces (in particular,
  6845. SNMP via the NMC) need to be augmented to be able to return all of the
  6846. version information.
  6847.  
  6848. -- David
  6849.  
  6850. /-----------------------------------------------------------------------\
  6851.  \               David Bolen              \  Internet: db3l@ans.net    /
  6852.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  6853.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  6854. \-----------------------------------------------------------------------/
  6855.  
  6856. -
  6857.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6858.  with "unsubscribe usr-tc" in the body of the message.
  6859.  For information on digests or retrieving files and old messages send
  6860.  "help" to the same address.  Do not use quotes in your message.
  6861.  
  6862.  
  6863. -------------------------------------------------------------------------------
  6864.  
  6865. From: "Andres Kroonmaa" <andre@ml.ee>
  6866. Subject: Re: (usr-tc) Acct-Session-Time problem
  6867. Date: 04 Mar 1999 22:59:46 +0200 EET
  6868.  
  6869. On 3 Mar 99, at 17:04, Carl Ansley <usr-tc@lists.xmission.com> wrote:
  6870.  
  6871. > (i.e. charge users) based on this information.  We're running 4.1.11.
  6872. > 
  6873. > example:
  6874. > 
  6875. >         User-Name = "joebloggs"
  6876. >         Framed-Protocol = PPP
  6877. >         Framed-IP-Address = x.x.x.x
  6878. >         Acct-Session-Time = -85082   <----
  6879. >         Acct-Terminate-Cause = User-Request
  6880. > 
  6881. > We see this on both ISDN and analogue calls.  Is this a bug/feature anyone
  6882. > else has seen?
  6883.  
  6884.  I've seen extremely interesting acct times when you change the time of day
  6885.  of the ARC. It may look especially interesting when you change the time
  6886.  from default of its epoh to current time, and then find that some of your
  6887.  users have been online for 30 years or so... Or, been idle for few years ;)
  6888.  cute, isn't it.
  6889.  
  6890.  
  6891.  
  6892.  ----------------------------------------------------------------------
  6893.   Andres Kroonmaa                                mail: andre@online.ee
  6894.   Network Manager
  6895.   Organization:            MicroLink Online       Tel:        6308 909
  6896.   Tallinn, Sakala 19                              Pho:  +372  6308 909
  6897.   Estonia, EE0001        http://www.online.ee     Fax:  +372  6308 901
  6898.  ----------------------------------------------------------------------
  6899.  
  6900. -
  6901.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6902.  with "unsubscribe usr-tc" in the body of the message.
  6903.  For information on digests or retrieving files and old messages send
  6904.  "help" to the same address.  Do not use quotes in your message.
  6905.  
  6906.  
  6907. -------------------------------------------------------------------------------
  6908.  
  6909. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  6910. Subject: RE: (usr-tc) What is the Newest V90 Code????
  6911. Date: 04 Mar 1999 15:12:48 -0600
  6912.  
  6913.  
  6914.  
  6915. |-----Original Message-----
  6916. |From: owner-usr-tc@lists.xmission.com
  6917. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Bolen
  6918. |Sent: Thursday, March 04, 1999 2:35 PM
  6919. |To: usr-tc@lists.xmission.com
  6920. |Subject: Re: (usr-tc) What is the Newest V90 Code????
  6921. |
  6922. |
  6923. |"David Cartwright" <David_Cartwright@mw.3com.com> writes:
  6924. |
  6925. |> For Emergency and Service Releases, the .ZZ starts at 99 and
  6926. |> decrements as additional releases are required.  If multiple
  6927. |> releases are required for one feature/MR, then XX.YY.ZZ.CC or
  6928. |> XX.YY.ZZ-CC is used.  For example, the HiPer ARC service released
  6929. |> posted on the Total Control web site is version number 4.1.59-1
  6930. |
  6931. |It's not entirely clear if you're saying that publically released
  6932. |versions may differ in the "CC" scheme (I was under the impression
  6933. |that didn't happen), or just that the currently released version of
  6934. |4.1.59 is the only one so CC is implicitly "-1", and for any given
  6935. |public release there will only be one "CC" value.
  6936. |
  6937. |But in case there's any suggestion that, for example, a 4.1.59-x might
  6938. |also make it out where x isn't "1", for my 2 cents, letting different
  6939. |XX.YY.ZZ-CC releases out of the lab is ludicrous, because there is no
  6940. |way (other than for example console commands) to query that version
  6941. |information via standard management tools through the NMC, and thus no
  6942. |way via such tools to verify what revision of code you have installed.
  6943. |
  6944. |I can sort of understand why internal R&D revs of code that are
  6945. |anticipated to deliver an ER or SR might use that extra level of
  6946. |numbering to help avoid burning the number space, but a unique number
  6947. |within the XX.YY.ZZ range should always be assigned before that code
  6948. |leaves the lab.  The "-CC" shouldn't be necessary to disambiguate
  6949. |generally available code releases.
  6950. |
  6951. |Either that, or the standard TC management interfaces (in particular,
  6952. |SNMP via the NMC) need to be augmented to be able to return all of the
  6953. |version information.
  6954. |
  6955.  
  6956. Unfortunately this is not the case.. There are multiple ERs/SRs that only differ
  6957. in the CC number in circulation. And yes at this time the only way to tell is
  6958. with the "_show version" console command. The management tools are not able to
  6959. get this information.  This should be corrected soon to allow the query of build
  6960. number via SNMP since this practice will continue for future releases.
  6961.  
  6962. -M
  6963.  
  6964.  
  6965. -
  6966.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6967.  with "unsubscribe usr-tc" in the body of the message.
  6968.  For information on digests or retrieving files and old messages send
  6969.  "help" to the same address.  Do not use quotes in your message.
  6970.  
  6971.  
  6972. -------------------------------------------------------------------------------
  6973.  
  6974. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  6975. Subject: (usr-tc) HiPerARC code for Webramp/Macintosh and related issues. (4.1.59-6)
  6976. Date: 04 Mar 1999 17:32:28 -0600
  6977.  
  6978. A service release of HiPerARC has been posted to the Totalservice website. It
  6979. addresses the Webramp/Mac issues as well as some other ISDN TA's.  Please
  6980. carefully "READ THE RELEASE NOTES" so you know how to verify the HARC
  6981. configuration to resolve these problems. A blind upgrade will without some
  6982. configuring may NOT resolve the issues.
  6983.  
  6984. HARC 4.1.59-6
  6985. ftp://mwronski:qwerty@totalservice.usr.com/pub/.files/ne040159_6.zip
  6986. Release Notes ftp://totalservice.usr.com/pub/.docs/040159_6.pdf
  6987.  
  6988. This code will does not require a service contract to download.
  6989.  
  6990. Mike Wronski (mike@coredump.ae.usr.com)
  6991. Rogue 3Com Network Systems Engineer / BETA Engineer
  6992. PGP:http://coredump.ae.usr.com/pgp iCQ:15796141
  6993. "If at first you do succeed, try not to look astonished."
  6994.  
  6995.  
  6996. -
  6997.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  6998.  with "unsubscribe usr-tc" in the body of the message.
  6999.  For information on digests or retrieving files and old messages send
  7000.  "help" to the same address.  Do not use quotes in your message.
  7001.  
  7002.  
  7003. -------------------------------------------------------------------------------
  7004.  
  7005. From: "Matthew E. Pearson" <mpearson@tiac.net>
  7006. Subject: RE: (usr-tc) Port Density
  7007. Date: 05 Mar 1999 10:53:22 -0500
  7008.  
  7009. Several of us have been beating up on 3com about a rational upgrade program
  7010. from Quads to DSPs. I am told nothing is final yet but they are very near
  7011. finishing the promotion details and allowing people to use it.
  7012.  
  7013. But it will be something like "buy two DSP, turn in 12 quad and get two more
  7014. DSP free (or 1/2 price or something). To put some value on all those quad
  7015. cards most of us have kicking around.
  7016.  
  7017.  
  7018.  
  7019. -
  7020.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7021.  with "unsubscribe usr-tc" in the body of the message.
  7022.  For information on digests or retrieving files and old messages send
  7023.  "help" to the same address.  Do not use quotes in your message.
  7024.  
  7025.  
  7026. -------------------------------------------------------------------------------
  7027.  
  7028. From: "Randy Cosby" <dcosby@infowest.com>
  7029. Subject: RE: (usr-tc) Port Density
  7030. Date: 05 Mar 1999 10:18:59 -0700
  7031.  
  7032. This appears to be a done deal.  See
  7033. http://www.3com.com/promotions/hipertrade
  7034.  
  7035. You have to buy a "Double Play" kit with 2 DSP's and the netserver memory
  7036. upgrade, then you send in your quads  (6 or 12).  They send you one or two
  7037. DSP's.  For a growing ISP, this seems like a good deal.
  7038.  
  7039. Randy Cosby
  7040. InfoWest, Inc.
  7041.  
  7042.  
  7043.  
  7044. > -----Original Message-----
  7045. > From: owner-usr-tc@lists.xmission.com
  7046. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Matthew E. Pearson
  7047. > Sent: Friday, March 05, 1999 8:53 AM
  7048. > To: usr-tc@lists.xmission.com
  7049. > Subject: RE: (usr-tc) Port Density
  7050. >
  7051. >
  7052. > Several of us have been beating up on 3com about a rational
  7053. > upgrade program
  7054. > from Quads to DSPs. I am told nothing is final yet but they are very near
  7055. > finishing the promotion details and allowing people to use it.
  7056. >
  7057. > But it will be something like "buy two DSP, turn in 12 quad and
  7058. > get two more
  7059. > DSP free (or 1/2 price or something). To put some value on all those quad
  7060. > cards most of us have kicking around.
  7061. >
  7062. >
  7063. >
  7064. > -
  7065. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7066. >  with "unsubscribe usr-tc" in the body of the message.
  7067. >  For information on digests or retrieving files and old messages send
  7068. >  "help" to the same address.  Do not use quotes in your message.
  7069. >
  7070.  
  7071.  
  7072. -
  7073.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7074.  with "unsubscribe usr-tc" in the body of the message.
  7075.  For information on digests or retrieving files and old messages send
  7076.  "help" to the same address.  Do not use quotes in your message.
  7077.  
  7078.  
  7079. -------------------------------------------------------------------------------
  7080.  
  7081. From: "George Ebert" <George_Ebert@mw.3com.com>
  7082. Subject: Re: (usr-tc) 3Com Problems.
  7083. Date: 04 Mar 1999 12:26:45 -0600
  7084.  
  7085.  
  7086.  
  7087. OSPF should be part of TCS 3.5 release. I believe this is already in Beta..
  7088.  
  7089. George Ebert
  7090. Network Consultant - Midwest
  7091. 847-262-1229
  7092.  
  7093.  
  7094.  
  7095.  
  7096.  
  7097.  
  7098. Allen Marsalis <am@shreve.net> on 02/28/99 02:40:13 AM
  7099.  
  7100. cc:   dean@iglou.com , dboyer@commnet.com, Thomas Goodman/MW/US/3Com@3Com, Glenn
  7101.       Gibney/MW/US/3Com@3COM, George Ebert/MW/US/3Com@3Com
  7102.  
  7103.  
  7104.  
  7105.  
  7106. At 12:36 PM 2/26/99 -0500, Jeff Mcadams wrote:
  7107.  
  7108. >Primarily, I believe 3Com should ditch this "revenue positive" attitude
  7109. >that they seem to have.  This attitude seems to be pervasive throughout
  7110. >all of 3Com.  The result of this attitude is that 3Com ends up screwing
  7111. >their longest and most loyal customers.  Customers such as us that have
  7112. >had USR/3Com gear for years have to pay more money to keep our equipment
  7113. >up to date and to work around bugs that 3Com was unable to fix, and
  7114. >their poor planning in not having an upgrade path available for the
  7115. >older equipment.  We have a large number of NETServer cards, and the
  7116. >only three options that we have are to throw that investment into the
  7117. >trash, try to sell these things used which throws most of our investment
  7118. >into the trash, or send them back to 3Com for a $3200 rebate on new
  7119. >purchases, which still throws a significant investment into the trash.
  7120. >
  7121.  
  7122. How about this idea Jeff..  Purchase the upgrade, send in your netserver
  7123. for the rebate, then sell off the HDM..  Since standalone HDM's are not
  7124. cheap, I bet you could the the "free" upgrade you desire albeit with a
  7125. little leg work...
  7126.  
  7127. I know I'd be happy to pay $3200 ea for HDM's..  We now have a dozen or
  7128. more chassis stripped of HDM's..  I'd really like to just purchase HDM's
  7129. and I'd even be willing to swap an ARC or two for HDM's..
  7130.  
  7131. When it comes to USR upgrades, you just have to be a little inventive
  7132. and imaginative..  and a little compromising...  I was able to upgrade
  7133. all our netservers to arcs one year ago without too much pain, and there
  7134. was NO upgrade path at all at that time..  Sure we had to hustle a little,
  7135. but it sure was worth it to get rid of Quake lag, broke MPIP, etc..  I
  7136. really don't care which direction the relief comes from as long as
  7137. it gets there..  :)
  7138.  
  7139. I really fought hard for that upgrade path Jeff, and I didn't even get
  7140. to take advantage of it myself..  It just hurts a little to see someone
  7141. less happy and yet better positioned to fix the problem than we were..
  7142. And if the energy spent banging heads with 3COM corporate types is less
  7143. than that spent to really *solve the problem*, I'd be surprised..  Not
  7144. that I'm against matters of principle, it's just my principles are
  7145. tempered by an overall lack of time and energy I guess..
  7146.  
  7147. However good luck in your quest, and you really have a good rep (Tom)
  7148. on your side.  Tom really does care, follow though, and will "go to bat"
  7149. for his customers..
  7150.  
  7151. <dredging up old memories>
  7152.  
  7153. Speaking of promises though, whatever happened to OSPF?  not on the
  7154. netserver (I'm not completely stupid) but on the ARC?  Think we might
  7155. see it this year?  (or have I just been out of the loop too long)  It
  7156. sure would be nice to use a decent interior routing protocol besides
  7157. RIP...
  7158.  
  7159. Allen
  7160.  
  7161. -
  7162.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7163.  with "unsubscribe usr-tc" in the body of the message.
  7164.  For information on digests or retrieving files and old messages send
  7165.  "help" to the same address.  Do not use quotes in your message.
  7166.  
  7167.  
  7168. -------------------------------------------------------------------------------
  7169.  
  7170. From: Pete Ashdown <pashdown@xmission.com>
  7171. Subject: Re: (usr-tc) HiPerARC code for Webramp/Macintosh and related issues. (4.1.59-6)
  7172. Date: 05 Mar 1999 12:30:13 -0700 (MST)
  7173.  
  7174. Mike Wronski said once upon a time:
  7175. >
  7176. >A service release of HiPerARC has been posted to the Totalservice website. It
  7177. >addresses the Webramp/Mac issues as well as some other ISDN TA's.  Please
  7178. >carefully "READ THE RELEASE NOTES" so you know how to verify the HARC
  7179. >configuration to resolve these problems. A blind upgrade will without some
  7180. >configuring may NOT resolve the issues.
  7181.  
  7182. I was interested to see that MPPP now has a global switch.  What is the
  7183. proper Framed-Protocol to use for MPPP?  I have a customer who is
  7184. connecting with Linux MPPP and the second connection always gets dropped
  7185. upon authentication.  The global switch for MPPP is on, but this is the
  7186. result.  Currently, I'm using PPP for the connection, I can't appear to
  7187. find the proper value for the dictionary for the ARC to recognize MPPP.
  7188.  
  7189. As an interesting side note, this connection worked flawlessly on a
  7190. Netserver.
  7191.  
  7192. -
  7193.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7194.  with "unsubscribe usr-tc" in the body of the message.
  7195.  For information on digests or retrieving files and old messages send
  7196.  "help" to the same address.  Do not use quotes in your message.
  7197.  
  7198.  
  7199. -------------------------------------------------------------------------------
  7200.  
  7201. From: <vanhalen@coredcs.com>
  7202. Subject: (usr-tc) Netserver 16 Question
  7203. Date: 05 Mar 1999 15:43:54 -0600 (CST)
  7204.  
  7205. Hello-
  7206.  
  7207. We have an old Netserver 16 that we use for some dedicated line people for
  7208. their low traffic mail servers.  I need to get into the box to change the
  7209. IP information.  I have the password for the box and can telnet into it
  7210. from any other host on the internet.  However in order to change the ip
  7211. info I would like to have the console available.
  7212.  
  7213. I can't get the console to let me in and I'm at wit's end on it.  Below is
  7214. the config for s0.  If I try to !root into it from the console it never
  7215. asks for a password.  If I root into the console the password attempt
  7216. shows up in our logfiles.  I'm just lost on it.  Any help is appreciated.
  7217. If you need more info, please let me know.
  7218.  
  7219. I've tried changing the port type for s0 to network hardwired to no avail.
  7220. The cable I'm using works on our reg TC chassis with Netservers and
  7221. Hipers.
  7222.  
  7223. Steve
  7224.  
  7225.  
  7226.  
  7227. ----------------------- Current Status - Port S0 ---------------------------
  7228.         Status: USERNAME
  7229.          Input: 41                       Parity Errors:  0
  7230.         Output: 1134                    Framing Errors:  0
  7231.        Pending: 0                       Overrun Errors:  0
  7232.  
  7233.                 Active Configuration    Default Configuration  (* = Host
  7234.                 --------------------    ---------------------   Can
  7235. Override)
  7236.      Port Type: Login                   Login
  7237.  Login Service: Telnet                  Telnet
  7238.     Baud Rates: 9600                    9600,9600,9600
  7239.       Databits: 8                       8
  7240.       Stopbits: 1                       1
  7241.         Parity: none                    none
  7242.   Flow Control: None                    None
  7243.  Modem Control: off                     off
  7244.    Init Script: (None)
  7245.     Init When?: Never
  7246.          Hosts:                         default                              
  7247.  Terminal Type: vt100
  7248.   Login Prompt: login:
  7249.   Idle Timeout: 20 min 0 sec
  7250.  Login Message:
  7251. login:
  7252. }
  7253.  
  7254. Welcome to CORE Digital
  7255.  
  7256.  
  7257. -
  7258.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7259.  with "unsubscribe usr-tc" in the body of the message.
  7260.  For information on digests or retrieving files and old messages send
  7261.  "help" to the same address.  Do not use quotes in your message.
  7262.  
  7263.  
  7264. -------------------------------------------------------------------------------
  7265.  
  7266. From: jeff.binkley@asacomp.com (Jeff Binkley)
  7267. Subject: (usr-tc) New Code ?
  7268. Date: 05 Mar 1999 17:25:00 -0500
  7269.  
  7270.  
  7271. What happened to the new HiPerArc ER code which fixes the Webramp and
  7272. Mac connect problems ?  I just checked and it was on the TotalService
  7273. site yesterday but now it's gone.
  7274.  
  7275. Jeff Binkley
  7276. ASA Network Computing
  7277.  
  7278. -
  7279.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7280.  with "unsubscribe usr-tc" in the body of the message.
  7281.  For information on digests or retrieving files and old messages send
  7282.  "help" to the same address.  Do not use quotes in your message.
  7283.  
  7284.  
  7285. -------------------------------------------------------------------------------
  7286.  
  7287. From: <sagarwal@crash.ae.usr.com>
  7288. Subject: Re: (usr-tc) New Code ?
  7289. Date: 05 Mar 1999 16:45:25 -0600 (CST)
  7290.  
  7291. The ER code is in Totalservice. Check in software Library and search for
  7292. Hiper ARc. The  code ver is 4.1.59-6
  7293.  
  7294. Regards
  7295.  
  7296. Sanjay Agarwal
  7297.  
  7298. On Fri, 5 Mar 1999, Jeff Binkley wrote:
  7299.  
  7300. > 
  7301. > What happened to the new HiPerArc ER code which fixes the Webramp and
  7302. > Mac connect problems ?  I just checked and it was on the TotalService
  7303. > site yesterday but now it's gone.
  7304. > 
  7305. > Jeff Binkley
  7306. > ASA Network Computing
  7307. > 
  7308. > -
  7309. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7310. >  with "unsubscribe usr-tc" in the body of the message.
  7311. >  For information on digests or retrieving files and old messages send
  7312. >  "help" to the same address.  Do not use quotes in your message.
  7313. > 
  7314.  
  7315.  
  7316. -
  7317.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7318.  with "unsubscribe usr-tc" in the body of the message.
  7319.  For information on digests or retrieving files and old messages send
  7320.  "help" to the same address.  Do not use quotes in your message.
  7321.  
  7322.  
  7323. -------------------------------------------------------------------------------
  7324.  
  7325. From: "Randy Cosby" <dcosby@infowest.com>
  7326. Subject: (usr-tc) Seimens in talks to buy 3Com Unit
  7327. Date: 05 Mar 1999 16:51:52 -0700
  7328.  
  7329. http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm
  7330.  
  7331. "The German communications giant is in preliminary discussions with 3Com to
  7332. acquire a unit of the U.S. vendor that sells networking equipment to
  7333. telephone companies, for a price of around $1.2 billion, the New York Times
  7334. report said. "
  7335.  
  7336. What unit would that be?
  7337.  
  7338. Randy Cosby <dcosby@infowest.com>
  7339. Vice President
  7340. InfoWest Global Internet Services, Inc.
  7341. (435)674-0165   http://www.infowest.com
  7342.  
  7343.  
  7344. -
  7345.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7346.  with "unsubscribe usr-tc" in the body of the message.
  7347.  For information on digests or retrieving files and old messages send
  7348.  "help" to the same address.  Do not use quotes in your message.
  7349.  
  7350.  
  7351. -------------------------------------------------------------------------------
  7352.  
  7353. From: Aaron Nabil <nabil@spiritone.com>
  7354. Subject: (usr-tc) 4.1.59-6 WARNING (was: HiPerARC code for Webramp/Macintosh and related issues.)
  7355. Date: 05 Mar 1999 18:50:14 -0800 (PST)
  7356.  
  7357.  
  7358. This code wiped out the ip pools entires on about 1/3 of my units, be
  7359. sure to do a "list ip pools" after you upgrade and make sure they are
  7360. still there.
  7361.  
  7362. I don't know if any other settings were affected.  You may want to 
  7363. reconfigure from scratch if you can.
  7364.  
  7365.  
  7366. Mike Wronski writes...
  7367. >A service release of HiPerARC has been posted to the Totalservice website. It
  7368. >addresses the Webramp/Mac issues as well as some other ISDN TA's.  Please
  7369. >carefully "READ THE RELEASE NOTES" so you know how to verify the HARC
  7370. >configuration to resolve these problems. A blind upgrade will without some
  7371. >configuring may NOT resolve the issues.
  7372. >
  7373. >HARC 4.1.59-6
  7374.  
  7375. -- 
  7376. Aaron Nabil
  7377.  
  7378. -
  7379.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7380.  with "unsubscribe usr-tc" in the body of the message.
  7381.  For information on digests or retrieving files and old messages send
  7382.  "help" to the same address.  Do not use quotes in your message.
  7383.  
  7384.  
  7385. -------------------------------------------------------------------------------
  7386.  
  7387. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  7388. Subject: Re: (usr-tc) Netserver 16 Question
  7389. Date: 06 Mar 1999 08:24:46 -0600 (CST)
  7390.  
  7391. On Fri, 5 Mar 1999 vanhalen@coredcs.com wrote:
  7392.  
  7393. > Hello-
  7394. > 
  7395. > We have an old Netserver 16 that we use for some dedicated line people for
  7396. > their low traffic mail servers.  I need to get into the box to change the
  7397. > IP information.  I have the password for the box and can telnet into it
  7398. > from any other host on the internet.  However in order to change the ip
  7399. > info I would like to have the console available.
  7400. > 
  7401.  
  7402. Telnet to the box and change the following below
  7403.  
  7404.  
  7405. set security on
  7406. set host 0.0.0.0
  7407. set s0 login_service portmux
  7408. set s0 login network diailin
  7409. reset s0
  7410.  
  7411. krish
  7412.  
  7413. > I can't get the console to let me in and I'm at wit's end on it.  Below is
  7414. > the config for s0.  If I try to !root into it from the console it never
  7415. > asks for a password.  If I root into the console the password attempt
  7416. > shows up in our logfiles.  I'm just lost on it.  Any help is appreciated.
  7417. > If you need more info, please let me know.
  7418. > 
  7419. > I've tried changing the port type for s0 to network hardwired to no avail.
  7420. > The cable I'm using works on our reg TC chassis with Netservers and
  7421. > Hipers.
  7422. > 
  7423. > Steve
  7424. > 
  7425. > 
  7426. > 
  7427. > ----------------------- Current Status - Port S0 ---------------------------
  7428. >         Status: USERNAME
  7429. >          Input: 41                       Parity Errors:  0
  7430. >         Output: 1134                    Framing Errors:  0
  7431. >        Pending: 0                       Overrun Errors:  0
  7432. > 
  7433. >                 Active Configuration    Default Configuration  (* = Host
  7434. >                 --------------------    ---------------------   Can
  7435. > Override)
  7436. >      Port Type: Login                   Login
  7437. >  Login Service: Telnet                  Telnet
  7438. >     Baud Rates: 9600                    9600,9600,9600
  7439. >       Databits: 8                       8
  7440. >       Stopbits: 1                       1
  7441. >         Parity: none                    none
  7442. >   Flow Control: None                    None
  7443. >  Modem Control: off                     off
  7444. >    Init Script: (None)
  7445. >     Init When?: Never
  7446. >          Hosts:                         default                              
  7447. >  Terminal Type: vt100
  7448. >   Login Prompt: login:
  7449. >   Idle Timeout: 20 min 0 sec
  7450. >  Login Message:
  7451. > login:
  7452. > }
  7453. > 
  7454. > Welcome to CORE Digital
  7455. > 
  7456. > 
  7457. > -
  7458. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7459. >  with "unsubscribe usr-tc" in the body of the message.
  7460. >  For information on digests or retrieving files and old messages send
  7461. >  "help" to the same address.  Do not use quotes in your message.
  7462. > 
  7463.  
  7464. -
  7465.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7466.  with "unsubscribe usr-tc" in the body of the message.
  7467.  For information on digests or retrieving files and old messages send
  7468.  "help" to the same address.  Do not use quotes in your message.
  7469.  
  7470.  
  7471. -------------------------------------------------------------------------------
  7472.  
  7473. From: <vanhalen@coredcs.com>
  7474. Subject: Re: (usr-tc) Netserver 16 Question
  7475. Date: 06 Mar 1999 10:57:34 -0600 (CST)
  7476.  
  7477. Hello-
  7478.  
  7479. Thanks for the reply.  I did the commands and also had to set !root on to
  7480. set !root dial-in access on.  This was different than our TC hub with
  7481. Netservers and Quads where !root dialin access is set to off and it still
  7482. allows console connections.  I thought that was a little curious.
  7483.  
  7484. btw set s0 login_service portmux should be set s0 service_login portmux.
  7485.  
  7486. But either way, I'm happy that I can console in now.  Thanks much for the
  7487. help.
  7488.  
  7489. Steve 
  7490.  
  7491. On Sat, 6 Mar 1999, Tatai SV Krishnan wrote:
  7492. > Telnet to the box and change the following below
  7493. > 
  7494. > 
  7495. > set security on
  7496. > set host 0.0.0.0
  7497. > set s0 login_service portmux
  7498. > set s0 login network diailin
  7499. > reset s0
  7500. > 
  7501. > krish
  7502. > 
  7503.  
  7504.  
  7505. -
  7506.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7507.  with "unsubscribe usr-tc" in the body of the message.
  7508.  For information on digests or retrieving files and old messages send
  7509.  "help" to the same address.  Do not use quotes in your message.
  7510.  
  7511.  
  7512. -------------------------------------------------------------------------------
  7513.  
  7514. From: matthew de Jongh <matthew.de.jongh@the-spa.com>
  7515. Subject: (usr-tc) winmodem & compression settings
  7516. Date: 06 Mar 1999 14:00:15 -0500
  7517.  
  7518.  
  7519.  hey, someone mentioned some compression you could shut off that would help
  7520. winmodem people connect better?
  7521.  
  7522.  which compression is this and how do you shut it off?
  7523.  
  7524.  matthew
  7525.  
  7526.  
  7527. -
  7528.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7529.  with "unsubscribe usr-tc" in the body of the message.
  7530.  For information on digests or retrieving files and old messages send
  7531.  "help" to the same address.  Do not use quotes in your message.
  7532.  
  7533.  
  7534. -------------------------------------------------------------------------------
  7535.  
  7536. From: Lostboy <lostboy@spacelink.com>
  7537. Subject: (usr-tc) SNMP, Radius, and Session-Id's
  7538. Date: 06 Mar 1999 15:21:00 +0000 (GMT)
  7539.  
  7540.  
  7541. Hi -
  7542.  
  7543.   Do any of you guys know if there is a way to extract the session ID's that
  7544. are used in Radius accounting (Acct-Session-Id 44) for all connected users
  7545. from a HiperArc?  I've poked through the MIB files and there are a couple items
  7546. that are close but they either do not work (the chassis does not respond at all,
  7547. though the MIB says thet should be there) or they return a diffrent sort of session
  7548. ID (internal?).
  7549.  
  7550.   Also, related, the below is an exerpt from the "usr_hiper.mib" file.  Any
  7551. clue what integer INDEX component "uumActiveSessionId" actually is?  These
  7552. values don't seem to relate to anything that I can find...
  7553.  
  7554.         uumActiveSessionEntry   OBJECT-TYPE
  7555.         SYNTAX  UumActiveSessionEntry
  7556.         ACCESS  not-accessible
  7557.         STATUS  mandatory
  7558.         DESCRIPTION
  7559.                 ""
  7560.         INDEX   { uumActiveSessionUserName, uumActiveSessionSessionId }
  7561.         ::= { usrUserManActiveSessionTable 1 }
  7562.  
  7563. Thanks!
  7564. -Jim
  7565.  
  7566. -
  7567.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7568.  with "unsubscribe usr-tc" in the body of the message.
  7569.  For information on digests or retrieving files and old messages send
  7570.  "help" to the same address.  Do not use quotes in your message.
  7571.  
  7572.  
  7573. -------------------------------------------------------------------------------
  7574.  
  7575. From: Matthew Opoka <phantom@magnolia.net>
  7576. Subject: Re: (usr-tc) HiPerARC code for Webramp/Macintosh and related issues. 
  7577. Date: 06 Mar 1999 21:07:15 -0600
  7578.  
  7579. My Webramp 310i now connects but it's still not good. The connection is
  7580. good for about 1-10mins then is hosed this is without VJ and Stac turned
  7581. on.  With VJ and Stac turned on the connections is hosed right away but
  7582. it connects now.
  7583.  
  7584. Mike Wronski wrote:
  7585. > 
  7586. > A service release of HiPerARC has been posted to the Totalservice website. It
  7587. > addresses the Webramp/Mac issues as well as some other ISDN TA's.  Please
  7588. > carefully "READ THE RELEASE NOTES" so you know how to verify the HARC
  7589. > configuration to resolve these problems. A blind upgrade will without some
  7590. > configuring may NOT resolve the issues.
  7591. > 
  7592. > HARC 4.1.59-6
  7593. > ftp://mwronski:qwerty@totalservice.usr.com/pub/.files/ne040159_6.zip
  7594. > Release Notes ftp://totalservice.usr.com/pub/.docs/040159_6.pdf
  7595. > 
  7596. > This code will does not require a service contract to download.
  7597. > 
  7598. > ---------------------------------------------------------
  7599. > Mike Wronski (mike@coredump.ae.usr.com)
  7600. > Rogue 3Com Network Systems Engineer / BETA Engineer
  7601. > PGP:http://coredump.ae.usr.com/pgp iCQ:15796141
  7602. > "If at first you do succeed, try not to look astonished."
  7603. > 
  7604. > -
  7605. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7606. >  with "unsubscribe usr-tc" in the body of the message.
  7607. >  For information on digests or retrieving files and old messages send
  7608. >  "help" to the same address.  Do not use quotes in your message.
  7609.  
  7610. -
  7611.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7612.  with "unsubscribe usr-tc" in the body of the message.
  7613.  For information on digests or retrieving files and old messages send
  7614.  "help" to the same address.  Do not use quotes in your message.
  7615.  
  7616.  
  7617. -------------------------------------------------------------------------------
  7618.  
  7619. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  7620. Subject: Re: (usr-tc) HiPerARC code for Webramp/Macintosh and related issues. (4.1.59-6)
  7621. Date: 06 Mar 1999 22:01:57 -0600 (CST)
  7622.  
  7623. On Sat, 6 Mar 1999, Matthew Opoka wrote:
  7624.  
  7625. > My Webramp 310i now connects but it's still not good. The connection is
  7626. > good for about 1-10mins then is hosed this is without VJ and Stac turned
  7627. > on.  With VJ and Stac turned on the connections is hosed right away but
  7628. > it connects now.
  7629. > 
  7630.  
  7631. Totally a different issue.  This code 4.1.59 -6 solves the pap connection 
  7632. issue only.  What you are experiencing a a different problem.  Need PPP 
  7633. trace to find out what is exactly happening.
  7634.  
  7635. Where are you enabling stac and vj?
  7636. Where are you disabling stac and vj?
  7637.  
  7638. When it disconnects what is the disconnect reason?
  7639.  
  7640. Is this problem solved if you use chap?
  7641.  
  7642. Apart from the ppp trace answers to the above questions will be helpful
  7643.  
  7644. krish
  7645.  
  7646. > > 
  7647. > > This code will does not require a service contract to download.
  7648. > > 
  7649. > > ---------------------------------------------------------
  7650. > > Mike Wronski (mike@coredump.ae.usr.com)
  7651. > > Rogue 3Com Network Systems Engineer / BETA Engineer
  7652. > > PGP:http://coredump.ae.usr.com/pgp iCQ:15796141
  7653. > > "If at first you do succeed, try not to look astonished."
  7654. > > 
  7655. > > -
  7656. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7657. > >  with "unsubscribe usr-tc" in the body of the message.
  7658. > >  For information on digests or retrieving files and old messages send
  7659. > >  "help" to the same address.  Do not use quotes in your message.
  7660. > 
  7661. > -
  7662. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7663. >  with "unsubscribe usr-tc" in the body of the message.
  7664. >  For information on digests or retrieving files and old messages send
  7665. >  "help" to the same address.  Do not use quotes in your message.
  7666. > 
  7667.  
  7668. -
  7669.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7670.  with "unsubscribe usr-tc" in the body of the message.
  7671.  For information on digests or retrieving files and old messages send
  7672.  "help" to the same address.  Do not use quotes in your message.
  7673.  
  7674.  
  7675. -------------------------------------------------------------------------------
  7676.  
  7677. From: Charles Hill <chill@ionet.net>
  7678. Subject: Re: (usr-tc) Seimens in talks to buy 3Com Unit
  7679. Date: 06 Mar 1999 23:07:52 -0600
  7680.  
  7681. I've heard the rumor about 3Com offloading the Total Control unit a few
  7682. times now, so I'm starting to believe it.  This Siemens story makes me
  7683. think it's going to happen.
  7684.  
  7685. > http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm
  7686.  
  7687. I hope the deal is beneficial for everyone.  Maybe Siemens will commit
  7688. more resources to developing the Total Control products than 3Com has. 
  7689. Higher density and DS3 ingress would be nice.
  7690.  
  7691. -CH
  7692.  
  7693. Related older stories:
  7694. http://images.cnnfn.com/digitaljam/9707/09/3com/
  7695. http://www.3com.co.uk/news/ihop/ihopnews6.html
  7696.  
  7697. Randy Cosby wrote:
  7698. > 
  7699. > 
  7700. > "The German communications giant is in preliminary discussions with 3Com to
  7701. > acquire a unit of the U.S. vendor that sells networking equipment to
  7702. > telephone companies, for a price of around $1.2 billion, the New York Times
  7703. > report said. "
  7704. > 
  7705. > What unit would that be?
  7706. > 
  7707. > Randy Cosby <dcosby@infowest.com>
  7708. > Vice President
  7709. > InfoWest Global Internet Services, Inc.
  7710. > (435)674-0165   http://www.infowest.com
  7711. > 
  7712. > -
  7713. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7714. >  with "unsubscribe usr-tc" in the body of the message.
  7715. >  For information on digests or retrieving files and old messages send
  7716. >  "help" to the same address.  Do not use quotes in your message.
  7717.  
  7718. -
  7719.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7720.  with "unsubscribe usr-tc" in the body of the message.
  7721.  For information on digests or retrieving files and old messages send
  7722.  "help" to the same address.  Do not use quotes in your message.
  7723.  
  7724.  
  7725. -------------------------------------------------------------------------------
  7726.  
  7727. From: "Ronald E. Kushner" <ron@glis.net>
  7728. Subject: Re: (usr-tc) Seimens in talks to buy 3Com Unit
  7729. Date: 07 Mar 1999 02:20:52 -0500
  7730.  
  7731.  
  7732.  
  7733. Charles Hill wrote:
  7734. > 
  7735. > I've heard the rumor about 3Com offloading the Total Control unit a few
  7736. > times now, so I'm starting to believe it.  This Siemens story makes me
  7737. > think it's going to happen.
  7738. > 
  7739. > > http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm
  7740. > 
  7741. > I hope the deal is beneficial for everyone.  Maybe Siemens will commit
  7742. > more resources to developing the Total Control products than 3Com has.
  7743. > Higher density and DS3 ingress would be nice.
  7744.  
  7745. Plus when things don't go right, I'll pick up my Siemens phone, call Siemens
  7746. tech support, and tell them that my Total Control is connected to a Siemens
  7747. EWSD switch, and the damn thing better work properly on thier own switch.
  7748. Maybe we can get blocking to work properly on NI2 PRI's. Ten digit numbers
  7749. for DNIS would be nice as well.
  7750.  
  7751. Actually it's quite funny to see a local problem where two EWSD switches
  7752. just don't seem to like each other. The woman working for Ameritech said,
  7753. "These damn things should like each other, god knows that the EWSD doesn't
  7754. like Lucent or Nortel switches."
  7755.  
  7756. -Ron
  7757. GLISnet, Inc.
  7758. +1 810/939.9885
  7759.  
  7760. -
  7761.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7762.  with "unsubscribe usr-tc" in the body of the message.
  7763.  For information on digests or retrieving files and old messages send
  7764.  "help" to the same address.  Do not use quotes in your message.
  7765.  
  7766.  
  7767. -------------------------------------------------------------------------------
  7768.  
  7769. From: Stephen Amadei <amadei@dandy.net>
  7770. Subject: (usr-tc) Pesky LEDs
  7771. Date: 07 Mar 1999 04:39:44 -0500 (EST)
  7772.  
  7773.  
  7774. I was poking around in the Total Control MIB lately, and noticed 
  7775. objects for reading the status and colors of the LEDs on a chassis-wide 
  7776. basis.  However, it's a proprietary encoding.
  7777.  
  7778. Anybody crack the encoding scheme?  Or, can somebody point me to
  7779. documentation that tells me how to decode them?  
  7780.  
  7781. I promise any project gleamed from this info would be given away for free.
  7782. ;-)
  7783.  
  7784.                     ----Steve
  7785. Stephen Amadei
  7786. Director of MIS
  7787. Dandy Connections, Inc.
  7788. Atlantic City, NJ
  7789.  
  7790.  
  7791. -
  7792.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7793.  with "unsubscribe usr-tc" in the body of the message.
  7794.  For information on digests or retrieving files and old messages send
  7795.  "help" to the same address.  Do not use quotes in your message.
  7796.  
  7797.  
  7798. -------------------------------------------------------------------------------
  7799.  
  7800. From: d baud <dbaud@bigfoot.com>
  7801. Subject: (usr-tc) IEA , using it from Radius
  7802. Date: 07 Mar 1999 14:15:22 -0500
  7803.  
  7804. I am trying to use the new IEA feature in the 4.1.59-6 HARC code.  I
  7805. managed to use it with local non-radius users:
  7806. set network usr my_local_user IP IEA_NEXT_HOP_GATEWAY 192.0.0.1
  7807.  
  7808. Now this is great, but I need to use this for particular users from
  7809. RADIUS, so I added in the dictionnary the following:
  7810. ATTRIBUTE    IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr
  7811.  
  7812. And I added to my "users" file the entry
  7813. IEA_NEXT_HOP_GATEWAY = 192.0.0.1,
  7814.  
  7815. The RADIUS users still pick the defaultroute :(
  7816. I tried to monitor the connection with "mon radius" on the HARC but it
  7817. does not seem to report any VSA attributes anyway.
  7818.  
  7819. Oh BTW for those who don't know what IEA is, it stands for Internet
  7820. Equal Access and it is used to specify a different gateway than the
  7821. defaultroute.
  7822.  
  7823. D. Baud
  7824.  
  7825.  
  7826. -
  7827.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7828.  with "unsubscribe usr-tc" in the body of the message.
  7829.  For information on digests or retrieving files and old messages send
  7830.  "help" to the same address.  Do not use quotes in your message.
  7831.  
  7832.  
  7833. -------------------------------------------------------------------------------
  7834.  
  7835. From: Brian <signal@shreve.net>
  7836. Subject: Re: (usr-tc) IEA , using it from Radius
  7837. Date: 07 Mar 1999 15:22:35 -0600 (EST)
  7838.  
  7839. On Sun, 7 Mar 1999, d baud wrote:
  7840.  
  7841. > I am trying to use the new IEA feature in the 4.1.59-6 HARC code.  I
  7842. > managed to use it with local non-radius users:
  7843. > set network usr my_local_user IP IEA_NEXT_HOP_GATEWAY 192.0.0.1
  7844. > 
  7845. > Now this is great, but I need to use this for particular users from
  7846. > RADIUS, so I added in the dictionnary the following:
  7847. > ATTRIBUTE    IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr
  7848. > 
  7849. > And I added to my "users" file the entry
  7850. > IEA_NEXT_HOP_GATEWAY = 192.0.0.1,
  7851. > 
  7852. > The RADIUS users still pick the defaultroute :(
  7853. > I tried to monitor the connection with "mon radius" on the HARC but it
  7854. > does not seem to report any VSA attributes anyway.
  7855. > 
  7856. > Oh BTW for those who don't know what IEA is, it stands for Internet
  7857. > Equal Access and it is used to specify a different gateway than the
  7858. > defaultroute.
  7859.  
  7860.  
  7861. use VPN-Neighbor instaead:
  7862.  
  7863. VPN-Neighbor = "192.0.0.1"
  7864.  
  7865. > 
  7866. > D. Baud
  7867. > 
  7868. > 
  7869. > -
  7870. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7871. >  with "unsubscribe usr-tc" in the body of the message.
  7872. >  For information on digests or retrieving files and old messages send
  7873. >  "help" to the same address.  Do not use quotes in your message.
  7874. > 
  7875.  
  7876. Brian Feeny (BF304)     signal@shreve.net   
  7877. 318-222-2638 x 109    http://www.shreve.net/~signal      
  7878. Network Administrator   ShreveNet Inc. (ASN 11881)           
  7879.  
  7880.  
  7881. -
  7882.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7883.  with "unsubscribe usr-tc" in the body of the message.
  7884.  For information on digests or retrieving files and old messages send
  7885.  "help" to the same address.  Do not use quotes in your message.
  7886.  
  7887.  
  7888. -------------------------------------------------------------------------------
  7889.  
  7890. From: mt <tsaim@mft.com>
  7891. Subject: (usr-tc) Need sw to analyze Netserver Log
  7892. Date: 07 Mar 1999 17:49:08 -0500
  7893.  
  7894. Hi All,
  7895.  
  7896. Is there any commercial software or shareware, w/ whatever the Language
  7897. it was written,
  7898. that can be used to analyze the user login info that was logged from TC
  7899. box into our
  7900. Unix syslogd file. ?
  7901.  
  7902. We tried 3com's Accounting software before and not too enthusastic about
  7903. it.
  7904. And we do not have Radius.
  7905.  
  7906. Thanks
  7907.  
  7908. Meng
  7909. tsaim@mft.com
  7910.  
  7911.  
  7912. -
  7913.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7914.  with "unsubscribe usr-tc" in the body of the message.
  7915.  For information on digests or retrieving files and old messages send
  7916.  "help" to the same address.  Do not use quotes in your message.
  7917.  
  7918.  
  7919. -------------------------------------------------------------------------------
  7920.  
  7921. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  7922. Subject: Re: (usr-tc) IEA , using it from Radius
  7923. Date: 07 Mar 1999 18:52:09 -0600 (CST)
  7924.  
  7925. Does your radius server support VSAs?
  7926.  
  7927. krish
  7928.  
  7929.         \    T.S.V. Krishnan  \
  7930.          \      Network System Engineer \ ( : - : )
  7931.           \     3Com ............   \
  7932.         ----------------------------------------------/
  7933. tkrishna@bubba.ae.usr.com  
  7934. ----------------------------/ http://interproc.ae.usr.com ----/
  7935. The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html
  7936.     Any Sufficiently advanced bug is indistinguishable for a feature.
  7937.                         - Rick Kulawiec
  7938.  
  7939. On Sun, 7 Mar 1999, d baud wrote:
  7940.  
  7941. > I am trying to use the new IEA feature in the 4.1.59-6 HARC code.  I
  7942. > managed to use it with local non-radius users:
  7943. > set network usr my_local_user IP IEA_NEXT_HOP_GATEWAY 192.0.0.1
  7944. > 
  7945. > Now this is great, but I need to use this for particular users from
  7946. > RADIUS, so I added in the dictionnary the following:
  7947. > ATTRIBUTE    IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr
  7948. > 
  7949. > And I added to my "users" file the entry
  7950. > IEA_NEXT_HOP_GATEWAY = 192.0.0.1,
  7951. > 
  7952. > The RADIUS users still pick the defaultroute :(
  7953. > I tried to monitor the connection with "mon radius" on the HARC but it
  7954. > does not seem to report any VSA attributes anyway.
  7955. > 
  7956. > Oh BTW for those who don't know what IEA is, it stands for Internet
  7957. > Equal Access and it is used to specify a different gateway than the
  7958. > defaultroute.
  7959. > 
  7960. > D. Baud
  7961. > 
  7962. > 
  7963. > -
  7964. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7965. >  with "unsubscribe usr-tc" in the body of the message.
  7966. >  For information on digests or retrieving files and old messages send
  7967. >  "help" to the same address.  Do not use quotes in your message.
  7968. > 
  7969.  
  7970. -
  7971.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  7972.  with "unsubscribe usr-tc" in the body of the message.
  7973.  For information on digests or retrieving files and old messages send
  7974.  "help" to the same address.  Do not use quotes in your message.
  7975.  
  7976.  
  7977. -------------------------------------------------------------------------------
  7978.  
  7979. From: Robert von Bismarck <rvb@petrel.ch>
  7980. Subject: RE: (usr-tc) 3Com Problems.
  7981. Date: 08 Mar 1999 12:28:45 +0100 
  7982.  
  7983.     I assume that those modems weren't MICA... These modems really suck
  7984. bad. We had a dozen here for a "mini-POP" and finally gave it up, and
  7985. replaced the cisco by a TC (ARC + DSP) and were really happy with it (still
  7986. are ;-).
  7987.  
  7988.     Robert
  7989.  
  7990.     oh yeah, nearly forgot : FS : 12 Mica Modems with carrier module for
  7991. Cisco 3640 ;-)
  7992.  
  7993.  
  7994. > But the next purchase will not be 3com or Livingston but rather Cisco. :-)
  7995. > 
  7996. > Not that were displeased with 3com Hiper or anything (its nice hardware,
  7997. > and I like the interface better than ComOS), just that under months of
  7998. > testing Cisco gave our customers more consistent and stable modem
  7999. > connections than either Hiper or PM3 and in the end its customer
  8000. > satisfaction not admin satisfaction that counts. Whatever magic DSP code
  8001. > Cisco has it works and thats all that matters.
  8002. > 
  8003. > And please no "run code version XYZ it will give better connects than
  8004. > Cisco" because it doesnt. No code versons on either 3com or Livingston
  8005. > made appreciably better or worse connections than any other version.
  8006. > 
  8007. > -Dan
  8008. > 
  8009. > 
  8010. > -
  8011. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8012. >  with "unsubscribe usr-tc" in the body of the message.
  8013. >  For information on digests or retrieving files and old messages send
  8014. >  "help" to the same address.  Do not use quotes in your message.
  8015.  
  8016. -
  8017.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8018.  with "unsubscribe usr-tc" in the body of the message.
  8019.  For information on digests or retrieving files and old messages send
  8020.  "help" to the same address.  Do not use quotes in your message.
  8021.  
  8022.  
  8023. -------------------------------------------------------------------------------
  8024.  
  8025. From: Robert von Bismarck <rvb@petrel.ch>
  8026. Subject: RE: (usr-tc) 3Com Problems.
  8027. Date: 08 Mar 1999 12:54:30 +0100 
  8028.  
  8029. The PM2-30 sitting in the closet is a 30 port. It's got an AMD Am386dx-40
  8030. and a mind-boggling 4 megs of RAM.
  8031.  
  8032. Well it's an OEM by Cayman Systems, called "GatorAccess" but the mboard is
  8033. definitely marked Livingston.
  8034.  
  8035. -Robert
  8036.  
  8037. > -----Original Message-----
  8038. > From:    MegaZone [SMTP:megazone@megazone.org]
  8039. > Sent:    lundi, 1. mars 1999 12:05
  8040. > To:    usr-tc@lists.xmission.com
  8041. > Subject:    Re: (usr-tc) 3Com Problems.
  8042. > 
  8043. > Once upon a time Ricky Beam shaped the electrons to say...
  8044. > >_damn_ good NAS -- who else has ever been able to get a 386dx40 to run
  8045. > >48 115.2k serial ports without a problem?
  8046. > 
  8047. > Well, the PM-2eR-30 only has a 386-33, early revs were 386-25. :-)  That's
  8048. > the most ports on an async PM.  The PM-3 is a 486-66.
  8049. > 
  8050. > -MZ
  8051. > -- 
  8052. > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/>
  8053. > X*=-
  8054. > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer,
  8055. > me..
  8056. > Join ISP/C Internet Service Providers' Consortium
  8057. > <URL:http://www.ispc.org/>
  8058. > "A little nonsense now and then, is relished by the wisest men"
  8059. > 781-788-0130
  8060. > <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail
  8061. > Discordia!
  8062. >  
  8063. > 
  8064. > -
  8065. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8066. >  with "unsubscribe usr-tc" in the body of the message.
  8067. >  For information on digests or retrieving files and old messages send
  8068. >  "help" to the same address.  Do not use quotes in your message.
  8069.  
  8070. -
  8071.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8072.  with "unsubscribe usr-tc" in the body of the message.
  8073.  For information on digests or retrieving files and old messages send
  8074.  "help" to the same address.  Do not use quotes in your message.
  8075.  
  8076.  
  8077. -------------------------------------------------------------------------------
  8078.  
  8079. From: Robert von Bismarck <rvb@petrel.ch>
  8080. Subject: RE: (usr-tc) 3Com Problems.
  8081. Date: 08 Mar 1999 13:16:40 +0100 
  8082.  
  8083. Correction, there is an upgrade to the 3640, I just performed that with an
  8084. old 4000, you send in an old 4000 with all it's goodies, and they send you a
  8085. 3640 chassis (no interfaces mind you, but you can get those at a very
  8086. interesting price)
  8087.  
  8088. -Robert
  8089.  
  8090. > -----Original Message-----
  8091. > From:    Dan Hollis [SMTP:goemon@sasami.anime.net]
  8092. > Sent:    lundi, 1. mars 1999 22:09
  8093. > To:    usr-tc@lists.xmission.com
  8094. > Subject:    Re: (usr-tc) 3Com Problems.
  8095. > 
  8096. > On Fri, 26 Feb 1999, Jeff Mcadams wrote:
  8097. > > I can still buy Cisco 2500's, that's older hardware technology than the
  8098. > > NETServers by a generation or two.
  8099. > 
  8100. > Cisco has EOL'd the 4000 and 4500's. There is no upgrade path.
  8101. > What are owners of that technology to do?
  8102. > 
  8103. > -Dan
  8104. > 
  8105. > 
  8106. > -
  8107. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8108. >  with "unsubscribe usr-tc" in the body of the message.
  8109. >  For information on digests or retrieving files and old messages send
  8110. >  "help" to the same address.  Do not use quotes in your message.
  8111.  
  8112. -
  8113.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8114.  with "unsubscribe usr-tc" in the body of the message.
  8115.  For information on digests or retrieving files and old messages send
  8116.  "help" to the same address.  Do not use quotes in your message.
  8117.  
  8118.  
  8119. -------------------------------------------------------------------------------
  8120.  
  8121. From: Robert von Bismarck <rvb@petrel.ch>
  8122. Subject: RE: (usr-tc) 3Com Problems.
  8123. Date: 08 Mar 1999 16:18:54 +0100 
  8124.  
  8125. I'm kinda sick of reading all this junk about suing 3com and blablabla...
  8126. Stop the whining. Did you also all whine as much when you found out your old
  8127. 286 wasn't able to run win95 ? 
  8128. You eventually found out that you had to upgrade to a 386 to be able to run
  8129. Linux, if you haven't found out yet, stop reading this right now ;-). This
  8130. also happens with servers, even with NAS's. The 486 has outlived it's life,
  8131. welcome to the PPC.
  8132. If you want the features, buy the right hardware and software. You want 48
  8133. ports ? fine... buy a couple pm2's with a bunch of Courier modems and a
  8134. 2501, and off you go into the happy world of low-cost, low-business
  8135. ISPing... and you're out of business in 2 years, while your next door
  8136. neigbour invested in a more powerful system which is better in the upgrade
  8137. and grabs your client database for 10$ at a court-level auction.
  8138. Upgrade is the power-word. In the ISP business it's "do or die". You want to
  8139. survive, you need more (be it customers, employees, ports, PoP's, etc...)
  8140. else you're dead or dying.
  8141. I think 3com is aiming at the future, not at the "now". My boss usually says
  8142. "now is too late", and I'm sure he's right. The folks at 3com have built
  8143. very good hardware, now they have to get the soft up to speed (all the major
  8144. bugs are out, and the minors are getting solved). I remember a time, where I
  8145. was rebooting my PM2e's every night at 4:30 to remove the memory leaks.
  8146.  
  8147. Well enough blathering,
  8148.  
  8149. all flames to /dev/null
  8150.  
  8151. --
  8152. Robert von Bismarck
  8153. Network Systems Engineer
  8154. Petrel Communications SA / SPAN
  8155. Tel : +41 22 304 47 47
  8156. Fax : +41 22 300 48 43
  8157. WWW : http://www.petrel.ch
  8158. e-mail : rvb@petrel.ch
  8159.  
  8160.  
  8161. -
  8162.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8163.  with "unsubscribe usr-tc" in the body of the message.
  8164.  For information on digests or retrieving files and old messages send
  8165.  "help" to the same address.  Do not use quotes in your message.
  8166.  
  8167.  
  8168. -------------------------------------------------------------------------------
  8169.  
  8170. From: Jeff Mcadams <jeffm@iglou.com>
  8171. Subject: Re: (usr-tc) 3Com Problems.
  8172. Date: 08 Mar 1999 10:52:24 -0500 (EST)
  8173.  
  8174. Thus spake Robert von Bismarck
  8175. >I'm kinda sick of reading all this junk about suing 3com and blablabla...
  8176. >Stop the whining. Did you also all whine as much when you found out your old
  8177. >286 wasn't able to run win95 ? 
  8178. >You eventually found out that you had to upgrade to a 386 to be able to run
  8179. >Linux, if you haven't found out yet, stop reading this right now ;-). This
  8180. >also happens with servers, even with NAS's. The 486 has outlived it's life,
  8181. >welcome to the PPC.
  8182. >If you want the features, buy the right hardware and software. 
  8183.  
  8184. You just don't get it, do you?  This is *NOT* about features.  I don't
  8185. need to upgrade, I need the NETServers to work as advertised, nothing
  8186. more.
  8187.  
  8188. >You want 48
  8189. >ports ? fine... buy a couple pm2's with a bunch of Courier modems and a
  8190. >2501, and off you go into the happy world of low-cost, low-business
  8191. >ISPing... and you're out of business in 2 years, 
  8192.  
  8193. Sorry to disappoint you, but IgLou has been in this business for over 12
  8194. years at this point, hardly some "low-cost, low-business" ISP or out of
  8195. business in 2 years.  I would hazard a bet that we've been using
  8196. USR/3Com equipment for longer than your ISP has been in business!
  8197.  
  8198. >Upgrade is the power-word. In the ISP business it's "do or die". You want to
  8199. >survive, you need more (be it customers, employees, ports, PoP's, etc...)
  8200. >else you're dead or dying.
  8201.  
  8202. I agree...and we're working on upgrading...however, at the same time,
  8203. throwing away hundreds of thousands of dollars of investments because
  8204. some vendor says their incapable of fixing something that should have
  8205. worked in the first place is certainly not a good recipe for being
  8206. profitable either.  Another news flash for you...IgLou is profitable,
  8207. and has been for longer than probably 90% of ISP's have been in
  8208. business, we didn't do that by flushing equipment investments down the
  8209. drain just because the equipment is a generation older.  If it still
  8210. does what we need it to do, we continue to use it.  Yes, upgrading is
  8211. important to be able to get new features...at this point, the HiPer Arc
  8212. doesn't have any features that the NETServer doesn't, or more
  8213. importantly, any features which make it worth our while to go into debt
  8214. in order to obtain.  We'll make, and are making, the move to HiPer
  8215. Arc's, but are doing it in a way that's fiscally responsible.  We're not
  8216. going out and buying the latest, greatest hardware just because it gives
  8217. us a testosterone boost to do so.
  8218.  
  8219. The simple fact is that 3Com is using illegal tactics to sell HiPer
  8220. Arcs.  3Com promised a software feature and in order to get that
  8221. software feature to work, they are trying to get people to buy new
  8222. hardware that it *CANNOT* be argued is necessary to get this feature
  8223. working.  You *CANNOT* argue that a 486 doesn't have enough CPU power to
  8224. run MPIP.  A PPC is simply not needed to do this...and for 3Com to try
  8225. to sell the extra hardware (at a premium) to do this is a used car lot
  8226. Bait and Switch tactic, nothing more.
  8227.  
  8228. >I think 3com is aiming at the future, not at the "now". 
  8229.  
  8230. Oh, I agree...the HiPer Arc hardware is good hardware...and the OS on it
  8231. has a nice feel (I don't know anything about the internals of it)...and
  8232. IgLou is moving to the future and purchasing HiPer Arcs as they finally
  8233. have all the features that we need to offer our service on them.  To
  8234. look to the future without also considering the "now" though is to
  8235. assure that you won't make it to what you're looking at.  I need
  8236. functional MPIP, period.  3Com can deliver that however they wish, but
  8237. to say that I need to pay a premium to get a feature that they said 3
  8238. months ago that I didn't need to pay a premium for, is downright
  8239. unethical at best.
  8240.  
  8241. >My boss usually says
  8242. >"now is too late", and I'm sure he's right. 
  8243.  
  8244. Yeah, and 3Com is in the past, not even up to the "now," as they don't
  8245. even have functional MPIP on the NETServers where it was originally
  8246. delivered.
  8247.  
  8248. >Well enough blathering,
  8249.  
  8250. Perhaps if you'd listen to what others are saying before responding you
  8251. might be able to respond with relevant points.
  8252. -- 
  8253. Jeff McAdams                            Email: jeffm@iglou.com
  8254. Head Network Administrator              Voice: (502) 966-3848
  8255. IgLou Internet Services                        (800) 436-4456
  8256.  
  8257. -
  8258.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8259.  with "unsubscribe usr-tc" in the body of the message.
  8260.  For information on digests or retrieving files and old messages send
  8261.  "help" to the same address.  Do not use quotes in your message.
  8262.  
  8263.  
  8264. -------------------------------------------------------------------------------
  8265.  
  8266. From: K Mitchell <mitch@keyconn.net>
  8267. Subject: RE: (usr-tc) 3Com Problems.
  8268. Date: 08 Mar 1999 10:51:07 -0500
  8269.  
  8270. At 04:18 PM 3/8/99 +0100, Robert von Bismarck <rvb@petrel.ch> wrote:
  8271. >I'm kinda sick of reading all this junk about suing 3com and blablabla...
  8272. >Stop the whining. Did you also all whine as much when you found out your old
  8273. >286 wasn't able to run win95 ? 
  8274.  
  8275.   You're missing the whole point of their complaints. Their gripe isn't
  8276. that a 286 won't run Win'95, the gripe is that they were promised that it
  8277. would when they bought it, now it doesn't, and they're being told that
  8278. their only option is to buy something else.
  8279.   It's not about the Netserver's capabilities, it's about the salesman or
  8280. company misrepresenting the product and it's capabilities in order to sell it.
  8281.  
  8282. At least that's what I inferred by actually reading the complaints.
  8283.  
  8284. Kirk
  8285.  
  8286.  
  8287.  
  8288. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  8289. Keystone Connect                http://www.keyconn.net
  8290. Altoona, PA   814-941-5000         We Unlock the World
  8291.  
  8292.  
  8293. -
  8294.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8295.  with "unsubscribe usr-tc" in the body of the message.
  8296.  For information on digests or retrieving files and old messages send
  8297.  "help" to the same address.  Do not use quotes in your message.
  8298.  
  8299.  
  8300. -------------------------------------------------------------------------------
  8301.  
  8302. From: Jeff Mcadams <jeffm@iglou.com>
  8303. Subject: Re: (usr-tc) 3Com Problems.
  8304. Date: 08 Mar 1999 11:00:07 -0500 (EST)
  8305.  
  8306. Thus spake K Mitchell
  8307. >At 04:18 PM 3/8/99 +0100, Robert von Bismarck <rvb@petrel.ch> wrote:
  8308. >>I'm kinda sick of reading all this junk about suing 3com and blablabla...
  8309. >>Stop the whining. Did you also all whine as much when you found out your old
  8310. >>286 wasn't able to run win95 ? 
  8311.  
  8312. >  You're missing the whole point of their complaints. Their gripe isn't
  8313. >that a 286 won't run Win'95, the gripe is that they were promised that it
  8314. >would when they bought it, now it doesn't, and they're being told that
  8315. >their only option is to buy something else.
  8316. >  It's not about the Netserver's capabilities, it's about the salesman or
  8317. >company misrepresenting the product and it's capabilities in order to sell it.
  8318.  
  8319. >At least that's what I inferred by actually reading the complaints.
  8320.  
  8321. Actually...I'd go even further than that....its like being told that a
  8322. 286 would run DOS 3.3...which by all means it should be able to...and
  8323. then being told that to run DOS 3.3 we have to upgrade to a Pentium
  8324. because they can't fix DOS 3.3 on a 286 anymore.
  8325. -- 
  8326. Jeff McAdams                            Email: jeffm@iglou.com
  8327. Head Network Administrator              Voice: (502) 966-3848
  8328. IgLou Internet Services                        (800) 436-4456
  8329.  
  8330. -
  8331.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8332.  with "unsubscribe usr-tc" in the body of the message.
  8333.  For information on digests or retrieving files and old messages send
  8334.  "help" to the same address.  Do not use quotes in your message.
  8335.  
  8336.  
  8337. -------------------------------------------------------------------------------
  8338.  
  8339. From: Clayton Zekelman <clayton@MNSi.Net>
  8340. Subject: Re: (usr-tc) Seimens in talks to buy 3Com Unit
  8341. Date: 07 Mar 1999 15:02:27 +0000
  8342.  
  8343. Either that, or the TC line will become just like the rest of Siemens
  8344. equipment:
  8345.  
  8346. Siemens - You can buy better, but you can't pay more.
  8347.  
  8348.  
  8349. At 11:07 PM 3/6/99 -0600, you wrote:
  8350. >I've heard the rumor about 3Com offloading the Total Control unit a few
  8351. >times now, so I'm starting to believe it.  This Siemens story makes me
  8352. >think it's going to happen.
  8353. >
  8354. >> http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm
  8355. >
  8356. >I hope the deal is beneficial for everyone.  Maybe Siemens will commit
  8357. >more resources to developing the Total Control products than 3Com has. 
  8358. >Higher density and DS3 ingress would be nice.
  8359. >
  8360. >-CH
  8361. >
  8362. >Related older stories:
  8363. >http://images.cnnfn.com/digitaljam/9707/09/3com/
  8364. >http://www.3com.co.uk/news/ihop/ihopnews6.html
  8365. >
  8366. >Randy Cosby wrote:
  8367. >> 
  8368. >> 
  8369. >> "The German communications giant is in preliminary discussions with 3Com to
  8370. >> acquire a unit of the U.S. vendor that sells networking equipment to
  8371. >> telephone companies, for a price of around $1.2 billion, the New York Times
  8372. >> report said. "
  8373. >> 
  8374. >> What unit would that be?
  8375. >> 
  8376. >> Randy Cosby <dcosby@infowest.com>
  8377. >> Vice President
  8378. >> InfoWest Global Internet Services, Inc.
  8379. >> (435)674-0165   http://www.infowest.com
  8380. >> 
  8381. >> -
  8382. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8383. >>  with "unsubscribe usr-tc" in the body of the message.
  8384. >>  For information on digests or retrieving files and old messages send
  8385. >>  "help" to the same address.  Do not use quotes in your message.
  8386. >
  8387. >-
  8388. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8389. > with "unsubscribe usr-tc" in the body of the message.
  8390. > For information on digests or retrieving files and old messages send
  8391. > "help" to the same address.  Do not use quotes in your message.
  8392. > 
  8393. ---
  8394. Clayton Zekelman
  8395. Managed Network Systems Inc. (MNSi)
  8396. 875 Ouellette Avenue
  8397. Windsor, Ontario
  8398. N9A 4J6
  8399.  
  8400. tel. 519-985-8410
  8401. fax. 519-258-3009
  8402.  
  8403. -
  8404.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8405.  with "unsubscribe usr-tc" in the body of the message.
  8406.  For information on digests or retrieving files and old messages send
  8407.  "help" to the same address.  Do not use quotes in your message.
  8408.  
  8409.  
  8410. -------------------------------------------------------------------------------
  8411.  
  8412. From: Robert von Bismarck <rvb@petrel.ch>
  8413. Subject: RE: (usr-tc) 3Com Problems.
  8414. Date: 08 Mar 1999 17:14:01 +0100 
  8415.  
  8416. Sorry folks, didn't know you'd take it so.. erhm.. personally... I apologize
  8417. if I've been rude, but I subscribed to this mailing-list for one thing :
  8418. Tech answers to tech problems.
  8419. I didn't find anything new in all those posts. This
  8420. whining/blathering/whatever takes up time and bandwidth (brain bandwidth in
  8421. my case) and I've got enough work/trouble to be able to live without all
  8422. this noise, thank you.
  8423.  
  8424. The signal to noise ratio on this list has dropped dramatically, but well,
  8425. now I'm killing threads instead of messages.
  8426.  
  8427. -Robert
  8428.  
  8429. PS : I don't read complaints, I just trash'em, and when there are too many I
  8430. respond something so that it stops (NOT !)
  8431. PPS : your 286 story is wrong, you don't change the hw platform, try running
  8432. dos 3.3 on a mac and that's more like it... ;-)
  8433.  
  8434. > -----Original Message-----
  8435. > From:    Jeff Mcadams [SMTP:jeffm@iglou.com]
  8436. > Sent:    lundi, 8. mars 1999 17:00
  8437. > To:    usr-tc@lists.xmission.com
  8438. > Subject:    Re: (usr-tc) 3Com Problems.
  8439. > 
  8440. > Thus spake K Mitchell
  8441. > >At 04:18 PM 3/8/99 +0100, Robert von Bismarck <rvb@petrel.ch> wrote:
  8442. > >>I'm kinda sick of reading all this junk about suing 3com and
  8443. > blablabla...
  8444. > >>Stop the whining. Did you also all whine as much when you found out your
  8445. > old
  8446. > >>286 wasn't able to run win95 ? 
  8447. > 
  8448. > >  You're missing the whole point of their complaints. Their gripe isn't
  8449. > >that a 286 won't run Win'95, the gripe is that they were promised that it
  8450. > >would when they bought it, now it doesn't, and they're being told that
  8451. > >their only option is to buy something else.
  8452. > >  It's not about the Netserver's capabilities, it's about the salesman or
  8453. > >company misrepresenting the product and it's capabilities in order to
  8454. > sell it.
  8455. > 
  8456. > >At least that's what I inferred by actually reading the complaints.
  8457. > 
  8458. > Actually...I'd go even further than that....its like being told that a
  8459. > 286 would run DOS 3.3...which by all means it should be able to...and
  8460. > then being told that to run DOS 3.3 we have to upgrade to a Pentium
  8461. > because they can't fix DOS 3.3 on a 286 anymore.
  8462. > -- 
  8463. > Jeff McAdams                            Email: jeffm@iglou.com
  8464. > Head Network Administrator              Voice: (502) 966-3848
  8465. > IgLou Internet Services                        (800) 436-4456
  8466. > 
  8467. > -
  8468. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8469. >  with "unsubscribe usr-tc" in the body of the message.
  8470. >  For information on digests or retrieving files and old messages send
  8471. >  "help" to the same address.  Do not use quotes in your message.
  8472.  
  8473. -
  8474.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8475.  with "unsubscribe usr-tc" in the body of the message.
  8476.  For information on digests or retrieving files and old messages send
  8477.  "help" to the same address.  Do not use quotes in your message.
  8478.  
  8479.  
  8480. -------------------------------------------------------------------------------
  8481.  
  8482. From: K Mitchell <mitch@keyconn.net>
  8483. Subject: Re: (usr-tc) 3Com Problems.
  8484. Date: 08 Mar 1999 11:26:45 -0500
  8485.  
  8486. At 11:00 AM 3/8/99 -0500, Jeff Mcadams wrote:
  8487. >Actually...I'd go even further than that....its like being told that a
  8488. >286 would run DOS 3.3...which by all means it should be able to...and
  8489. >then being told that to run DOS 3.3 we have to upgrade to a Pentium
  8490. >because they can't fix DOS 3.3 on a 286 anymore.
  8491.  
  8492. I stand corrected  :)
  8493.  
  8494.  
  8495.  
  8496.  
  8497. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  8498. Keystone Connect                http://www.keyconn.net
  8499. Altoona, PA   814-941-5000         We Unlock the World
  8500.  
  8501.  
  8502. -
  8503.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8504.  with "unsubscribe usr-tc" in the body of the message.
  8505.  For information on digests or retrieving files and old messages send
  8506.  "help" to the same address.  Do not use quotes in your message.
  8507.  
  8508.  
  8509. -------------------------------------------------------------------------------
  8510.  
  8511. From: Jim Johnson <jim@perigee.net>
  8512. Subject: (usr-tc) Hiper Tips List?
  8513. Date: 08 Mar 1999 11:56:45 -0500
  8514.  
  8515.  
  8516. Have been reading this list for quite a while now and have learned a
  8517. great deal about the TC platform from the knowledgeable people who are
  8518. on this list.
  8519.  
  8520. I wonder if anyone has put together an overview of the steps they take
  8521. when putting a new Hiper Chassis (ARCs&HDMs) into service and whether
  8522. they would share it with the rest of us.  It seems to me from reading
  8523. this list that there are some steps which would not be in the 3COM
  8524. manuals, but which experience shows make the chassis more stable or
  8525. better able to connect with a broader range of client modems.  We still
  8526. have more connect problems to our HDMs than with our quads and maybe we
  8527. are missing some obvious ways to improve their connectivity while we
  8528. wait for all the various v.90 implementations to improve.
  8529.  
  8530. This ocurred to me while reading the thread on disabling v.42bis modem
  8531. compression.  
  8532.  
  8533. It would also be nice to know what things are being done temporarily to
  8534. work around current firmware issues.
  8535.  
  8536. Thanks,
  8537.  
  8538. Jim
  8539.  
  8540. -
  8541.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8542.  with "unsubscribe usr-tc" in the body of the message.
  8543.  For information on digests or retrieving files and old messages send
  8544.  "help" to the same address.  Do not use quotes in your message.
  8545.  
  8546.  
  8547. -------------------------------------------------------------------------------
  8548.  
  8549. From: "Randy Cosby" <dcosby@infowest.com>
  8550. Subject: (usr-tc) Ignore previous..
  8551. Date: 08 Mar 1999 11:13:47 -0700
  8552.  
  8553. Sorry about that...
  8554.  
  8555. Randy Cosby <dcosby@infowest.com>
  8556. Vice President
  8557. InfoWest Global Internet Services, Inc.
  8558. (435)674-0165   http://www.infowest.com
  8559.  
  8560.  
  8561. -
  8562.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8563.  with "unsubscribe usr-tc" in the body of the message.
  8564.  For information on digests or retrieving files and old messages send
  8565.  "help" to the same address.  Do not use quotes in your message.
  8566.  
  8567.  
  8568. -------------------------------------------------------------------------------
  8569.  
  8570. From: "Randy Cosby" <dcosby@infowest.com>
  8571. Subject: RE: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335 US for 48 ports.
  8572. Date: 08 Mar 1999 11:12:59 -0700
  8573.  
  8574. Greg,
  8575.  
  8576. I placed an order, and we're doing the wire transfer this morning.  I
  8577. noticed something on the web page about a Palm III for new customers.  Rita
  8578. said that's an old promo, but I thought I'd ask anyway.  I've got one buy my
  8579. partner is very jealous :)
  8580.  
  8581. Randy
  8582.  
  8583.  
  8584. > -----Original Message-----
  8585. > From: owner-usr-tc@lists.xmission.com
  8586. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Genge
  8587. > Sent: Wednesday, March 03, 1999 11:06 AM
  8588. > To: usr-tc@xmission.com
  8589. > Subject: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335 US for
  8590. > 48 ports.
  8591. >
  8592. >
  8593. > I checked the info on the list and found no mention of any problem posting
  8594. > items for sale on this list. I'm sure I'll be corrected if I'm wrong and I
  8595. > apologize in advance if that's the case but here goes.
  8596. >
  8597. > I noticed a couple people posting requesting to buy DSP cards. I have a
  8598. > number of 3465 Double ups available for $8335 US delivered. Single cards
  8599. > are $4200 each. These are brand new, full warranty, from a certified 3COM
  8600. > (USRobotics) VAR. We want to move these quickly so we will beat any quote
  8601. > for new cards by 5%. I also have a number or ARC Cards for $2000 each.
  8602. > Custom configs are also no problem, AC, DC, 70, 130 AMP, 1 or 2 ARC's 1-14
  8603. > DSP's, edgeserver, any combination.
  8604. >
  8605. > As for my offer for free support, I have a number of Total Control trained
  8606. > engineers on staff, including myself, and I offer free technical
  8607. > support to
  8608. > Dynavar customers and even Non-Dynavar customers to show that we can add
  8609. > value to you future purchases. We also have a full lab setup here with
  8610. > spares galore if anyone ever needs urgent replacement. We also offer
  8611. > on-site training, we just completed 2 courses each for a customer (18
  8612. > students) Installation and Management, and HiPer ARC at less than 1/2
  8613. > 3COM's on-site cost, and within 4 weeks of request.
  8614. >
  8615. > Let me know if there is anything I can do for you.
  8616. >
  8617. > Regards, Greg
  8618. >
  8619. > Gregory F. Genge, President, Dynavar Networking, Inc.
  8620. > Toll Free  877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct,
  8621. > 5005 Fax, http://www.dynavar.com
  8622. > #300, 1550 - 5th Street S.W.,  Calgary, Alberta, Canada, T2R-1K3
  8623. > Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard,
  8624. > Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran,
  8625. > Compatible,
  8626. > Microcom (Compaq), Garrett, Sonic, Cobalt.
  8627. >
  8628. > -
  8629. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8630. >  with "unsubscribe usr-tc" in the body of the message.
  8631. >  For information on digests or retrieving files and old messages send
  8632. >  "help" to the same address.  Do not use quotes in your message.
  8633. >
  8634.  
  8635.  
  8636. -
  8637.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8638.  with "unsubscribe usr-tc" in the body of the message.
  8639.  For information on digests or retrieving files and old messages send
  8640.  "help" to the same address.  Do not use quotes in your message.
  8641.  
  8642.  
  8643. -------------------------------------------------------------------------------
  8644.  
  8645. From: matthew de Jongh <matthew.de.jongh@the-spa.com>
  8646. Subject: RE: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335
  8647. Date: 08 Mar 1999 14:57:28 -0500
  8648.  
  8649. well i rec'vd a junk fax from dynavar this weekend that mentions the free
  8650. palm III
  8651.  
  8652.   matthew
  8653.  
  8654. At 11:12 AM 3/8/99 -0700, you wrote:
  8655. >Greg,
  8656. >
  8657. >I placed an order, and we're doing the wire transfer this morning.  I
  8658. >noticed something on the web page about a Palm III for new customers.  Rita
  8659. >said that's an old promo, but I thought I'd ask anyway.  I've got one buy my
  8660. >partner is very jealous :)
  8661. >
  8662. >Randy
  8663. >
  8664. >
  8665. >> -----Original Message-----
  8666. >> From: owner-usr-tc@lists.xmission.com
  8667. >> [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Greg Genge
  8668. >> Sent: Wednesday, March 03, 1999 11:06 AM
  8669. >> To: usr-tc@xmission.com
  8670. >> Subject: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335 US for
  8671. >> 48 ports.
  8672. >>
  8673. >>
  8674. >> I checked the info on the list and found no mention of any problem posting
  8675. >> items for sale on this list. I'm sure I'll be corrected if I'm wrong and I
  8676. >> apologize in advance if that's the case but here goes.
  8677. >>
  8678. >> I noticed a couple people posting requesting to buy DSP cards. I have a
  8679. >> number of 3465 Double ups available for $8335 US delivered. Single cards
  8680. >> are $4200 each. These are brand new, full warranty, from a certified 3COM
  8681. >> (USRobotics) VAR. We want to move these quickly so we will beat any quote
  8682. >> for new cards by 5%. I also have a number or ARC Cards for $2000 each.
  8683. >> Custom configs are also no problem, AC, DC, 70, 130 AMP, 1 or 2 ARC's 1-14
  8684. >> DSP's, edgeserver, any combination.
  8685. >>
  8686. >> As for my offer for free support, I have a number of Total Control trained
  8687. >> engineers on staff, including myself, and I offer free technical
  8688. >> support to
  8689. >> Dynavar customers and even Non-Dynavar customers to show that we can add
  8690. >> value to you future purchases. We also have a full lab setup here with
  8691. >> spares galore if anyone ever needs urgent replacement. We also offer
  8692. >> on-site training, we just completed 2 courses each for a customer (18
  8693. >> students) Installation and Management, and HiPer ARC at less than 1/2
  8694. >> 3COM's on-site cost, and within 4 weeks of request.
  8695. >>
  8696. >> Let me know if there is anything I can do for you.
  8697. >>
  8698. >> Regards, Greg
  8699. >>
  8700. >> Gregory F. Genge, President, Dynavar Networking, Inc.
  8701. >> Toll Free  877-Dynavar (Canada and US) (403) 571-5000 Main, 5003 Direct,
  8702. >> 5005 Fax, http://www.dynavar.com
  8703. >> #300, 1550 - 5th Street S.W.,  Calgary, Alberta, Canada, T2R-1K3
  8704. >> Ascend, 3Com (USRobotics), Alteon, Cisco, Lucent (Livingston), WatchGuard,
  8705. >> Cacheflow, Foundry, Breezecom, Redback Networks, Shiva, Adtran,
  8706. >> Compatible,
  8707. >> Microcom (Compaq), Garrett, Sonic, Cobalt.
  8708. >>
  8709. >> -
  8710. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8711. >>  with "unsubscribe usr-tc" in the body of the message.
  8712. >>  For information on digests or retrieving files and old messages send
  8713. >>  "help" to the same address.  Do not use quotes in your message.
  8714. >>
  8715. >
  8716. >
  8717. >-
  8718. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8719. > with "unsubscribe usr-tc" in the body of the message.
  8720. > For information on digests or retrieving files and old messages send
  8721. > "help" to the same address.  Do not use quotes in your message.
  8722.  
  8723.  
  8724. -
  8725.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8726.  with "unsubscribe usr-tc" in the body of the message.
  8727.  For information on digests or retrieving files and old messages send
  8728.  "help" to the same address.  Do not use quotes in your message.
  8729.  
  8730.  
  8731. -------------------------------------------------------------------------------
  8732.  
  8733. From: Dan Hollis <goemon@sasami.anime.net>
  8734. Subject: RE: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335  US for 48 ports.
  8735. Date: 08 Mar 1999 12:09:53 -0800 (PST)
  8736.  
  8737. On Mon, 8 Mar 1999, matthew de Jongh wrote:
  8738. > well i rec'vd a junk fax from dynavar this weekend that mentions the free
  8739. > palm III
  8740.  
  8741. Did you file in small claims court for dynavar's violation of USC Title 47
  8742. Sec. 227(b)(1)(C)? Under 227(b)(3)(B) youre entitled to $500.
  8743.  
  8744. Make that the most expensive fax dynavar has ever sent B)
  8745.  
  8746. -Dan
  8747.  
  8748.  
  8749. -
  8750.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8751.  with "unsubscribe usr-tc" in the body of the message.
  8752.  For information on digests or retrieving files and old messages send
  8753.  "help" to the same address.  Do not use quotes in your message.
  8754.  
  8755.  
  8756. -------------------------------------------------------------------------------
  8757.  
  8758. From: David Bolen <db3l@ans.net>
  8759. Subject: Re: (usr-tc) Pesky LEDs
  8760. Date: 08 Mar 1999 15:24:27 EST
  8761.  
  8762. Stephen Amadei <amadei@dandy.net> writes:
  8763.  
  8764. > I was poking around in the Total Control MIB lately, and noticed 
  8765. > objects for reading the status and colors of the LEDs on a chassis-wide 
  8766. > basis.  However, it's a proprietary encoding.
  8767.  
  8768. No so much proprietary (it's documented) as just a binary encoding,
  8769. since your kind of stuck with opaque object definitions for binary
  8770. stuff using SNMP's object types.  Of course, it'd probably be nice if
  8771. they stuck the encoding in the description for the object :-)
  8772.  
  8773. You should be able to find the documentation in the "Network
  8774. Management Card Parameter Reference Guide" - in the PDF copy I have
  8775. for NMC 5.0, the LED objects specifically are discussed in chapter 3
  8776. (NMC parameters), starting on page 3-36.
  8777.  
  8778. You can get the guide (NMCPRG50.PDF) off of the 3Com TotalService web
  8779. site (http://totalservice.usr.com) by searching the documentation -
  8780. last I checked it looked like it was generally accessible even as a
  8781. guest account if you don't have a service contract.
  8782.  
  8783. -- David
  8784.  
  8785. /-----------------------------------------------------------------------\
  8786.  \               David Bolen              \  Internet: db3l@ans.net    /
  8787.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  8788.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  8789. \-----------------------------------------------------------------------/
  8790.  
  8791. -
  8792.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8793.  with "unsubscribe usr-tc" in the body of the message.
  8794.  For information on digests or retrieving files and old messages send
  8795.  "help" to the same address.  Do not use quotes in your message.
  8796.  
  8797.  
  8798. -------------------------------------------------------------------------------
  8799.  
  8800. From: Mike Andrews <mandrews@termfrost.org>
  8801. Subject: (usr-tc) dsp 1.2.59 and 3com Winmodems
  8802. Date: 08 Mar 1999 15:51:22 -0500 (EST)
  8803.  
  8804. Am I the only one seeing problems with 3com Winmodems and DSP code 1.2.59?
  8805. I had 1.2.60 running, then went to 1.2.59 and the number of "takes
  8806. multiple attempts to connect" complaints shot WAY up.  This is the second
  8807. time I've tried this, and looks like the second time I'm going back to
  8808. 1.2.60.  Someone tell me it's coincidence....
  8809.  
  8810.  
  8811. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  8812. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  8813. getting beaten by the police, put down the video camera and come help me!"
  8814.  
  8815.  
  8816. -
  8817.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8818.  with "unsubscribe usr-tc" in the body of the message.
  8819.  For information on digests or retrieving files and old messages send
  8820.  "help" to the same address.  Do not use quotes in your message.
  8821.  
  8822.  
  8823. -------------------------------------------------------------------------------
  8824.  
  8825. From: Dale Hege <fhege@sover.net>
  8826. Subject: Re: (usr-tc) dsp 1.2.59 and 3com Winmodems
  8827. Date: 08 Mar 1999 16:10:58 -0500 (EST)
  8828.  
  8829. You are correct. :) I've seen this since december. There is new code
  8830. comming our soon that will fix this problem. 
  8831.  
  8832. -Dale
  8833.  
  8834. On Mon, 8 Mar 1999, Mike Andrews wrote:
  8835.  
  8836. > Am I the only one seeing problems with 3com Winmodems and DSP code 1.2.59?
  8837. > I had 1.2.60 running, then went to 1.2.59 and the number of "takes
  8838. > multiple attempts to connect" complaints shot WAY up.  This is the second
  8839. > time I've tried this, and looks like the second time I'm going back to
  8840. > 1.2.60.  Someone tell me it's coincidence....
  8841. > 
  8842. > 
  8843. > Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  8844. > mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  8845. > getting beaten by the police, put down the video camera and come help me!"
  8846. > 
  8847. > 
  8848. > -
  8849. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8850. >  with "unsubscribe usr-tc" in the body of the message.
  8851. >  For information on digests or retrieving files and old messages send
  8852. >  "help" to the same address.  Do not use quotes in your message.
  8853. > 
  8854.  
  8855.  
  8856. -
  8857.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8858.  with "unsubscribe usr-tc" in the body of the message.
  8859.  For information on digests or retrieving files and old messages send
  8860.  "help" to the same address.  Do not use quotes in your message.
  8861.  
  8862.  
  8863. -------------------------------------------------------------------------------
  8864.  
  8865. From: Bob Purdon <bobp@southcom.com.au>
  8866. Subject: RE: (usr-tc) 3Com Problems.
  8867. Date: 09 Mar 1999 08:20:20 +1100 (EST)
  8868.  
  8869.  
  8870. > if I've been rude, but I subscribed to this mailing-list for one thing
  8871. > : Tech answers to tech problems.
  8872.  
  8873. Hey, if you can give us a technical description of how to make MPIP work
  8874. properly on a *NETserver* then we'll be all ears :-)
  8875.  
  8876. Regards,
  8877.  
  8878. Bob Purdon,
  8879. Technical Manager,
  8880. Southern Internet Services.
  8881.  
  8882.  
  8883. -
  8884.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8885.  with "unsubscribe usr-tc" in the body of the message.
  8886.  For information on digests or retrieving files and old messages send
  8887.  "help" to the same address.  Do not use quotes in your message.
  8888.  
  8889.  
  8890. -------------------------------------------------------------------------------
  8891.  
  8892. From: "Peter D. Mayer" <dmayer@netwalk.com>
  8893. Subject: (usr-tc) Network sharing of TCH modems
  8894. Date: 08 Mar 1999 18:50:48 -0500
  8895.  
  8896. Does anyone know of a way to share a quad or DSP modem over the network (i.e.
  8897. use it as a device under Windows) from a TCH?  I thought I read somewhere that
  8898. you could do this, but I haven't been able to find any documentation to that
  8899. end.  If you can't do this with TCH, can anyone recommend products that can?
  8900.  
  8901. TIA for any info.
  8902.  
  8903. Peter D. Mayer
  8904. NetWalk System Administrator
  8905. dmayer@netwalk.com
  8906.  
  8907.  
  8908. -
  8909.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8910.  with "unsubscribe usr-tc" in the body of the message.
  8911.  For information on digests or retrieving files and old messages send
  8912.  "help" to the same address.  Do not use quotes in your message.
  8913.  
  8914.  
  8915. -------------------------------------------------------------------------------
  8916.  
  8917. From: Charles Hill <chill@ionet.net>
  8918. Subject: Re: (usr-tc) Network sharing of TCH modems
  8919. Date: 08 Mar 1999 18:20:53 -0600 (CST)
  8920.  
  8921.  
  8922. Look in the HiPer ARC documentation for NCSI.  Go to
  8923. http://www.networkproducts.com/ to download the client software.  Works
  8924. great for sharing a modem on the network.  I tried to fax through it once,
  8925. but there was a bug.  I never checked to see if they fixed it in a later
  8926. rev.  -CH
  8927.  
  8928. On Mon, 8 Mar 1999, Peter D. Mayer wrote:
  8929.  
  8930. > Does anyone know of a way to share a quad or DSP modem over the network (i.e.
  8931. > use it as a device under Windows) from a TCH?  I thought I read somewhere that
  8932. > you could do this, but I haven't been able to find any documentation to that
  8933. > end.  If you can't do this with TCH, can anyone recommend products that can?
  8934. > 
  8935. > TIA for any info.
  8936. > 
  8937. > Peter D. Mayer
  8938. > NetWalk System Administrator
  8939. > dmayer@netwalk.com
  8940. > 
  8941. > 
  8942. > -
  8943. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8944. >  with "unsubscribe usr-tc" in the body of the message.
  8945. >  For information on digests or retrieving files and old messages send
  8946. >  "help" to the same address.  Do not use quotes in your message.
  8947. > 
  8948.  
  8949.  
  8950. -
  8951.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8952.  with "unsubscribe usr-tc" in the body of the message.
  8953.  For information on digests or retrieving files and old messages send
  8954.  "help" to the same address.  Do not use quotes in your message.
  8955.  
  8956.  
  8957. -------------------------------------------------------------------------------
  8958.  
  8959. From: Sean Herr <Sean@YNC.NET>
  8960. Subject: (usr-tc) DSP Port Numbers
  8961. Date: 08 Mar 1999 19:19:17 -0600 
  8962.  
  8963. I have just installed our first set of DSP/ARC cards and have an issue with
  8964. port numbers in the thousands.  This would not bother me if it was 2000 -
  8965. 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a
  8966. decoder ring for this.  Does any one have an idea what to do?  I just
  8967. upgraded to the newest code on the ARC and DSP's and did a reboot.  Still no
  8968. change.
  8969.  
  8970. TIA
  8971.  
  8972. Sean Herr
  8973. @YourNET Connection, Inc.
  8974. 847-524-3910
  8975. http://www.ync.net
  8976.  
  8977. -
  8978.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  8979.  with "unsubscribe usr-tc" in the body of the message.
  8980.  For information on digests or retrieving files and old messages send
  8981.  "help" to the same address.  Do not use quotes in your message.
  8982.  
  8983.  
  8984. -------------------------------------------------------------------------------
  8985.  
  8986. From: "Jamie Orzechowski" <mhz@recorder.ca>
  8987. Subject: Re: (usr-tc) DSP Port Numbers
  8988. Date: 08 Mar 1999 20:30:33 -0500
  8989.  
  8990. I had the same problem when I first got an ARC ... I had a former 3Com tech
  8991. show me how a port number is assigned ... I can probably get it if anyone is
  8992. interested ... Something like (Slot# * 1024) - 256 ...
  8993.  
  8994. Have a Great Day!
  8995.  
  8996. Jamie Orzechowski
  8997. RipNET System Admin
  8998.  
  8999. Tel.: 613-342-3946 ext 293
  9000. Tel.: 800-267-4434 ext 293
  9001. Page.: 613-341-0883
  9002. EMail.: mhz@ripnet.com
  9003. Web.: http://www.ripnet.com
  9004. Personal.: http://www.moonchilli.com
  9005.  
  9006. -----Original Message-----
  9007. 'radiusnt@iea-software.com' <radiusnt@iea-software.com>
  9008.  
  9009.  
  9010. >I have just installed our first set of DSP/ARC cards and have an issue with
  9011. >port numbers in the thousands.  This would not bother me if it was 2000 -
  9012. >2100 but it spans from 1028 to 2365 to 3850 I am not about to build a
  9013. >decoder ring for this.  Does any one have an idea what to do?  I just
  9014. >upgraded to the newest code on the ARC and DSP's and did a reboot.  Still
  9015. no
  9016. >change.
  9017. >
  9018. >TIA
  9019. >
  9020. >Sean Herr
  9021. >@YourNET Connection, Inc.
  9022. >847-524-3910
  9023. >http://www.ync.net
  9024. >
  9025. >-
  9026. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9027. > with "unsubscribe usr-tc" in the body of the message.
  9028. > For information on digests or retrieving files and old messages send
  9029. > "help" to the same address.  Do not use quotes in your message.
  9030. >
  9031. >
  9032.  
  9033.  
  9034. -
  9035.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9036.  with "unsubscribe usr-tc" in the body of the message.
  9037.  For information on digests or retrieving files and old messages send
  9038.  "help" to the same address.  Do not use quotes in your message.
  9039.  
  9040.  
  9041. -------------------------------------------------------------------------------
  9042.  
  9043. From: Mike Andrews <mandrews@termfrost.org>
  9044. Subject: Re: (usr-tc) DSP Port Numbers
  9045. Date: 08 Mar 1999 20:35:20 -0500 (EST)
  9046.  
  9047. There is a semi-sensible formula for this -- not sensible in the fact that
  9048. you have to do this in the first place, but sensible in that you can get
  9049. the slot #/channel # from it...
  9050.  
  9051. In Perl:
  9052.  
  9053.       $portnum = $portname - 1000;
  9054.       $card = ($portnum >> 8);
  9055.       $chan = $portnum - ($card * 256);
  9056.  
  9057. First, subtract 1000 (decimal).
  9058. The lower 16 bits (8 bits, really) are the channel number.
  9059. The next 8 bits up are the card number.
  9060.  
  9061. (If you convert the port numbers into hex, it's a *lot* easier to figure
  9062. this out...)
  9063.  
  9064.  
  9065. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  9066. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  9067. getting beaten by the police, put down the video camera and come help me!"
  9068.  
  9069. On Mon, 8 Mar 1999, Sean Herr wrote:
  9070.  
  9071. > I have just installed our first set of DSP/ARC cards and have an issue with
  9072. > port numbers in the thousands.  This would not bother me if it was 2000 -
  9073. > 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a
  9074. > decoder ring for this.  Does any one have an idea what to do?  I just
  9075. > upgraded to the newest code on the ARC and DSP's and did a reboot.  Still no
  9076. > change.
  9077.  
  9078.  
  9079. -
  9080.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9081.  with "unsubscribe usr-tc" in the body of the message.
  9082.  For information on digests or retrieving files and old messages send
  9083.  "help" to the same address.  Do not use quotes in your message.
  9084.  
  9085.  
  9086. -------------------------------------------------------------------------------
  9087.  
  9088. From: ROC Services <rocsoft@itol.com>
  9089. Subject: Re: (usr-tc) DSP Port Numbers
  9090. Date: 08 Mar 1999 19:35:46 -0600 (CST)
  9091.  
  9092. On Mon, 8 Mar 1999, Sean Herr wrote:
  9093.  
  9094. > I have just installed our first set of DSP/ARC cards and have an issue with
  9095. > port numbers in the thousands.  This would not bother me if it was 2000 -
  9096. > 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a
  9097. > decoder ring for this.  Does any one have an idea what to do?  I just
  9098. > upgraded to the newest code on the ARC and DSP's and did a reboot.  Still no
  9099. > change.
  9100.  
  9101. Port number = slot*256+modem, slots being numbered starting with 0, modems
  9102. starting with 1.
  9103.  
  9104.  
  9105. -
  9106.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9107.  with "unsubscribe usr-tc" in the body of the message.
  9108.  For information on digests or retrieving files and old messages send
  9109.  "help" to the same address.  Do not use quotes in your message.
  9110.  
  9111.  
  9112. -------------------------------------------------------------------------------
  9113.  
  9114. From: Brian <signal@shreve.net>
  9115. Subject: RE: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335  US
  9116. Date: 08 Mar 1999 23:38:26 -0600 (EST)
  9117.  
  9118. On Mon, 8 Mar 1999, Dan Hollis wrote:
  9119.  
  9120. > On Mon, 8 Mar 1999, matthew de Jongh wrote:
  9121. > > well i rec'vd a junk fax from dynavar this weekend that mentions the free
  9122. > > palm III
  9123. > 
  9124. > Did you file in small claims court for dynavar's violation of USC Title 47
  9125. > Sec. 227(b)(1)(C)? Under 227(b)(3)(B) youre entitled to $500.
  9126. > 
  9127. > Make that the most expensive fax dynavar has ever sent B)
  9128. > 
  9129.  
  9130.  
  9131. Dan,
  9132.  
  9133. Every try to collect on that?  I would be interested in hearing if anyones
  9134. put the law to the test.  I get alot of junk faxes from VARs
  9135.  
  9136.  
  9137. > -Dan
  9138. > 
  9139. > 
  9140. > -
  9141. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9142. >  with "unsubscribe usr-tc" in the body of the message.
  9143. >  For information on digests or retrieving files and old messages send
  9144. >  "help" to the same address.  Do not use quotes in your message.
  9145. > 
  9146.  
  9147. Brian Feeny (BF304)     signal@shreve.net   
  9148. 318-222-2638 x 109    http://www.shreve.net/~signal      
  9149. Network Administrator   ShreveNet Inc. (ASN 11881)           
  9150.  
  9151.  
  9152. -
  9153.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9154.  with "unsubscribe usr-tc" in the body of the message.
  9155.  For information on digests or retrieving files and old messages send
  9156.  "help" to the same address.  Do not use quotes in your message.
  9157.  
  9158.  
  9159. -------------------------------------------------------------------------------
  9160.  
  9161. From: Dan Hollis <goemon@sasami.anime.net>
  9162. Subject: RE: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335  US for 48 ports.
  9163. Date: 08 Mar 1999 23:22:04 -0800 (PST)
  9164.  
  9165. On Mon, 8 Mar 1999, Brian wrote:
  9166. > On Mon, 8 Mar 1999, Dan Hollis wrote:
  9167. > > On Mon, 8 Mar 1999, matthew de Jongh wrote:
  9168. > > > well i rec'vd a junk fax from dynavar this weekend that mentions the free
  9169. > > > palm III
  9170. > > Did you file in small claims court for dynavar's violation of USC Title 47
  9171. > > Sec. 227(b)(1)(C)? Under 227(b)(3)(B) youre entitled to $500.
  9172. > > Make that the most expensive fax dynavar has ever sent B)
  9173. > Every try to collect on that?  I would be interested in hearing if anyones
  9174. > put the law to the test.  I get alot of junk faxes from VARs
  9175.  
  9176. Heres one way you can go:
  9177.  
  9178. http://x1.dejanews.com/[ST_rn=ps]/getdoc.xp?AN=362567244&CONTEXT=920964009.1053818974&hitnum=0
  9179.  
  9180. -Dan
  9181.  
  9182.  
  9183. -
  9184.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9185.  with "unsubscribe usr-tc" in the body of the message.
  9186.  For information on digests or retrieving files and old messages send
  9187.  "help" to the same address.  Do not use quotes in your message.
  9188.  
  9189.  
  9190. -------------------------------------------------------------------------------
  9191.  
  9192. From: Mark Lemmert <cto@athenet.net>
  9193. Subject: (usr-tc) Bizzare Webramp Problems
  9194. Date: 09 Mar 1999 10:31:56 -0600 (CST)
  9195.  
  9196. I have seen some weird problems with Webramps, particularly
  9197. ones that have 3com Impact IQ modems as their ISDN TA.
  9198.  
  9199. The problem is that after connecting the connection between
  9200. the webramp and the HiperARC will 'freeze'. The connection
  9201. doesn't drop and everything looks ok in terms on the bundle
  9202. and links but no data moves in or out of the connection.
  9203. It only takes around 15 minutes for this to happen.
  9204.  
  9205. I am currently running 4.1.63 -6 and 1.2.60. What code
  9206. does everyone recommend for best results with Webramps?
  9207.  
  9208. I also read on a Webramp doc somewhere that they recommend
  9209. using the command set ppp ccp_MODEMTYPE_ACCEPT none to turn
  9210. off compression on the HiperARC. Has anybody done this and
  9211. had success?
  9212.  
  9213.  
  9214.  
  9215. Mark Lemmert                           AthEnet Data Exchange
  9216. Chief Technical Officer                888-919-8700    
  9217.  
  9218.  
  9219.  
  9220.  
  9221. -
  9222.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9223.  with "unsubscribe usr-tc" in the body of the message.
  9224.  For information on digests or retrieving files and old messages send
  9225.  "help" to the same address.  Do not use quotes in your message.
  9226.  
  9227.  
  9228. -------------------------------------------------------------------------------
  9229.  
  9230. From: matthew de Jongh <matthew.de.jongh@the-spa.com>
  9231. Subject: RE: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335 
  9232. Date: 09 Mar 1999 11:56:17 -0500
  9233.  
  9234. well no, i actually didn't mind getting the fax, the bundles they had
  9235. looked pretty good, i just hate coming in the office on sunday to feed the
  9236. cats and finding our fax machine full of faxes from people i have never
  9237. requested info from.
  9238.  
  9239. between the boardwatch isp book and the damn hummer giveaways where you
  9240. have to get stamped at 30 booths we get way too much junk mail, faxes and
  9241. sales weasels calling on the phone.
  9242.  
  9243.  matthew
  9244.  
  9245. At 12:09 PM 3/8/99 -0800, you wrote:
  9246. >On Mon, 8 Mar 1999, matthew de Jongh wrote:
  9247. >> well i rec'vd a junk fax from dynavar this weekend that mentions the free
  9248. >> palm III
  9249. >
  9250. >Did you file in small claims court for dynavar's violation of USC Title 47
  9251. >Sec. 227(b)(1)(C)? Under 227(b)(3)(B) youre entitled to $500.
  9252. >
  9253. >Make that the most expensive fax dynavar has ever sent B)
  9254. >
  9255. >-Dan
  9256. >
  9257. >
  9258. >-
  9259. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9260. > with "unsubscribe usr-tc" in the body of the message.
  9261. > For information on digests or retrieving files and old messages send
  9262. > "help" to the same address.  Do not use quotes in your message.
  9263.  
  9264.  
  9265. -
  9266.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9267.  with "unsubscribe usr-tc" in the body of the message.
  9268.  For information on digests or retrieving files and old messages send
  9269.  "help" to the same address.  Do not use quotes in your message.
  9270.  
  9271.  
  9272. -------------------------------------------------------------------------------
  9273.  
  9274. From: "Billy Huddleston" <billy@nxs.net>
  9275. Subject: (usr-tc) 4.1.59-1 and STAC compression
  9276. Date: 09 Mar 1999 12:03:40 -0500
  9277.  
  9278. I've got a few customers using 3com Office Connect Hubs and they we're
  9279. having problems with the PPP stack just dieing after about 5 minutes.  I
  9280. finially tracked it down to STAC compression... I dedicded to try a
  9281. different device which supports STAC so I modify my Ascend Pipelin 75 and
  9282. enable STAC and end up having the same problem. Anyone else had this
  9283. problem?
  9284.  
  9285. Thanks, Billy Huddleston
  9286. Dataworld's Net-Express
  9287.  
  9288.  
  9289.  
  9290.  
  9291. -
  9292.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9293.  with "unsubscribe usr-tc" in the body of the message.
  9294.  For information on digests or retrieving files and old messages send
  9295.  "help" to the same address.  Do not use quotes in your message.
  9296.  
  9297.  
  9298. -------------------------------------------------------------------------------
  9299.  
  9300. From: Dan Hollis <goemon@sasami.anime.net>
  9301. Subject: RE: (usr-tc) Free suport & HiPer DSP cardsets for sale $8335   US for 48 ports.
  9302. Date: 09 Mar 1999 13:23:22 -0800 (PST)
  9303.  
  9304. On Tue, 9 Mar 1999, matthew de Jongh wrote:
  9305. > between the boardwatch isp book and the damn hummer giveaways where you
  9306. > have to get stamped at 30 booths we get way too much junk mail, faxes and
  9307. > sales weasels calling on the phone.
  9308.  
  9309. A $500 judgement against the sales weasels cant be a bad thing. I can
  9310. think of lots of wonderful things to spend $500 on.
  9311.  
  9312. -Dan
  9313.  
  9314.  
  9315. -
  9316.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9317.  with "unsubscribe usr-tc" in the body of the message.
  9318.  For information on digests or retrieving files and old messages send
  9319.  "help" to the same address.  Do not use quotes in your message.
  9320.  
  9321.  
  9322. -------------------------------------------------------------------------------
  9323.  
  9324. From: "Peter D. Mayer" <dmayer@netwalk.com>
  9325. Subject: Re: (usr-tc) DSP Port Numbers
  9326. Date: 09 Mar 1999 19:29:26 -0500
  9327.  
  9328. Rather than mucking around with formulas and stuff, I've heard you can also do
  9329. this:
  9330.  
  9331. set pbus reported_port_density 24
  9332.  
  9333. This reportedly will number the ports in a more normal fashion, though I haven't
  9334. tried it yet myself.  It should number the ports so that slot 1 will be ports
  9335. 1-24, slot 2 will be 25-48, etc.
  9336.  
  9337. Keep in mind that if you have a quad in a slot, it will still number 24 ports
  9338. for that card, but only the first 4 will be "real".  So if you have a quad modem
  9339. in slot 2, it will be numbered 25-28, a quad in slot 3 will be 49-52, etc.
  9340.  
  9341. Hope this does the trick, let me know how it works as I'll probably try it
  9342. myself in the next couple of weeks.
  9343.  
  9344. Peter D. Mayer
  9345. NetWalk System Administrator
  9346. dmayer@netwalk.com
  9347.  
  9348. ----- Original Message -----
  9349. Cc: <usr-tc@lists.xmission.com>
  9350. Sent: Monday, March 08, 1999 8:35 PM
  9351.  
  9352.  
  9353. >On Mon, 8 Mar 1999, Sean Herr wrote:
  9354. >
  9355. >> I have just installed our first set of DSP/ARC cards and have an issue with
  9356. >> port numbers in the thousands.  This would not bother me if it was 2000 -
  9357. >> 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a
  9358. >> decoder ring for this.  Does any one have an idea what to do?  I just
  9359. >> upgraded to the newest code on the ARC and DSP's and did a reboot.  Still no
  9360. >> change.
  9361. >
  9362. >Port number = slot*256+modem, slots being numbered starting with 0, modems
  9363. >starting with 1.
  9364. >
  9365. >
  9366. >-
  9367. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9368. > with "unsubscribe usr-tc" in the body of the message.
  9369. > For information on digests or retrieving files and old messages send
  9370. > "help" to the same address.  Do not use quotes in your message.
  9371. >
  9372.  
  9373.  
  9374. -
  9375.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9376.  with "unsubscribe usr-tc" in the body of the message.
  9377.  For information on digests or retrieving files and old messages send
  9378.  "help" to the same address.  Do not use quotes in your message.
  9379.  
  9380.  
  9381. -------------------------------------------------------------------------------
  9382.  
  9383. From: "Randy Cosby" <dcosby@infowest.com>
  9384. Subject: (usr-tc) 4.1.59-6 Progress
  9385. Date: 09 Mar 1999 17:31:41 -0700
  9386.  
  9387. So far, 4.1.59-6 is working very well on the HiperArc, on a combination of 6
  9388. HiperDSP and Quad boxes.   I was getting some problems with IP addresses not
  9389. being released with 4.1.59-1, haven't seen that so far (fingers crossed).
  9390. I didn't have problems with lost IP pools that Aaron Nabil experienced on
  9391. the upgrade.  I wrote them down and did one extra "save all" before
  9392. rebooting witht the new code just to be sure.
  9393.  
  9394. Now, if we can get a few more fixes in the HiperDSP code, we'll really be in
  9395. business!
  9396.  
  9397. Randy Cosby <dcosby@infowest.com>
  9398. Vice President
  9399. InfoWest Global Internet Services, Inc.
  9400. (435)674-0165   http://www.infowest.com
  9401.  
  9402.  
  9403. -
  9404.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9405.  with "unsubscribe usr-tc" in the body of the message.
  9406.  For information on digests or retrieving files and old messages send
  9407.  "help" to the same address.  Do not use quotes in your message.
  9408.  
  9409.  
  9410. -------------------------------------------------------------------------------
  9411.  
  9412. From: "Jamie Orzechowski" <mhz@recorder.ca>
  9413. Subject: Re: (usr-tc) DSP Port Numbers
  9414. Date: 09 Mar 1999 20:42:53 -0500
  9415.  
  9416. seems to work for me ...
  9417.  
  9418. Have a Great Day!
  9419.  
  9420. Jamie Orzechowski
  9421. RipNET System Admin
  9422.  
  9423. Tel.: 613-342-3946 ext 293
  9424. Tel.: 800-267-4434 ext 293
  9425. Page.: 613-341-0883
  9426. EMail.: mhz@ripnet.com
  9427. Web.: http://www.ripnet.com
  9428. Personal.: http://www.moonchilli.com
  9429.  
  9430. -----Original Message-----
  9431.  
  9432.  
  9433. >Rather than mucking around with formulas and stuff, I've heard you can also
  9434. do
  9435. >this:
  9436. >
  9437. >set pbus reported_port_density 24
  9438. >
  9439. >This reportedly will number the ports in a more normal fashion, though I
  9440. haven't
  9441. >tried it yet myself.  It should number the ports so that slot 1 will be
  9442. ports
  9443. >1-24, slot 2 will be 25-48, etc.
  9444. >
  9445. >Keep in mind that if you have a quad in a slot, it will still number 24
  9446. ports
  9447. >for that card, but only the first 4 will be "real".  So if you have a quad
  9448. modem
  9449. >in slot 2, it will be numbered 25-28, a quad in slot 3 will be 49-52, etc.
  9450. >
  9451. >Hope this does the trick, let me know how it works as I'll probably try it
  9452. >myself in the next couple of weeks.
  9453. >
  9454. >Peter D. Mayer
  9455. >NetWalk System Administrator
  9456. >dmayer@netwalk.com
  9457. >
  9458. >----- Original Message -----
  9459. >From: ROC Services <rocsoft@itol.com>
  9460. >To: Sean Herr <Sean@YNC.NET>
  9461. >Cc: <usr-tc@lists.xmission.com>
  9462. >Sent: Monday, March 08, 1999 8:35 PM
  9463. >Subject: Re: (usr-tc) DSP Port Numbers
  9464. >
  9465. >
  9466. >>On Mon, 8 Mar 1999, Sean Herr wrote:
  9467. >>
  9468. >>> I have just installed our first set of DSP/ARC cards and have an issue
  9469. with
  9470. >>> port numbers in the thousands.  This would not bother me if it was
  9471. 2000 -
  9472. >>> 2100 but it spans from 1028 to 2365 to 3850 I am not about to build a
  9473. >>> decoder ring for this.  Does any one have an idea what to do?  I just
  9474. >>> upgraded to the newest code on the ARC and DSP's and did a reboot.
  9475. Still no
  9476. >>> change.
  9477. >>
  9478. >>Port number = slot*256+modem, slots being numbered starting with 0, modems
  9479. >>starting with 1.
  9480. >>
  9481. >>
  9482. >>-
  9483. >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9484. >> with "unsubscribe usr-tc" in the body of the message.
  9485. >> For information on digests or retrieving files and old messages send
  9486. >> "help" to the same address.  Do not use quotes in your message.
  9487. >>
  9488. >
  9489. >
  9490. >-
  9491. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9492. > with "unsubscribe usr-tc" in the body of the message.
  9493. > For information on digests or retrieving files and old messages send
  9494. > "help" to the same address.  Do not use quotes in your message.
  9495. >
  9496. >
  9497.  
  9498.  
  9499. -
  9500.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9501.  with "unsubscribe usr-tc" in the body of the message.
  9502.  For information on digests or retrieving files and old messages send
  9503.  "help" to the same address.  Do not use quotes in your message.
  9504.  
  9505.  
  9506. -------------------------------------------------------------------------------
  9507.  
  9508. From: "Matt Harper" <Matt_Harper@mw.3com.com>
  9509. Subject: Re: (usr-tc) 4.1.59-6 Progress
  9510. Date: 09 Mar 1999 21:36:50 -0600
  9511.  
  9512.  
  9513.  
  9514. FYI -
  9515.  
  9516. The reported issue of "lost IP pools" could be the result of the following:
  9517.  
  9518. IP pools and static routes on the ARC are installed after the system has been
  9519. booted for ~15-20 seconds.
  9520. (Type "list ip pool" right after a boot at the prompt and you'll see that this
  9521. is the case).
  9522. Wait a bit, and you'll see the IP pools wink into existance.
  9523.  
  9524. Anyhow, if you happen to perform a "save all" before the system has installed
  9525. the
  9526. IP pools, then you would possibly loose the pools.  There is an open MR on this
  9527. issue - MR9119.
  9528.  
  9529. -- Matt
  9530.  
  9531.  
  9532.  
  9533.  
  9534.  
  9535.  
  9536. "Randy Cosby" <dcosby@infowest.com> on 03/09/99 06:31:41 PM
  9537.  
  9538. Please respond to usr-tc@lists.xmission.com
  9539.  
  9540. cc:    (Matt Harper/MW/US/3Com)
  9541.  
  9542.  
  9543.  
  9544.  
  9545. So far, 4.1.59-6 is working very well on the HiperArc, on a combination of 6
  9546. HiperDSP and Quad boxes.   I was getting some problems with IP addresses not
  9547. being released with 4.1.59-1, haven't seen that so far (fingers crossed).
  9548. I didn't have problems with lost IP pools that Aaron Nabil experienced on
  9549. the upgrade.  I wrote them down and did one extra "save all" before
  9550. rebooting witht the new code just to be sure.
  9551.  
  9552. Now, if we can get a few more fixes in the HiperDSP code, we'll really be in
  9553. business!
  9554.  
  9555. Randy Cosby <dcosby@infowest.com>
  9556. Vice President
  9557. InfoWest Global Internet Services, Inc.
  9558. (435)674-0165   http://www.infowest.com
  9559.  
  9560.  
  9561. -
  9562.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9563.  with "unsubscribe usr-tc" in the body of the message.
  9564.  For information on digests or retrieving files and old messages send
  9565.  "help" to the same address.  Do not use quotes in your message.
  9566.  
  9567.  
  9568.  
  9569.  
  9570.  
  9571.  
  9572.  
  9573.  
  9574. -
  9575.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9576.  with "unsubscribe usr-tc" in the body of the message.
  9577.  For information on digests or retrieving files and old messages send
  9578.  "help" to the same address.  Do not use quotes in your message.
  9579.  
  9580.  
  9581. -------------------------------------------------------------------------------
  9582.  
  9583. From: usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox)
  9584. Subject: (usr-tc) Timing on USR Security and Accounting Server reports
  9585. Date: 09 Mar 1999 22:39:26 -0500
  9586.  
  9587. Has anyone seen any problems with the USR Accounting Reports
  9588. with regards to Duration time timing? I've been looking over
  9589. some of our "high hours" clients, and noticed a lot of 
  9590. overlapping times, even though they're from the same phone
  9591. number. I'm adding the Duration time to the connect time (by 
  9592. hand!) to get a disconnect time. Some of our clients are 
  9593. clearly logging in concurrently from two computers if these
  9594. times are correct. 
  9595.  
  9596. We're running Security, Accounting, radius server version 4.3 
  9597. from USR. The report is a new layout. The "Duration" formula
  9598. was copied from the example "Sample Billing" report provided
  9599. by USR. 
  9600.  
  9601. Thanks! 
  9602.  
  9603. Steve 
  9604.  
  9605.  
  9606. -
  9607.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9608.  with "unsubscribe usr-tc" in the body of the message.
  9609.  For information on digests or retrieving files and old messages send
  9610.  "help" to the same address.  Do not use quotes in your message.
  9611.  
  9612.  
  9613. -------------------------------------------------------------------------------
  9614.  
  9615. From: Yevgeniy Kruglov <shar@cifnet.com>
  9616. Subject: (usr-tc) dialout from tc
  9617. Date: 09 Mar 1999 22:43:12 -0600
  9618.  
  9619. Does anybody have any experience using hiper platform to dial out, using
  9620. telnet? We have an application that reqires 7 bit Even Parity and right
  9621. now we got Netserver 8I for this purpose (only has 8 bit no parity). The
  9622. main problem is if telnet session gets closed before the modem disconnects
  9623. the modem interface is being reported as in use, but Netserver would let
  9624. you to telnet to that modem again even it's not usable until you reset
  9625. that interface from CLI. How the Hiper Arc works in this case, would the
  9626. modem drop the connection if telnet session is broken, and is there such
  9627. thing as round-robin dialout within one modem group?
  9628.  
  9629. Thanks!
  9630.  
  9631. Yevgeniy
  9632.  
  9633. -
  9634.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9635.  with "unsubscribe usr-tc" in the body of the message.
  9636.  For information on digests or retrieving files and old messages send
  9637.  "help" to the same address.  Do not use quotes in your message.
  9638.  
  9639.  
  9640. -------------------------------------------------------------------------------
  9641.  
  9642. From: MegaZone <megazone@megazone.org>
  9643. Subject: Re: (usr-tc) HiPerARC code for Webramp/Macintosh and related issues. (4.1.59-6)
  9644. Date: 09 Mar 1999 23:20:49 -0800 (PST)
  9645.  
  9646. Once upon a time Pete Ashdown shaped the electrons to say...
  9647. >I was interested to see that MPPP now has a global switch.  What is the
  9648. >proper Framed-Protocol to use for MPPP?  I have a customer who is
  9649.  
  9650. Framed-Protocol = PPP
  9651.  
  9652. Anything else is not RFC compliant.
  9653.  
  9654. If you don't want to allow multiple ports, then add:
  9655.  
  9656. Port-Limit = 1
  9657.  
  9658. -MZ
  9659. -- 
  9660. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  9661. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  9662. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  9663. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  9664. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  9665.  
  9666. -
  9667.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9668.  with "unsubscribe usr-tc" in the body of the message.
  9669.  For information on digests or retrieving files and old messages send
  9670.  "help" to the same address.  Do not use quotes in your message.
  9671.  
  9672.  
  9673. -------------------------------------------------------------------------------
  9674.  
  9675. From: MegaZone <megazone@megazone.org>
  9676. Subject: Re: (usr-tc) 3Com Problems.
  9677. Date: 09 Mar 1999 23:26:04 -0800 (PST)
  9678.  
  9679. Once upon a time Robert von Bismarck shaped the electrons to say...
  9680. >The PM2-30 sitting in the closet is a 30 port. It's got an AMD Am386dx-40
  9681. >and a mind-boggling 4 megs of RAM.
  9682. >
  9683. >Well it's an OEM by Cayman Systems, called "GatorAccess" but the mboard is
  9684. >definitely marked Livingston.
  9685.  
  9686. They're all but identical - different ROM.  In fact, back around 1995 
  9687. when Cayman got all messed up, Livingston offered a 'refurb/upgrade' for
  9688. around $900 where they'd take the unit, clean it, test it, swap out
  9689. the ROM, and ship it back with Livingston support, warranty, etc.  I
  9690. don't know if they'd still do that.
  9691.  
  9692. The PM-3 can do 3 T1 (2 on the main board, and a WAN card) and it has a
  9693. 486DX2-66 as I recall, and 4MB of RAM.  And it'll do OSPF.  Give it
  9694. 16MB or more and it'll do BGP happily.
  9695.  
  9696. -MZ
  9697. -- 
  9698. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  9699. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  9700. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  9701. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  9702. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  9703.  
  9704. -
  9705.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9706.  with "unsubscribe usr-tc" in the body of the message.
  9707.  For information on digests or retrieving files and old messages send
  9708.  "help" to the same address.  Do not use quotes in your message.
  9709.  
  9710.  
  9711. -------------------------------------------------------------------------------
  9712.  
  9713. From: MegaZone <megazone@megazone.org>
  9714. Subject: Re: (usr-tc) 3Com Problems.
  9715. Date: 09 Mar 1999 23:32:03 -0800 (PST)
  9716.  
  9717. Once upon a time Robert von Bismarck shaped the electrons to say...
  9718. >also happens with servers, even with NAS's. The 486 has outlived it's life,
  9719. >welcome to the PPC.
  9720.  
  9721. But this is BULLSHIT.  Wake up - the NetServer *HARDWARE* has plenty of
  9722. power, as long as the OS isn't crap.  They only need a PPC because Pilgrim
  9723. isn't efficient enough to use the 486-100.
  9724.  
  9725. A PPC is overpriced, overkill for a small-to-medium NAS.  And that is what
  9726. many people need - now AND tomorrow.  If you think xDSL, etc, is going to
  9727. be ubiquitous tomorrow, you're high.  Modems/ISDN will remain for a number
  9728. of years.  And spending money on unnecessary hardware for a rural POP is
  9729. bad business, anyway you slice it.  The NetServer TCs could server on
  9730. for many years yet - if only 3Com knew how to code an OS.  But just look
  9731. at how bad the bloated ComOS by the end.  It was bigger than the original,
  9732. took 4 times the RAM, and did LESS.
  9733.  
  9734. >Upgrade is the power-word. In the ISP business it's "do or die". You want to
  9735.  
  9736. This is moronic.  You could also use a vendor who knows how to write an
  9737. OS and doesn't bloat it so fast they ARTIFICIALLY obsolete perfectly good
  9738. HW.  It sure sounds like you've been brainwashed by the M$/Intel mentality.
  9739.  
  9740. -MZ
  9741. -- 
  9742. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  9743. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  9744. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  9745. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  9746. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  9747.  
  9748. -
  9749.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9750.  with "unsubscribe usr-tc" in the body of the message.
  9751.  For information on digests or retrieving files and old messages send
  9752.  "help" to the same address.  Do not use quotes in your message.
  9753.  
  9754.  
  9755. -------------------------------------------------------------------------------
  9756.  
  9757. From: MegaZone <megazone@megazone.org>
  9758. Subject: Re: (usr-tc) Seimens in talks to buy 3Com Unit
  9759. Date: 09 Mar 1999 23:41:41 -0800 (PST)
  9760.  
  9761. Once upon a time Charles Hill shaped the electrons to say...
  9762. >I've heard the rumor about 3Com offloading the Total Control unit a few
  9763. >times now, so I'm starting to believe it.  This Siemens story makes me
  9764. >think it's going to happen.
  9765.  
  9766. Sounds reasonable.
  9767.  
  9768. Nortel grabbed Aptis and Bay, Lucent grabbed Livingston and Ascend,
  9769. Ericsson grabbed ACC, Alcatel just grabbed Assured Access.  Why not
  9770. Siemens going after 3Com, or part thereof?
  9771.  
  9772. Don't they already make a VOIP gateway based on the HiPer?
  9773.  
  9774. >I hope the deal is beneficial for everyone.  Maybe Siemens will commit
  9775. >more resources to developing the Total Control products than 3Com has. 
  9776. >Higher density and DS3 ingress would be nice.
  9777.  
  9778. Do you think they can re-double the density for T3?
  9779.  
  9780. -MZ
  9781. -- 
  9782. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  9783. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  9784. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  9785. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  9786. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  9787.  
  9788. -
  9789.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9790.  with "unsubscribe usr-tc" in the body of the message.
  9791.  For information on digests or retrieving files and old messages send
  9792.  "help" to the same address.  Do not use quotes in your message.
  9793.  
  9794.  
  9795. -------------------------------------------------------------------------------
  9796.  
  9797. From: MegaZone <megazone@megazone.org>
  9798. Subject: Re: (usr-tc) IEA , using it from Radius
  9799. Date: 09 Mar 1999 23:44:49 -0800 (PST)
  9800.  
  9801. Once upon a time d baud shaped the electrons to say...
  9802. >Now this is great, but I need to use this for particular users from
  9803. >RADIUS, so I added in the dictionnary the following:
  9804. >ATTRIBUTE    IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr
  9805.  
  9806. You're doing the wrong thing.  This is NOT a RADIUS attribute, this is a
  9807. Vendor Specific Attribute.
  9808.  
  9809. So:
  9810. 1. You need a RADIUS server that not only understands VSAs, but that
  9811. understands 3Com's oddball format.  (3Com chose not to follow the format
  9812. recommended by the RFC, so some VSA supporting servers still don't do
  9813. 3Com VSAs.)
  9814. 2. You need to enter this into the RADIUS server's dictionary in the 
  9815. format that server uses for VSAs.
  9816.  
  9817. As a tip, the free Cistron RADIUS server does support 3Com VSAs.
  9818.  
  9819. >Oh BTW for those who don't know what IEA is, it stands for Internet
  9820.  
  9821. That's going to be so annoying, as IEA Software is a major RADIUS 
  9822. server vendor - with RadiusNT and Emerald.
  9823.  
  9824. -MZ
  9825. -- 
  9826. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  9827. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  9828. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  9829. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  9830. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  9831.  
  9832. -
  9833.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9834.  with "unsubscribe usr-tc" in the body of the message.
  9835.  For information on digests or retrieving files and old messages send
  9836.  "help" to the same address.  Do not use quotes in your message.
  9837.  
  9838.  
  9839. -------------------------------------------------------------------------------
  9840.  
  9841. From: Matthew Opoka <phantom@magnolia.net>
  9842. Subject: Re: (usr-tc) Bizzare Webramp Problems
  9843. Date: 10 Mar 1999 02:46:43 -0600
  9844.  
  9845. Same here on my WebRamp 310i.  It is worse with VJ and/or stac turned on
  9846. in the WebRamp.  Running 4.1.59-6 ARC 4.1.59 DSP.
  9847.  
  9848.  
  9849. Mark Lemmert wrote:
  9850. > 
  9851. > I have seen some weird problems with Webramps, particularly
  9852. > ones that have 3com Impact IQ modems as their ISDN TA.
  9853. > 
  9854. > The problem is that after connecting the connection between
  9855. > the webramp and the HiperARC will 'freeze'. The connection
  9856. > doesn't drop and everything looks ok in terms on the bundle
  9857. > and links but no data moves in or out of the connection.
  9858. > It only takes around 15 minutes for this to happen.
  9859. > 
  9860. > I am currently running 4.1.63 -6 and 1.2.60. What code
  9861. > does everyone recommend for best results with Webramps?
  9862. > 
  9863. > I also read on a Webramp doc somewhere that they recommend
  9864. > using the command set ppp ccp_MODEMTYPE_ACCEPT none to turn
  9865. > off compression on the HiperARC. Has anybody done this and
  9866. > had success?
  9867. > 
  9868. > Mark Lemmert                           AthEnet Data Exchange
  9869. > Chief Technical Officer                888-919-8700
  9870. > 
  9871. > -
  9872. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9873. >  with "unsubscribe usr-tc" in the body of the message.
  9874. >  For information on digests or retrieving files and old messages send
  9875. >  "help" to the same address.  Do not use quotes in your message.
  9876.  
  9877. -
  9878.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9879.  with "unsubscribe usr-tc" in the body of the message.
  9880.  For information on digests or retrieving files and old messages send
  9881.  "help" to the same address.  Do not use quotes in your message.
  9882.  
  9883.  
  9884. -------------------------------------------------------------------------------
  9885.  
  9886. From: Robert von Bismarck <rvb@petrel.ch>
  9887. Subject: RE: (usr-tc) 3Com Problems.
  9888. Date: 10 Mar 1999 10:15:50 +0100
  9889.  
  9890.     Even the PM2 does BGP... but it's BGP3 which is pretty useless.
  9891.  
  9892. > -----Original Message-----
  9893. > From:    MegaZone [SMTP:megazone@megazone.org]
  9894. > Sent:    mercredi, 10. mars 1999 08:26
  9895. > To:    usr-tc@lists.xmission.com
  9896. > Subject:    Re: (usr-tc) 3Com Problems.
  9897. > 
  9898. > The PM-3 can do 3 T1 (2 on the main board, and a WAN card) and it has a
  9899. > 486DX2-66 as I recall, and 4MB of RAM.  And it'll do OSPF.  Give it
  9900. > 16MB or more and it'll do BGP happily.
  9901. > 
  9902. > -MZ
  9903. > -- 
  9904. > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/>
  9905. > X*=-
  9906. > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer,
  9907. > me..
  9908. > Join ISP/C Internet Service Providers' Consortium
  9909. > <URL:http://www.ispc.org/>
  9910. > "A little nonsense now and then, is relished by the wisest men"
  9911. > 781-788-0130
  9912. > <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail
  9913. > Discordia!
  9914. > 
  9915. > 
  9916.  
  9917. -
  9918.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9919.  with "unsubscribe usr-tc" in the body of the message.
  9920.  For information on digests or retrieving files and old messages send
  9921.  "help" to the same address.  Do not use quotes in your message.
  9922.  
  9923.  
  9924. -------------------------------------------------------------------------------
  9925.  
  9926. From: Stephen Amadei <amadei@dandy.net>
  9927. Subject: Re: (usr-tc) IEA , using it from Radius
  9928. Date: 10 Mar 1999 04:42:17 -0500 (EST)
  9929.  
  9930. On Tue, 9 Mar 1999, MegaZone wrote:
  9931.  
  9932.  
  9933. > 2. You need to enter this into the RADIUS server's dictionary in the 
  9934. > format that server uses for VSAs.
  9935. > 
  9936. > As a tip, the free Cistron RADIUS server does support 3Com VSAs.
  9937.  
  9938. O.K... the muddy water is starting to clear here... We run an OS/2 port of 
  9939. Cistron RADIUS (easy access to our DB2 server).  I tried setting up 3Com's
  9940. VSA's in my dictionary file, using the complaints RADIUS had when it
  9941. encountered an unknown attribute.  My dictionary.3com:
  9942.  
  9943. ATTRIBUTE       Vendor-Specific        26    string
  9944. ATTRIBUTE    Acct-Multi-Session-ID    50    string
  9945. ATTRIBUTE    Acct-Link-Count        51    string
  9946.  
  9947. I used to have more, as specificed in 3Com's RADIUS guide... but they were
  9948. never used, and they got tossed out during an upgrade long ago.
  9949.  
  9950. However, the attributes still come up null:
  9951.  
  9952. Mon Mar  8 16:08:27 1999
  9953.     User-Name = "steve"
  9954.     NAS-IP-Address = 209.101.140.2
  9955.     Acct-Status-Type = Start
  9956.     Acct-Session-Id = "2558"
  9957.     Acct-Delay-Time = 0
  9958.     Acct-Authentic = RADIUS
  9959.     Service-Type = Framed-User
  9960.     NAS-Port-Type = Async
  9961.     NAS-Port-Id = 1796
  9962.     Vendor-Specific = ""
  9963.     Vendor-Specific = ""
  9964.     Vendor-Specific = ""
  9965.     Vendor-Specific = ""
  9966.     Vendor-Specific = ""
  9967.     Vendor-Specific = ""
  9968.     Calling-Station-Id = "6095550773"
  9969.     Called-Station-Id = "5555555"
  9970.     Vendor-Specific = ""
  9971.     Vendor-Specific = ""
  9972.     Vendor-Specific = ""
  9973.     Vendor-Specific = ""
  9974.     Framed-Protocol = PPP
  9975.     Framed-IP-Address = 209.101.140.23
  9976.     Timestamp = 920927307
  9977.     Request-Authenticator = Unverified
  9978.  
  9979. Is there something else I need to add to my dictionary to reveal these
  9980. VSAs?  Is the info in these VSAs useful?  I can't imagine it is not... ;-)
  9981.  
  9982. Thanx in advance.
  9983.  
  9984.                     ----Steve
  9985. Stephen Amadei
  9986. Director of MIS
  9987. Dandy Connections, Inc.
  9988. Atlantic City, NJ
  9989.  
  9990.  
  9991. -
  9992.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  9993.  with "unsubscribe usr-tc" in the body of the message.
  9994.  For information on digests or retrieving files and old messages send
  9995.  "help" to the same address.  Do not use quotes in your message.
  9996.  
  9997.  
  9998. -------------------------------------------------------------------------------
  9999.  
  10000. From: MegaZone <megazone@megazone.org>
  10001. Subject: Re: (usr-tc) 3Com Problems.
  10002. Date: 10 Mar 1999 01:25:16 -0800 (PST)
  10003.  
  10004. Once upon a time Robert von Bismarck shaped the electrons to say...
  10005. >    Even the PM2 does BGP... but it's BGP3 which is pretty useless.
  10006.  
  10007. The PM-2 does RIP and OSPFv2 with NSSA.  No BGP.
  10008.  
  10009. The only PortMaster products which do BGP are the PM-3, PM-4, and IRX.
  10010. All do BGP4.  Actually, the implementation supports many of the 
  10011. supplimental RFCs, and some of the draft material for BGP5.
  10012.  
  10013. All PortMasters (well, except for the ancient PM-11 and IR4) support RIPv1
  10014. and OSPFv2 with NSSA, the above three do BGP as well.  Lucent is adding
  10015. RIPv2 to the PM-4 in ComOS 4.1, a reversal on Livingston's stance on 
  10016. supporting OSPF but not RIPv2 since OSPF is superior.  No definite word
  10017. yet on if that means the other products will also receive RIPv2 in 3.9.
  10018.  
  10019. -MZ
  10020. -- 
  10021. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  10022. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  10023. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  10024. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  10025. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  10026.  
  10027. -
  10028.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10029.  with "unsubscribe usr-tc" in the body of the message.
  10030.  For information on digests or retrieving files and old messages send
  10031.  "help" to the same address.  Do not use quotes in your message.
  10032.  
  10033.  
  10034. -------------------------------------------------------------------------------
  10035.  
  10036. From: Robert von Bismarck <rvb@petrel.ch>
  10037. Subject: RE: (usr-tc) 3Com Problems.
  10038. Date: 10 Mar 1999 10:50:50 +0100
  10039.  
  10040. ok.
  10041.  
  10042. Our opinions differ and that's fine. Let me explain the situation I live
  10043. with so you'll understand my points better.
  10044.  
  10045. We have 107 "virtual" PoPs provided by our telco. This means that we have
  10046. 107 local numbers for 107 different tariff zones. All the numbers are
  10047. forwarded to two "MegaPoPs" in which we store our equipment.
  10048. We have 700 ports in one location, and 300 in another. We do not have any
  10049. other Pop with dial-up access. We do have other Pops for Frame-Relay, DSL
  10050. and snych leased lines.
  10051. I think that this kind of "back-hauling" telephone calls will become more
  10052. and more used by everyone (be it carriers, ISP, etc...).
  10053. I don't know if this kind of operation is possible in the states, or
  10054. elsewhere (I know for example that it's impossible to do in France).
  10055.  
  10056. This has lots of advantages and disadvantages versus smaller PoP's :
  10057. - All the equipment is in a few locations, you don't have to travel miles to
  10058. reboot a board
  10059. - The modems are better used
  10060. - If one board fails, there's not one Pop that'll sound busy, but only one
  10061. ring in twenty
  10062. - You don't need multiple leased lines going to one central site, you just
  10063. order 10M/s of ATM to your internet access and you're fine.
  10064. - As your megapop is in the telco's racks, you're right next door to their
  10065. engineers, who can help if you got trouble with protocol analyzers, etc...
  10066. - The equipment is all on the same switch, if that fails, you're out of
  10067. business for a while
  10068. - There's only one line going out, if that fails, you're in trouble
  10069. - There's one big router, failure = trouble (better have those smartnet 24/7
  10070. contracts ready)
  10071. - Insurance is lighter (only one building, and you share costs with the
  10072. telco)
  10073. - There's only two UPS's per POP (thank God for redundant Power Supplies)
  10074.  
  10075. With this trend, I see no more use for small Pops with 30 or so lines except
  10076. as RAS service for the employees of a big company, or a very local ISP
  10077. who'll probably have not very many customers, and a very limited Net access
  10078. (remember the BBS's of old...).
  10079.  
  10080. I believe the garage-family-business ISP time is over in Europe.
  10081.  
  10082. I'm not really aware of what the situation is like in the USA, but I don't
  10083. think it's really very different.
  10084.  
  10085. This is the situation, and I hope you now understand why I think the
  10086. Netserver has outlived it's useful life (even with bloated OS and blablabla)
  10087.  
  10088. Robert
  10089.  
  10090. PS : I have not been brainwashed by M$/Intel (even though we use MS Exchange
  10091. for e-mail). Our production equipment is not running MS or Intel stuff
  10092. except Frontpage server extensions ;-)
  10093.  
  10094. > -----Original Message-----
  10095. > From:    MegaZone [SMTP:megazone@megazone.org]
  10096. > Sent:    mercredi, 10. mars 1999 08:32
  10097. > To:    usr-tc@lists.xmission.com
  10098. > Subject:    Re: (usr-tc) 3Com Problems.
  10099. > 
  10100. > Once upon a time Robert von Bismarck shaped the electrons to say...
  10101. > >also happens with servers, even with NAS's. The 486 has outlived it's
  10102. > life,
  10103. > >welcome to the PPC.
  10104. > 
  10105. > But this is BULLSHIT.  Wake up - the NetServer *HARDWARE* has plenty of
  10106. > power, as long as the OS isn't crap.  They only need a PPC because Pilgrim
  10107. > isn't efficient enough to use the 486-100.
  10108. > 
  10109. > A PPC is overpriced, overkill for a small-to-medium NAS.  And that is what
  10110. > many people need - now AND tomorrow.  If you think xDSL, etc, is going to
  10111. > be ubiquitous tomorrow, you're high.  Modems/ISDN will remain for a number
  10112. > of years.  And spending money on unnecessary hardware for a rural POP is
  10113. > bad business, anyway you slice it.  The NetServer TCs could server on
  10114. > for many years yet - if only 3Com knew how to code an OS.  But just look
  10115. > at how bad the bloated ComOS by the end.  It was bigger than the original,
  10116. > took 4 times the RAM, and did LESS.
  10117. > 
  10118. > >Upgrade is the power-word. In the ISP business it's "do or die". You want
  10119. > to
  10120. > 
  10121. > This is moronic.  You could also use a vendor who knows how to write an
  10122. > OS and doesn't bloat it so fast they ARTIFICIALLY obsolete perfectly good
  10123. > HW.  It sure sounds like you've been brainwashed by the M$/Intel
  10124. > mentality.
  10125. > 
  10126. > -MZ
  10127. > -- 
  10128. > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/>
  10129. > X*=-
  10130. > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer,
  10131. > me..
  10132. > Join ISP/C Internet Service Providers' Consortium
  10133. > <URL:http://www.ispc.org/>
  10134. > "A little nonsense now and then, is relished by the wisest men"
  10135. > 781-788-0130
  10136. > <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail
  10137. > Discordia!
  10138. > 
  10139. > -
  10140. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10141. >  with "unsubscribe usr-tc" in the body of the message.
  10142. >  For information on digests or retrieving files and old messages send
  10143. >  "help" to the same address.  Do not use quotes in your message.
  10144.  
  10145. -
  10146.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10147.  with "unsubscribe usr-tc" in the body of the message.
  10148.  For information on digests or retrieving files and old messages send
  10149.  "help" to the same address.  Do not use quotes in your message.
  10150.  
  10151.  
  10152. -------------------------------------------------------------------------------
  10153.  
  10154. From: Robert von Bismarck <rvb@petrel.ch>
  10155. Subject: RE: (usr-tc) 3Com Problems.
  10156. Date: 10 Mar 1999 10:56:38 +0100
  10157.  
  10158. Huh ? explain this to me then, (it's an old PM2-e refurbished cayman we use
  10159. for RS-232 console access)
  10160.  
  10161. ComOS - Livingston PortMaster
  10162.  
  10163. login: !root
  10164. Password:
  10165. SBL-PM1> sh glo
  10166.  
  10167. [ lots of config stuff deleted ]
  10168.  
  10169.   Disabled Modules: OSPF BGP
  10170. SBL-PM1> version
  10171. Livingston PortMaster PM-2e ComOS 3.7.2
  10172. System uptime is 126 days 16 hours 3 minutes
  10173. SBL-PM1> exit
  10174.  
  10175. Why mention it, if it's not inside or planned ? (I never tried to use it as
  10176. it would have been pretty useless for me)
  10177.  
  10178. Robert
  10179.  
  10180. > -----Original Message-----
  10181. > From:    MegaZone [SMTP:megazone@megazone.org]
  10182. > Sent:    mercredi, 10. mars 1999 10:25
  10183. > To:    usr-tc@lists.xmission.com
  10184. > Subject:    Re: (usr-tc) 3Com Problems.
  10185. > 
  10186. > Once upon a time Robert von Bismarck shaped the electrons to say...
  10187. > >    Even the PM2 does BGP... but it's BGP3 which is pretty useless.
  10188. > 
  10189. > The PM-2 does RIP and OSPFv2 with NSSA.  No BGP.
  10190. > 
  10191. > The only PortMaster products which do BGP are the PM-3, PM-4, and IRX.
  10192. > All do BGP4.  Actually, the implementation supports many of the 
  10193. > supplimental RFCs, and some of the draft material for BGP5.
  10194. > 
  10195. > All PortMasters (well, except for the ancient PM-11 and IR4) support RIPv1
  10196. > and OSPFv2 with NSSA, the above three do BGP as well.  Lucent is adding
  10197. > RIPv2 to the PM-4 in ComOS 4.1, a reversal on Livingston's stance on 
  10198. > supporting OSPF but not RIPv2 since OSPF is superior.  No definite word
  10199. > yet on if that means the other products will also receive RIPv2 in 3.9.
  10200. > 
  10201. > -MZ
  10202. > -- 
  10203. > -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/>
  10204. > X*=-
  10205. > <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer,
  10206. > me..
  10207. > Join ISP/C Internet Service Providers' Consortium
  10208. > <URL:http://www.ispc.org/>
  10209. > "A little nonsense now and then, is relished by the wisest men"
  10210. > 781-788-0130
  10211. > <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail
  10212. > Discordia!
  10213. > 
  10214. > -
  10215. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10216. >  with "unsubscribe usr-tc" in the body of the message.
  10217. >  For information on digests or retrieving files and old messages send
  10218. >  "help" to the same address.  Do not use quotes in your message.
  10219.  
  10220. -
  10221.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10222.  with "unsubscribe usr-tc" in the body of the message.
  10223.  For information on digests or retrieving files and old messages send
  10224.  "help" to the same address.  Do not use quotes in your message.
  10225.  
  10226.  
  10227. -------------------------------------------------------------------------------
  10228.  
  10229. From: "Thomas C. Kinnen" <tkinnen@livingston.com>
  10230. Subject: Re: (usr-tc) 3Com Problems.
  10231. Date: 10 Mar 1999 03:35:16 -0800
  10232.  
  10233. Robert von Bismarck wrote:
  10234.  
  10235. >   Disabled Modules: OSPF BGP
  10236. > SBL-PM1> version
  10237. > Livingston PortMaster PM-2e ComOS 3.7.2
  10238. > System uptime is 126 days 16 hours 3 minutes
  10239. > SBL-PM1> exit
  10240. > 
  10241. > Why mention it, if it's not inside or planned ? (I never tried to use it as
  10242. > it would have been pretty useless for me)
  10243.  
  10244. ComOS uses a common code base.
  10245.  
  10246. -- 
  10247. Thomas C Kinnen - <tkinnen@ra.lucent.com> <tkinnen@sobhrach.com>
  10248. [RADIUS Test Engineer] - LUCENT Technologies RABU
  10249. "All of the opinions stated above are my own and not my employer's,
  10250. unless they were given to me by my employer"
  10251.  
  10252. -
  10253.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10254.  with "unsubscribe usr-tc" in the body of the message.
  10255.  For information on digests or retrieving files and old messages send
  10256.  "help" to the same address.  Do not use quotes in your message.
  10257.  
  10258.  
  10259. -------------------------------------------------------------------------------
  10260.  
  10261. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  10262. Subject: Re: (usr-tc) Bizzare Webramp Problems
  10263. Date: 10 Mar 1999 08:17:21 -0600 (CST)
  10264.  
  10265. On Wed, 10 Mar 1999, Matthew Opoka wrote:
  10266.  
  10267. > Same here on my WebRamp 310i.  It is worse with VJ and/or stac turned on
  10268. > in the WebRamp.  Running 4.1.59-6 ARC 4.1.59 DSP.
  10269. > 
  10270.  
  10271. Do a show ppp on the hiper arc
  10272.  
  10273. Make sure that you have ppp offloading enabled
  10274. Make sure that ppp receive_accm is disabled.
  10275. Make sure that ppp ccp is set to all
  10276. Make sure header comprssion is on on the hiper arc
  10277.  
  10278. This will solve your problem.
  10279.  
  10280. krish
  10281.  
  10282. > 
  10283. > Mark Lemmert wrote:
  10284. > > 
  10285. > > I have seen some weird problems with Webramps, particularly
  10286. > > ones that have 3com Impact IQ modems as their ISDN TA.
  10287. > > 
  10288. > > The problem is that after connecting the connection between
  10289. > > the webramp and the HiperARC will 'freeze'. The connection
  10290. > > doesn't drop and everything looks ok in terms on the bundle
  10291. > > and links but no data moves in or out of the connection.
  10292. > > It only takes around 15 minutes for this to happen.
  10293. > > 
  10294. > > I am currently running 4.1.63 -6 and 1.2.60. What code
  10295. > > does everyone recommend for best results with Webramps?
  10296. > > 
  10297. > > I also read on a Webramp doc somewhere that they recommend
  10298. > > using the command set ppp ccp_MODEMTYPE_ACCEPT none to turn
  10299. > > off compression on the HiperARC. Has anybody done this and
  10300. > > had success?
  10301. > > 
  10302. > > Mark Lemmert                           AthEnet Data Exchange
  10303. > > Chief Technical Officer                888-919-8700
  10304. > > 
  10305. > > -
  10306. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10307. > >  with "unsubscribe usr-tc" in the body of the message.
  10308. > >  For information on digests or retrieving files and old messages send
  10309. > >  "help" to the same address.  Do not use quotes in your message.
  10310. > 
  10311. > -
  10312. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10313. >  with "unsubscribe usr-tc" in the body of the message.
  10314. >  For information on digests or retrieving files and old messages send
  10315. >  "help" to the same address.  Do not use quotes in your message.
  10316. > 
  10317.  
  10318. -
  10319.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10320.  with "unsubscribe usr-tc" in the body of the message.
  10321.  For information on digests or retrieving files and old messages send
  10322.  "help" to the same address.  Do not use quotes in your message.
  10323.  
  10324.  
  10325. -------------------------------------------------------------------------------
  10326.  
  10327. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  10328. Subject: Re: (usr-tc) Bizzare Webramp Problems
  10329. Date: 10 Mar 1999 08:17:21 -0600 (CST)
  10330.  
  10331. On Wed, 10 Mar 1999, Matthew Opoka wrote:
  10332.  
  10333. > Same here on my WebRamp 310i.  It is worse with VJ and/or stac turned on
  10334. > in the WebRamp.  Running 4.1.59-6 ARC 4.1.59 DSP.
  10335. > 
  10336.  
  10337. Do a show ppp on the hiper arc
  10338.  
  10339. Make sure that you have ppp offloading enabled
  10340. Make sure that ppp receive_accm is disabled.
  10341. Make sure that ppp ccp is set to all
  10342. Make sure header comprssion is on on the hiper arc
  10343.  
  10344. This will solve your problem.
  10345.  
  10346. krish
  10347.  
  10348. > 
  10349. > Mark Lemmert wrote:
  10350. > > 
  10351. > > I have seen some weird problems with Webramps, particularly
  10352. > > ones that have 3com Impact IQ modems as their ISDN TA.
  10353. > > 
  10354. > > The problem is that after connecting the connection between
  10355. > > the webramp and the HiperARC will 'freeze'. The connection
  10356. > > doesn't drop and everything looks ok in terms on the bundle
  10357. > > and links but no data moves in or out of the connection.
  10358. > > It only takes around 15 minutes for this to happen.
  10359. > > 
  10360. > > I am currently running 4.1.63 -6 and 1.2.60. What code
  10361. > > does everyone recommend for best results with Webramps?
  10362. > > 
  10363. > > I also read on a Webramp doc somewhere that they recommend
  10364. > > using the command set ppp ccp_MODEMTYPE_ACCEPT none to turn
  10365. > > off compression on the HiperARC. Has anybody done this and
  10366. > > had success?
  10367. > > 
  10368. > > Mark Lemmert                           AthEnet Data Exchange
  10369. > > Chief Technical Officer                888-919-8700
  10370. > > 
  10371. > > -
  10372. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10373. > >  with "unsubscribe usr-tc" in the body of the message.
  10374. > >  For information on digests or retrieving files and old messages send
  10375. > >  "help" to the same address.  Do not use quotes in your message.
  10376. > 
  10377. > -
  10378. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10379. >  with "unsubscribe usr-tc" in the body of the message.
  10380. >  For information on digests or retrieving files and old messages send
  10381. >  "help" to the same address.  Do not use quotes in your message.
  10382. > 
  10383.  
  10384. -
  10385.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10386.  with "unsubscribe usr-tc" in the body of the message.
  10387.  For information on digests or retrieving files and old messages send
  10388.  "help" to the same address.  Do not use quotes in your message.
  10389.  
  10390.  
  10391. -------------------------------------------------------------------------------
  10392.  
  10393. From: d baud <dbaud@bigfoot.com>
  10394. Subject: (usr-tc) Re: IEA , using it from Radius - Problem fixed
  10395. Date: 10 Mar 1999 12:53:36 -0500
  10396.  
  10397. Ok just for the record, 
  10398.  
  10399. I re-checked my settings and it turned out that I did a typo in the
  10400. dictionary entry.
  10401. so the problem is fixed and IEA is working properly.
  10402. The monitor ppp and monitor radius commands helped alot in debugging
  10403. this silly error.  
  10404. and I would like to share with the list the very helpfull undocumented
  10405. CLI command:
  10406. _auth username password
  10407. This will "fake" a login connection to the HARC and will actually
  10408. authenticate the user as if it was a regular call.
  10409.  
  10410. d baud
  10411.  
  10412. > 
  10413. > I am trying to use the new IEA feature in the 4.1.59-6 HARC code.  I
  10414. > managed to use it with local non-radius users:
  10415. > set network usr my_local_user IP IEA_NEXT_HOP_GATEWAY 192.0.0.1
  10416. > 
  10417. > Now this is great, but I need to use this for particular users from
  10418. > RADIUS, so I added in the dictionnary the following:
  10419. > ATTRIBUTE    IEA_NEXT_HOP_GATEWAY 0x9008 ipaddr
  10420. > 
  10421. > And I added to my "users" file the entry
  10422. > IEA_NEXT_HOP_GATEWAY = 192.0.0.1,
  10423. > 
  10424. > The RADIUS users still pick the defaultroute :(
  10425. > I tried to monitor the connection with "mon radius" on the HARC but it
  10426. > does not seem to report any VSA attributes anyway.
  10427. > 
  10428. > Oh BTW for those who don't know what IEA is, it stands for Internet
  10429. > Equal Access and it is used to specify a different gateway than the
  10430. > defaultroute.
  10431. > 
  10432. > D. Baud
  10433.  
  10434. -
  10435.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10436.  with "unsubscribe usr-tc" in the body of the message.
  10437.  For information on digests or retrieving files and old messages send
  10438.  "help" to the same address.  Do not use quotes in your message.
  10439.  
  10440.  
  10441. -------------------------------------------------------------------------------
  10442.  
  10443. From: Jim Johnson <jim@perigee.net>
  10444. Subject: (usr-tc) SREJ on Quads
  10445. Date: 10 Mar 1999 13:53:18 -0500
  10446.  
  10447.  
  10448.  
  10449. What is the consensus opinion of leaving Selective Reject enabled on the
  10450. quads? 
  10451.  
  10452. The default setting is enabled when you restore a quad from defaults,
  10453. but not on the HDMs.
  10454.  
  10455. Does it cause more problems than it helps?
  10456.  
  10457. Jim
  10458.  
  10459. -
  10460.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10461.  with "unsubscribe usr-tc" in the body of the message.
  10462.  For information on digests or retrieving files and old messages send
  10463.  "help" to the same address.  Do not use quotes in your message.
  10464.  
  10465.  
  10466. -------------------------------------------------------------------------------
  10467.  
  10468. From: Stephen Amadei <amadei@dandy.net>
  10469. Subject: (usr-tc) Impact problems...
  10470. Date: 10 Mar 1999 15:17:58 -0500 (EST)
  10471.  
  10472.  
  10473. I was wondering if there was any easy fix for getting 3Com Impact IQ ISDN
  10474. "modems" to connect to the Quad cards?  I have a chassis with the Dual
  10475. T1/12 Quads/ARC and NMC setup, and the Impact absolutely refuses to
  10476. connect.  All firmware is current (even 4.1.59-6).
  10477.  
  10478. On my Hiper chassis, the Impact connects to the DSPs without a glitch.
  10479. It also has all current firmware.
  10480.  
  10481. Thanx in advance.
  10482.  
  10483.                     ----Steve
  10484. Stephen Amadei
  10485. Director of MIS
  10486. Dandy Connections, Inc.
  10487. Atlantic City, NJ
  10488.  
  10489.  
  10490. -
  10491.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10492.  with "unsubscribe usr-tc" in the body of the message.
  10493.  For information on digests or retrieving files and old messages send
  10494.  "help" to the same address.  Do not use quotes in your message.
  10495.  
  10496.  
  10497. -------------------------------------------------------------------------------
  10498.  
  10499. From: "Randy McMillan" <randy@pacinfo.com>
  10500. Subject: (usr-tc) Is there a way to disable x2/v.90 with DNIS init strings?
  10501. Date: 10 Mar 1999 14:30:38 -0800
  10502.  
  10503. This is a multi-part message in MIME format.
  10504.  
  10505. ------=_NextPart_000_013D_01BE6B02.91B1AE40
  10506. Content-Type: text/plain;
  10507.     charset="iso-8859-1"
  10508. Content-Transfer-Encoding: quoted-printable
  10509.  
  10510. I have been trying to set up a way for users whose modems won't =
  10511. negotiate with the v.90 code on our quad modems to call a number other =
  10512. than our huntgroup lead number and then based on that DNIS number limit =
  10513. the modem to v.34 speeds.  So far it hasn't worked (it still connects at =
  10514. v.90 speeds).  I am getting the DNIS digits, but perhaps my init strings =
  10515. were not correct.  Any help would be apreciated.
  10516.  
  10517. Randy McMillan
  10518. PacInfo
  10519.  
  10520. ------=_NextPart_000_013D_01BE6B02.91B1AE40
  10521. Content-Type: text/html;
  10522.     charset="iso-8859-1"
  10523. Content-Transfer-Encoding: quoted-printable
  10524.  
  10525. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  10526. <HTML>
  10527. <HEAD>
  10528.  
  10529. <META content=3Dtext/html;charset=3Diso-8859-1 =
  10530. http-equiv=3DContent-Type>
  10531. <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
  10532. </HEAD>
  10533. <BODY bgColor=3D#ffffff>
  10534. <DIV><FONT color=3D#000000 face=3DArial size=3D2>I have been trying to =
  10535. set up a way=20
  10536. for users whose modems won't negotiate with the v.90 code on our quad =
  10537. modems to=20
  10538. call a number other than our huntgroup lead number and then based on =
  10539. that DNIS=20
  10540. number limit the modem to v.34 speeds.  So far it hasn't worked (it =
  10541. still=20
  10542. connects at v.90 speeds).  I am getting the DNIS digits, but =
  10543. perhaps my=20
  10544. init strings were not correct.  Any help would be =
  10545. apreciated.</FONT></DIV>
  10546. <DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT> </DIV>
  10547. <DIV><FONT color=3D#000000 face=3DArial size=3D2>Randy =
  10548. McMillan</FONT></DIV>
  10549. <DIV><FONT color=3D#000000 face=3DArial =
  10550. size=3D2>PacInfo</FONT></DIV></BODY></HTML>
  10551.  
  10552. ------=_NextPart_000_013D_01BE6B02.91B1AE40--
  10553.  
  10554.  
  10555. -
  10556.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10557.  with "unsubscribe usr-tc" in the body of the message.
  10558.  For information on digests or retrieving files and old messages send
  10559.  "help" to the same address.  Do not use quotes in your message.
  10560.  
  10561.  
  10562. -------------------------------------------------------------------------------
  10563.  
  10564. From: "John C Hill II" <carroll@netexas.net>
  10565. Subject: RE: (usr-tc) Is there a way to disable x2/v.90 with DNIS init strings?
  10566. Date: 10 Mar 1999 16:36:48 -0600
  10567.  
  10568. This is a multi-part message in MIME format.
  10569.  
  10570. ------=_NextPart_000_0003_01BE6B14.31ED3620
  10571. Content-Type: text/plain;
  10572.     charset="iso-8859-1"
  10573. Content-Transfer-Encoding: 7bit
  10574.  
  10575. I've done something similar, but from the opposite end. I just have the user
  10576. disable the V.90 on their end. This usually works fine for us.
  10577.  
  10578.  
  10579.  
  10580. John C Hill II
  10581. North East Texas Internet
  10582.  
  10583.  
  10584.  
  10585.  
  10586.     -----Original Message-----
  10587.     From: owner-usr-tc@lists.xmission.com
  10588. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy McMillan
  10589.     Sent: Wednesday, March 10, 1999 4:31 PM
  10590.     To: usr-tc@xmission.com
  10591.     Subject: (usr-tc) Is there a way to disable x2/v.90 with DNIS init
  10592. strings?
  10593.  
  10594.  
  10595.     I have been trying to set up a way for users whose modems won't
  10596. negotiate with the v.90 code on our quad modems to call a number other than
  10597. our huntgroup lead number and then based on that DNIS number limit the modem
  10598. to v.34 speeds.  So far it hasn't worked (it still connects at v.90 speeds).
  10599. I am getting the DNIS digits, but perhaps my init strings were not correct.
  10600. Any help would be apreciated.
  10601.  
  10602.     Randy McMillan
  10603.     PacInfo
  10604.  
  10605. ------=_NextPart_000_0003_01BE6B14.31ED3620
  10606. Content-Type: text/html;
  10607.     charset="iso-8859-1"
  10608. Content-Transfer-Encoding: quoted-printable
  10609.  
  10610. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  10611. <HTML>
  10612. <HEAD>
  10613. <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
  10614. charset=3Diso-8859-1">
  10615.  
  10616.  
  10617.  
  10618. <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
  10619. </HEAD>
  10620. <BODY bgColor=3D#ffffff>
  10621. <DIV><SPAN class=3D480353522-10031999><FONT color=3D#0000ff face=3DArial =
  10622. size=3D3>I've=20
  10623. done something similar, but from the opposite end. I just have the user =
  10624. disable=20
  10625. the V.90 on their end. This usually works fine for =
  10626. us.</FONT></SPAN></DIV>
  10627. <DIV> </DIV><BR>
  10628. <P><FONT face=3DArial size=3D2>John C Hill II</FONT> <BR><FONT =
  10629. face=3DArial=20
  10630. size=3D2>North East Texas Internet</FONT> </P><BR>
  10631. <DIV> </DIV>
  10632. <BLOCKQUOTE>
  10633.     <DIV class=3DOutlookMessageHeader><FONT face=3D"Times New Roman"=20
  10634.     size=3D2>-----Original Message-----<BR><B>From:</B>=20
  10635.     owner-usr-tc@lists.xmission.com=20
  10636.     [mailto:owner-usr-tc@lists.xmission.com]<B>On Behalf Of</B> Randy=20
  10637.     McMillan<BR><B>Sent:</B> Wednesday, March 10, 1999 4:31 =
  10638. PM<BR><B>To:</B>=20
  10639.     usr-tc@xmission.com<BR><B>Subject:</B> (usr-tc) Is there a way to =
  10640. disable=20
  10641.     x2/v.90 with DNIS init strings?<BR><BR></FONT></DIV>
  10642.     <DIV><FONT color=3D#000000 face=3DArial size=3D2>I have been trying =
  10643. to set up a=20
  10644.     way for users whose modems won't negotiate with the v.90 code on our =
  10645. quad=20
  10646.     modems to call a number other than our huntgroup lead number and =
  10647. then based=20
  10648.     on that DNIS number limit the modem to v.34 speeds.  So far it =
  10649. hasn't=20
  10650.     worked (it still connects at v.90 speeds).  I am getting the =
  10651. DNIS=20
  10652.     digits, but perhaps my init strings were not correct.  Any help =
  10653. would=20
  10654.     be apreciated.</FONT></DIV>
  10655.     <DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT> </DIV>
  10656.     <DIV><FONT color=3D#000000 face=3DArial size=3D2>Randy =
  10657. McMillan</FONT></DIV>
  10658.     <DIV><FONT color=3D#000000 face=3DArial=20
  10659. size=3D2>PacInfo</FONT></DIV></BLOCKQUOTE></BODY></HTML>
  10660.  
  10661. ------=_NextPart_000_0003_01BE6B14.31ED3620--
  10662.  
  10663.  
  10664. -
  10665.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10666.  with "unsubscribe usr-tc" in the body of the message.
  10667.  For information on digests or retrieving files and old messages send
  10668.  "help" to the same address.  Do not use quotes in your message.
  10669.  
  10670.  
  10671. -------------------------------------------------------------------------------
  10672.  
  10673. From: "Michael E. Ezzell" <mezzell@networkacg.com>
  10674. Subject: RE: (usr-tc) Is there a way to disable x2/v.90 with DNIS init str
  10675. Date: 10 Mar 1999 17:09:08 -0600
  10676.  
  10677. John, I like your solution and I'm curious... are you using "AT&F0S38=0" or
  10678. something else on the customer end?
  10679.  
  10680. Michael Ezzell
  10681. The Austin Consultant Group
  10682. Oklahoma City, Oklahoma
  10683.  
  10684. -----Original Message-----
  10685. Sent: Wednesday, March 10, 1999 4:37 PM
  10686. strings?
  10687.  
  10688.  
  10689. I've done something similar, but from the opposite end. I just have the user
  10690. disable the V.90 on their end. This usually works fine for us.
  10691.  
  10692. John C Hill II 
  10693. North East Texas Internet 
  10694.  
  10695.  
  10696. -----Original Message-----
  10697. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy McMillan
  10698. Sent: Wednesday, March 10, 1999 4:31 PM
  10699.  
  10700.  
  10701. I have been trying to set up a way for users whose modems won't negotiate
  10702. with the v.90 code on our quad modems to call a number other than our
  10703. huntgroup lead number and then based on that DNIS number limit the modem to
  10704. v.34 speeds.  So far it hasn't worked (it still connects at v.90 speeds).  I
  10705. am getting the DNIS digits, but perhaps my init strings were not correct.
  10706. Any help would be apreciated.
  10707.  
  10708. Randy McMillan
  10709. PacInfo
  10710.  
  10711. -
  10712.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10713.  with "unsubscribe usr-tc" in the body of the message.
  10714.  For information on digests or retrieving files and old messages send
  10715.  "help" to the same address.  Do not use quotes in your message.
  10716.  
  10717.  
  10718. -------------------------------------------------------------------------------
  10719.  
  10720. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  10721. Subject: Re: (usr-tc) Is there a way to disable x2/v.90 with DNIS init strings?
  10722. Date: 10 Mar 1999 18:15:52 -0500 (EST)
  10723.  
  10724.  
  10725. Based on an idea I mentioned a couple of threads ago, I'm currently
  10726. working on setting this up and getting it tested; am waiting on
  10727. the telco to point another number at my head-of-huntgroup line (they
  10728. say it'll take 'em till Friday 19th to do it *roll* Yes, I told 'em
  10729. that if they gave me dialup access to their switch I could do it
  10730. in the time it took me to ask them. Of course, they thought I was
  10731. pretty good at being a comedian).
  10732.  
  10733. The basic idea is to have two configurations...one with all the
  10734. bells and whistles, and one that's more a generic work-with-anything
  10735. configuration with no 56k or v.42bis, etc. If a customer has trouble
  10736. with our main number (which is configged to kick ass for the ones
  10737. who have fancy modems that actually work), they just try our secondary
  10738. number (which is configged to get anything connected, including me
  10739. whistling a 300bps carrier).
  10740.  
  10741. Sure, one can get the customer to turn it all off on their end (as
  10742. we currently do), but I don't like that solution. It requires the
  10743. customer to have to learn too much about modems for one. And the
  10744. killer is the amount of time tech support is online with someone's
  10745. mom trying to get her to type strange things in a strange panel
  10746. (something she *never* had to do when she was with AOL, she'll
  10747. remind you).
  10748.  
  10749. So getting the customer to turn it off is *lame*. Anything I can do
  10750. to avoid it must be attempted. If I succeed, I fully expect higher
  10751. customer satisfaction and yet another stick I can smack my competition
  10752. with.
  10753.  
  10754. So, I can't be of much help now, but I will be posting my results
  10755. here.
  10756.  
  10757. Couple of things I'd investigate in your position tho...make sure
  10758. that you're getting all the dnis digits, or if you're getting a
  10759. subset, make sure it's the same in your hdsp config. And definately
  10760. verify your init strings of course....
  10761.  
  10762. Lon Stockton
  10763. MoonStar
  10764.  
  10765.  
  10766. On Wed, 10 Mar 1999, Randy McMillan wrote (without any word wrap):
  10767.  
  10768. > I have been trying to set up a way for users whose modems won't
  10769. > negotiate with the v.90 code on our quad modems to call a number
  10770. > other than our huntgroup lead number and then based on that DNIS
  10771. > number limit the modem to v.34 speeds.  So far it hasn't worked
  10772. > (it still connects at v.90 speeds).  I am getting the DNIS digits,
  10773. > but perhaps my init strings were not correct.  Any help would be
  10774. > apreciated.
  10775.  
  10776.  
  10777. -
  10778.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10779.  with "unsubscribe usr-tc" in the body of the message.
  10780.  For information on digests or retrieving files and old messages send
  10781.  "help" to the same address.  Do not use quotes in your message.
  10782.  
  10783.  
  10784. -------------------------------------------------------------------------------
  10785.  
  10786. From: "John C Hill II" <carroll@netexas.net>
  10787. Subject: RE: (usr-tc) Is there a way to disable x2/v.90 with DNIS init strings?
  10788. Date: 10 Mar 1999 17:19:23 -0600
  10789.  
  10790. It depends on what type of modem they are using. I fist find out what the
  10791. chipset is. Usually you can do this by going to Modems in Control Panel
  10792. (Win95 & Win98). If you click on the Diagnostics tab and then select the
  10793. modem, then click on the button that says More Info. Usually somewhere is
  10794. the chipset of the modem. After learning this info, I found a WebPages that
  10795. tells the init string to disable either V.90, X2, or KFlex. The URL is
  10796. http://www.56k.com/trouble/interop.shtml .  Another good WebPages is
  10797. http://www.v90stuff.com/ .  Hope this helps. If not, let me know.
  10798.  
  10799.  
  10800. John C Hill II
  10801. North East Texas Internet
  10802.  
  10803.  
  10804.  
  10805.  
  10806. -----Original Message-----
  10807. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Michael E. Ezzell
  10808. Sent: Wednesday, March 10, 1999 5:09 PM
  10809. strings?
  10810.  
  10811.  
  10812. John, I like your solution and I'm curious... are you using "AT&F0S38=0" or
  10813. something else on the customer end?
  10814.  
  10815. Michael Ezzell
  10816. The Austin Consultant Group
  10817. Oklahoma City, Oklahoma
  10818.  
  10819. -----Original Message-----
  10820. Sent: Wednesday, March 10, 1999 4:37 PM
  10821. strings?
  10822.  
  10823.  
  10824. I've done something similar, but from the opposite end. I just have the user
  10825. disable the V.90 on their end. This usually works fine for us.
  10826.  
  10827. John C Hill II
  10828. North East Texas Internet
  10829.  
  10830.  
  10831. -----Original Message-----
  10832. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Randy McMillan
  10833. Sent: Wednesday, March 10, 1999 4:31 PM
  10834.  
  10835.  
  10836. I have been trying to set up a way for users whose modems won't negotiate
  10837. with the v.90 code on our quad modems to call a number other than our
  10838. huntgroup lead number and then based on that DNIS number limit the modem to
  10839. v.34 speeds.  So far it hasn't worked (it still connects at v.90 speeds).  I
  10840. am getting the DNIS digits, but perhaps my init strings were not correct.
  10841. Any help would be apreciated.
  10842.  
  10843. Randy McMillan
  10844. PacInfo
  10845.  
  10846. -
  10847.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10848.  with "unsubscribe usr-tc" in the body of the message.
  10849.  For information on digests or retrieving files and old messages send
  10850.  "help" to the same address.  Do not use quotes in your message.
  10851.  
  10852.  
  10853. -
  10854.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10855.  with "unsubscribe usr-tc" in the body of the message.
  10856.  For information on digests or retrieving files and old messages send
  10857.  "help" to the same address.  Do not use quotes in your message.
  10858.  
  10859.  
  10860. -------------------------------------------------------------------------------
  10861.  
  10862. From: "Randy McMillan" <randy@pacinfo.com>
  10863. Subject: Re: (usr-tc) Is there a way to disable x2/v.90 with DNIS init strings?
  10864. Date: 10 Mar 1999 16:00:04 -0800
  10865.  
  10866. This is a multi-part message in MIME format.
  10867.  
  10868. ------=_NextPart_000_01B1_01BE6B0F.0FB73920
  10869. Content-Type: text/plain;
  10870.     charset="iso-8859-1"
  10871. Content-Transfer-Encoding: quoted-printable
  10872.  
  10873. I am using quad modems and hiper ARC card.  The telco is passing 4 =
  10874. digits, the modem "call control" options are set for 4 DNIS digits, and =
  10875. those digits are in the modem "DNIS access codes".  The init strings I =
  10876. have tried with no luck are:
  10877. ATS76.0=3D0S81.4=3D0S81.5=3D0S81.6=3D0
  10878. ATS32=3D98
  10879. AT&N21
  10880. Do they look right or wrong to you?  I am not positive that they are =
  10881. actually being executed, and not sure of a way to check.
  10882.  
  10883.  
  10884. Randy McMillan
  10885. PacInfo
  10886.  
  10887. -----Original Message-----
  10888. strings?
  10889.  
  10890.  
  10891. <snip>
  10892. >So, I can't be of much help now, but I will be posting my results
  10893. >here.
  10894. >
  10895. >Couple of things I'd investigate in your position tho...make sure
  10896. >that you're getting all the dnis digits, or if you're getting a
  10897. >subset, make sure it's the same in your hdsp config. And definately
  10898. >verify your init strings of course....
  10899.  
  10900.  
  10901. >
  10902. >Lon Stockton
  10903. >MoonStar
  10904. >
  10905. >
  10906. >On Wed, 10 Mar 1999, Randy McMillan wrote (without any word wrap):
  10907. >
  10908. >> I have been trying to set up a way for users whose modems won't
  10909. >> negotiate with the v.90 code on our quad modems to call a number
  10910. >> other than our huntgroup lead number and then based on that DNIS
  10911. >> number limit the modem to v.34 speeds.  So far it hasn't worked
  10912. >> (it still connects at v.90 speeds).  I am getting the DNIS digits,
  10913. >> but perhaps my init strings were not correct.  Any help would be
  10914. >> apreciated.
  10915. >
  10916. >
  10917. >-
  10918. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  10919. > with "unsubscribe usr-tc" in the body of the message.
  10920. > For information on digests or retrieving files and old messages send
  10921. > "help" to the same address.  Do not use quotes in your message.
  10922. >
  10923.  
  10924. ------=_NextPart_000_01B1_01BE6B0F.0FB73920
  10925. Content-Type: text/html;
  10926.     charset="iso-8859-1"
  10927. Content-Transfer-Encoding: quoted-printable
  10928.  
  10929. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  10930. <HTML>
  10931. <HEAD>
  10932.  
  10933. <META content=3Dtext/html;charset=3Diso-8859-1 =
  10934. http-equiv=3DContent-Type>
  10935. <META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
  10936. </HEAD>
  10937. <BODY>
  10938. <DIV>
  10939. <DIV>I am using quad modems and hiper ARC card.  The telco is =
  10940. passing 4=20
  10941. digits, the modem "call control" options are set for 4 DNIS =
  10942. digits,=20
  10943. and those digits are in the modem "DNIS access codes".  =
  10944. The init=20
  10945. strings I have tried with no luck are:</DIV>
  10946. <DIV>ATS76.0=3D0S81.4=3D0S81.5=3D0S81.6=3D0</DIV>
  10947. <DIV>ATS32=3D98</DIV>
  10948. <DIV>AT&N21</DIV>
  10949. <DIV>Do they look right or wrong to you?  I am not positive that =
  10950. they are=20
  10951. actually being executed, and not sure of a way to check.<BR></DIV>
  10952. <DIV> </DIV>
  10953. <DIV><FONT color=3D#000000 face=3DArial size=3D2>Randy =
  10954. McMillan</FONT></DIV>
  10955. <DIV><FONT color=3D#000000 face=3DArial size=3D2></FONT><FONT =
  10956. face=3DArial=20
  10957. size=3D2>PacInfo</FONT></DIV>
  10958. <DIV> </DIV></DIV>
  10959. <DIV><FONT face=3DArial size=3D2>-----Original Message-----<BR>From: Lon =
  10960. R.=20
  10961. Stockton, Jr. <<A=20
  10962. href=3D"mailto:lon@moonstar.com">lon@moonstar.com</A>><BR>To: <A=20
  10963. href=3D"mailto:usr-tc@lists.xmission.com">usr-tc@lists.xmission.com</A> =
  10964. <<A=20
  10965. href=3D"mailto:usr-tc@lists.xmission.com">usr-tc@lists.xmission.com</A>&g=
  10966. t;<BR>Date:=20
  10967. Wednesday, March 10, 1999 3:21 PM<BR>Subject: Re: (usr-tc) Is there a =
  10968. way to=20
  10969. disable x2/v.90 with DNIS init strings?<BR><BR></FONT></DIV>
  10970. <DIV><snip></DIV>
  10971. <DIV>>So, I can't be of much help now, but I will be posting my=20
  10972. results<BR>>here.<BR>><BR>>Couple of things I'd investigate in =
  10973. your=20
  10974. position tho...make sure<BR>>that you're getting all the dnis digits, =
  10975. or if=20
  10976. you're getting a<BR>>subset, make sure it's the same in your hdsp =
  10977. config. And=20
  10978. definately<BR>>verify your init strings of course....</DIV>
  10979. <DIV> </DIV>
  10980. <DIV> </DIV>
  10981. <DIV>><BR>>Lon Stockton<BR>>MoonStar<BR>><BR>><BR>>On =
  10982. Wed, 10=20
  10983. Mar 1999, Randy McMillan wrote (without any word =
  10984. wrap):<BR>><BR>>> I=20
  10985. have been trying to set up a way for users whose modems =
  10986. won't<BR>>>=20
  10987. negotiate with the v.90 code on our quad modems to call a =
  10988. number<BR>>>=20
  10989. other than our huntgroup lead number and then based on that =
  10990. DNIS<BR>>>=20
  10991. number limit the modem to v.34 speeds.  So far it hasn't =
  10992. worked<BR>>>=20
  10993. (it still connects at v.90 speeds).  I am getting the DNIS=20
  10994. digits,<BR>>> but perhaps my init strings were not correct.  =
  10995. Any help=20
  10996. would be<BR>>> apreciated.<BR>><BR>><BR>>-<BR>> To =
  10997. unsubscribe=20
  10998. to usr-tc, send an email to "<A=20
  10999. href=3D"mailto:majordomo@xmission.com">majordomo@xmission.com</A>"<B=
  11000. R>>=20
  11001. with "unsubscribe usr-tc" in the body of the message.<BR>> =
  11002. For=20
  11003. information on digests or retrieving files and old messages send<BR>> =
  11004.  
  11005. "help" to the same address.  Do not use quotes in your=20
  11006. message.<BR>></DIV></BODY></HTML>
  11007.  
  11008. ------=_NextPart_000_01B1_01BE6B0F.0FB73920--
  11009.  
  11010.  
  11011. -
  11012.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11013.  with "unsubscribe usr-tc" in the body of the message.
  11014.  For information on digests or retrieving files and old messages send
  11015.  "help" to the same address.  Do not use quotes in your message.
  11016.  
  11017.  
  11018. -------------------------------------------------------------------------------
  11019.  
  11020. From: "Jamie Orzechowski" <mhz@recorder.ca>
  11021. Subject: Re: (usr-tc) Port Limit
  11022. Date: 10 Mar 1999 19:04:45 -0500
  11023.  
  11024. This is a multi-part message in MIME format.
  11025.  
  11026. ------=_NextPart_000_0013_01BE6B28.DC9B9440
  11027. Content-Type: text/plain;
  11028.     charset="iso-8859-1"
  11029. Content-Transfer-Encoding: quoted-printable
  11030.  
  11031. I am just wondering about port limits.
  11032.  
  11033. I want to set my ARC up so that ONLY 1 userID can be logged in at once.  =
  11034. I still want to allow for multilink PPP though sp that if there radius =
  11035. attribute of Port-Limit =3D 2 they will be allowed multilink.
  11036.  
  11037. I tried a "set user default port_limit 1" but then I noticed that some =
  11038. people we logged in multiple times ... any ideas??
  11039.  
  11040. is this possible on netserver also??
  11041.  
  11042. Have a Great Day!
  11043.  
  11044. Jamie Orzechowski
  11045. RipNET System Admin
  11046.  
  11047. Tel.: 613-342-3946 ext 293
  11048. Tel.: 800-267-4434 ext 293
  11049. Page.: 613-341-0883
  11050. EMail.: mhz@ripnet.com
  11051. Web.: http://www.ripnet.com
  11052. Personal.: http://www.moonchilli.com
  11053.  
  11054. ------=_NextPart_000_0013_01BE6B28.DC9B9440
  11055. Content-Type: text/html;
  11056.     charset="iso-8859-1"
  11057. Content-Transfer-Encoding: quoted-printable
  11058.  
  11059. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  11060. <HTML>
  11061. <HEAD>
  11062.  
  11063. <META content=3Dtext/html;charset=3Diso-8859-1 =
  11064. http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
  11065. HTML//EN">
  11066. <META content=3D'"MSHTML 4.72.3612.1700"' name=3DGENERATOR>
  11067. </HEAD>
  11068. <BODY bgColor=3D#ffffff>
  11069. <DIV><FONT color=3D#000000 size=3D2>I am just wondering about port=20
  11070. limits.</FONT></DIV>
  11071. <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
  11072. <DIV><FONT size=3D2>I want to set my ARC up so that ONLY 1 userID can be =
  11073. logged in=20
  11074. at once.  I still want to allow for multilink PPP though sp that if =
  11075. there=20
  11076. radius attribute of Port-Limit =3D 2 they will be allowed =
  11077. multilink.</FONT></DIV>
  11078. <DIV><FONT size=3D2></FONT> </DIV>
  11079. <DIV><FONT size=3D2>I tried a "set user default port_limit 1" =
  11080. but then I=20
  11081. noticed that some people we logged in multiple times ... any=20
  11082. ideas??</FONT></DIV>
  11083. <DIV><FONT size=3D2></FONT> </DIV>
  11084. <DIV><FONT size=3D2>is this possible on netserver also??</FONT></DIV>
  11085. <DIV><FONT color=3D#000000=20
  11086. size=3D2><BR>---------------------------------------------------<BR>Have =
  11087. a Great=20
  11088. Day!</FONT></DIV>
  11089. <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
  11090. <DIV><FONT color=3D#000000 size=3D2>Jamie Orzechowski<BR>RipNET System=20
  11091. Admin</FONT></DIV>
  11092. <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
  11093. <DIV><FONT color=3D#000000 size=3D2>Tel.: 613-342-3946 ext 293<BR>Tel.: =
  11094. 800-267-4434=20
  11095. ext 293<BR>Page.: 613-341-0883<BR>EMail.: <A=20
  11096. href=3D"mailto:mhz@ripnet.com">mhz@ripnet.com</A><BR>Web.: <A=20
  11097. href=3D"http://www.ripnet.com">http://www.ripnet.com</A><BR>Personal.: =
  11098. <A=20
  11099. href=3D"http://www.moonchilli.com">http://www.moonchilli.com</A><BR>-----=
  11100.  
  11101.  
  11102. ------=_NextPart_000_0013_01BE6B28.DC9B9440--
  11103.  
  11104.  
  11105. -
  11106.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11107.  with "unsubscribe usr-tc" in the body of the message.
  11108.  For information on digests or retrieving files and old messages send
  11109.  "help" to the same address.  Do not use quotes in your message.
  11110.  
  11111.  
  11112. -------------------------------------------------------------------------------
  11113.  
  11114. From: Greg Coffey <greg@coffey.com>
  11115. Subject: Re: (usr-tc) Port Limit
  11116. Date: 10 Mar 1999 17:08:55 -0700
  11117.  
  11118. There is some good software at www.tsmon.com that we use.  We had about 20%
  11119. of the subscribers that were using (abusing) the system in some fashion.
  11120. Twas much higher than I thought and the program merrily keeps kicking them
  11121. off every couple of minutes.  Works well and I know of no other option.  I
  11122. think its around $600 for 3 pops and $25 per pop after that.  We use it on
  11123. our TC's and some netserver 16's with no problem.   
  11124.  
  11125. At 07:04 PM 3/10/99 -0500, you wrote:
  11126. >    I am just wondering about port  limits.     I still want to allow for
  11127. >multilink PPP though sp that if there  radius attribute of Port-Limit = 2
  11128. >they will be allowed multilink.   "" but then I  noticed that some people
  11129. >we logged in multiple times ... any  ideas??   is this possible on
  11130. >netserver also?? 
  11131. >---------------------------------------------------
  11132. >Have a Great  Day!   Jamie Orzechowski
  11133. >RipNET System  Admin   Tel.: 613-342-3946 ext 293
  11134. >Tel.: 800-267-4434  ext 293
  11135. >Page.: 613-341-0883
  11136. >EMail.: mhz@ripnet.com
  11137. >Web.: http://www.ripnet.com
  11138. >Personal.: http://www.moonchilli.com
  11139. >--------------------------------------------------- 
  11140.  
  11141. Thanks,
  11142. Greg Coffey, CoffeyNet    Voice 307-234-5443   307-234-5446 Fax
  11143. ====================================================================
  11144. 142 S. Center St.          3Com v.90 56k $20 in Casper & Douglas
  11145. Casper, WY  82601       Local Internet for Casper, Rawlins, Douglas,
  11146. http://WWW.COFFEY.COM      Wheatland, Pinedale, Lander & Lusk, WY
  11147.  
  11148. -
  11149.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11150.  with "unsubscribe usr-tc" in the body of the message.
  11151.  For information on digests or retrieving files and old messages send
  11152.  "help" to the same address.  Do not use quotes in your message.
  11153.  
  11154.  
  11155. -------------------------------------------------------------------------------
  11156.  
  11157. From: Stephen Amadei <amadei@dandy.net>
  11158. Subject: Re: (usr-tc) Port Limit
  11159. Date: 10 Mar 1999 20:47:03 -0500 (EST)
  11160.  
  11161. On Wed, 10 Mar 1999, Jamie Orzechowski wrote:
  11162.  
  11163. > I am just wondering about port limits.
  11164. > 
  11165. > I want to set my ARC up so that ONLY 1 userID can be logged in at once.
  11166. > I still want to allow for multilink PPP though sp that if there radius
  11167. > attribute of Port-Limit = 2 they will be allowed multilink.
  11168. > 
  11169. > I tried a "set user default port_limit 1" but then I noticed that some
  11170. > people we logged in multiple times ... any ideas??
  11171. > 
  11172. > is this possible on netserver also??
  11173.  
  11174. Apparently, Port-Limit won't stop multiple logins.
  11175.  
  11176. Really, Radius is a poor tool for limiting multiple logins. However, if
  11177. you use Cistron Radius, it has a Simultaneous-Use attribute that you can
  11178. use... that's the good news.  It calls a small script that checks your
  11179. access server to see if the original user is still on.  The bad news is
  11180. that the Total Control is a PITA to check what users are on.  The good
  11181. news is that a few Perl add-ons will give you the ability to check the TC.
  11182. However, this is as far as I have gotten since I can't find the "pmcmd"
  11183. script/program.  Oh well...
  11184.  
  11185.                     ----Steve
  11186. Stephen Amadei
  11187. Director of MIS
  11188. Dandy Connections, Inc.
  11189. Atlantic City, NJ
  11190.  
  11191.  
  11192. -
  11193.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11194.  with "unsubscribe usr-tc" in the body of the message.
  11195.  For information on digests or retrieving files and old messages send
  11196.  "help" to the same address.  Do not use quotes in your message.
  11197.  
  11198.  
  11199. -------------------------------------------------------------------------------
  11200.  
  11201. From: "Jamie Orzechowski" <mhz@recorder.ca>
  11202. Subject: Re: (usr-tc) Port Limit
  11203. Date: 10 Mar 1999 20:44:20 -0500
  11204.  
  11205. I believe www.tsmon.com will do what I need ... 
  11206.  
  11207. -----Original Message-----
  11208.  
  11209.  
  11210. >On Wed, 10 Mar 1999, Jamie Orzechowski wrote:
  11211. >
  11212. >> I am just wondering about port limits.
  11213. >> 
  11214. >> I want to set my ARC up so that ONLY 1 userID can be logged in at once.
  11215. >> I still want to allow for multilink PPP though sp that if there radius
  11216. >> attribute of Port-Limit = 2 they will be allowed multilink.
  11217. >> 
  11218. >> I tried a "set user default port_limit 1" but then I noticed that some
  11219. >> people we logged in multiple times ... any ideas??
  11220. >> 
  11221. >> is this possible on netserver also??
  11222. >
  11223. >Apparently, Port-Limit won't stop multiple logins.
  11224. >
  11225. >Really, Radius is a poor tool for limiting multiple logins. However, if
  11226. >you use Cistron Radius, it has a Simultaneous-Use attribute that you can
  11227. >use... that's the good news.  It calls a small script that checks your
  11228. >access server to see if the original user is still on.  The bad news is
  11229. >that the Total Control is a PITA to check what users are on.  The good
  11230. >news is that a few Perl add-ons will give you the ability to check the TC.
  11231. >However, this is as far as I have gotten since I can't find the "pmcmd"
  11232. >script/program.  Oh well...
  11233. >
  11234. > ----Steve
  11235. >Stephen Amadei
  11236. >Director of MIS
  11237. >Dandy Connections, Inc.
  11238. >Atlantic City, NJ
  11239. >
  11240. >
  11241. >-
  11242. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11243. > with "unsubscribe usr-tc" in the body of the message.
  11244. > For information on digests or retrieving files and old messages send
  11245. > "help" to the same address.  Do not use quotes in your message.
  11246. >
  11247. >
  11248.  
  11249.  
  11250. -
  11251.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11252.  with "unsubscribe usr-tc" in the body of the message.
  11253.  For information on digests or retrieving files and old messages send
  11254.  "help" to the same address.  Do not use quotes in your message.
  11255.  
  11256.  
  11257. -------------------------------------------------------------------------------
  11258.  
  11259. From: Mike Andrews <mandrews@termfrost.org>
  11260. Subject: Re: (usr-tc) Is there a way to disable x2/v.90 with DNIS init strings?
  11261. Date: 10 Mar 1999 20:46:28 -0500 (EST)
  11262.  
  11263. This is a hell of a good idea ... sure would save us a lot of time with
  11264. all the users afflicted with cheap modems.  If anyone has this working,
  11265. please let us all know :)  We're using both Quads and DSP's, which
  11266. complicates things a bit, though we are an all-PRI and all-ARC shop.
  11267.  
  11268.  
  11269. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  11270. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  11271. getting beaten by the police, put down the video camera and come help me!"
  11272.  
  11273. On Wed, 10 Mar 1999, Lon R. Stockton, Jr. wrote:
  11274.  
  11275. > 
  11276. > Based on an idea I mentioned a couple of threads ago, I'm currently
  11277. > working on setting this up and getting it tested; am waiting on
  11278. > the telco to point another number at my head-of-huntgroup line (they
  11279. > say it'll take 'em till Friday 19th to do it *roll* Yes, I told 'em
  11280. > that if they gave me dialup access to their switch I could do it
  11281. > in the time it took me to ask them. Of course, they thought I was
  11282. > pretty good at being a comedian).
  11283. > 
  11284. > The basic idea is to have two configurations...one with all the
  11285. > bells and whistles, and one that's more a generic work-with-anything
  11286. > configuration with no 56k or v.42bis, etc. If a customer has trouble
  11287. > with our main number (which is configged to kick ass for the ones
  11288. > who have fancy modems that actually work), they just try our secondary
  11289. > number (which is configged to get anything connected, including me
  11290. > whistling a 300bps carrier).
  11291. > 
  11292. > Sure, one can get the customer to turn it all off on their end (as
  11293. > we currently do), but I don't like that solution. It requires the
  11294. > customer to have to learn too much about modems for one. And the
  11295. > killer is the amount of time tech support is online with someone's
  11296. > mom trying to get her to type strange things in a strange panel
  11297. > (something she *never* had to do when she was with AOL, she'll
  11298. > remind you).
  11299. > 
  11300. > So getting the customer to turn it off is *lame*. Anything I can do
  11301. > to avoid it must be attempted. If I succeed, I fully expect higher
  11302. > customer satisfaction and yet another stick I can smack my competition
  11303. > with.
  11304. > 
  11305. > So, I can't be of much help now, but I will be posting my results
  11306. > here.
  11307. > 
  11308. > Couple of things I'd investigate in your position tho...make sure
  11309. > that you're getting all the dnis digits, or if you're getting a
  11310. > subset, make sure it's the same in your hdsp config. And definately
  11311. > verify your init strings of course....
  11312. > 
  11313. > Lon Stockton
  11314. > MoonStar
  11315. > 
  11316. > 
  11317. > On Wed, 10 Mar 1999, Randy McMillan wrote (without any word wrap):
  11318. > 
  11319. > > I have been trying to set up a way for users whose modems won't
  11320. > > negotiate with the v.90 code on our quad modems to call a number
  11321. > > other than our huntgroup lead number and then based on that DNIS
  11322. > > number limit the modem to v.34 speeds.  So far it hasn't worked
  11323. > > (it still connects at v.90 speeds).  I am getting the DNIS digits,
  11324. > > but perhaps my init strings were not correct.  Any help would be
  11325. > > apreciated.
  11326. > 
  11327. > 
  11328. > -
  11329. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11330. >  with "unsubscribe usr-tc" in the body of the message.
  11331. >  For information on digests or retrieving files and old messages send
  11332. >  "help" to the same address.  Do not use quotes in your message.
  11333. > 
  11334.  
  11335.  
  11336. -
  11337.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11338.  with "unsubscribe usr-tc" in the body of the message.
  11339.  For information on digests or retrieving files and old messages send
  11340.  "help" to the same address.  Do not use quotes in your message.
  11341.  
  11342.  
  11343. -------------------------------------------------------------------------------
  11344.  
  11345. From: Jeff Mcadams <jeffm@iglou.com>
  11346. Subject: Re: (usr-tc) Is there a way to disable x2/v.90 with DNIS init strings?
  11347. Date: 10 Mar 1999 21:17:06 -0500 (EST)
  11348.  
  11349. Thus spake Mike Andrews
  11350. >This is a hell of a good idea ... sure would save us a lot of time with
  11351. >all the users afflicted with cheap modems.  If anyone has this working,
  11352. >please let us all know :)  We're using both Quads and DSP's, which
  11353. >complicates things a bit, though we are an all-PRI and all-ARC shop.
  11354.  
  11355. Oh, it is a great idea...and one that I'll definitely remember for
  11356. implementation here, but since we're dealing with a horrible mismash of
  11357. quads, DSPs, NETServers and Arcs at the moment, I don't even want to
  11358. *think* about implementing this until our environment settles down a
  11359. bit.  Primarily I think getting fully switched over to Arc's will be the
  11360. first part of getting this settled down.  Not sure *how* long its gonna
  11361. take (if ever) to really do away with all our quads.
  11362.  
  11363. Count me as another interested in the outcome of your experiments though
  11364. :)
  11365. -- 
  11366. Jeff McAdams                            Email: jeffm@iglou.com
  11367. Head Network Administrator              Voice: (502) 966-3848
  11368. IgLou Internet Services                        (800) 436-4456
  11369.  
  11370. -
  11371.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11372.  with "unsubscribe usr-tc" in the body of the message.
  11373.  For information on digests or retrieving files and old messages send
  11374.  "help" to the same address.  Do not use quotes in your message.
  11375.  
  11376.  
  11377. -------------------------------------------------------------------------------
  11378.  
  11379. From: Stephen Amadei <amadei@dandy.net>
  11380. Subject: Re: (usr-tc) Port Limit
  11381. Date: 10 Mar 1999 21:44:10 -0500 (EST)
  11382.  
  11383. On Wed, 10 Mar 1999, Jamie Orzechowski wrote:
  11384.  
  11385. > I believe www.tsmon.com will do what I need ... 
  11386.  
  11387. Yeah... but Cistron Radius is free.
  11388.  
  11389.                     ----Steve
  11390. Stephen Amadei
  11391. Director of MIS
  11392. Dandy Connections, Inc.
  11393. Atlantic City, NJ
  11394.  
  11395.  
  11396. -
  11397.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11398.  with "unsubscribe usr-tc" in the body of the message.
  11399.  For information on digests or retrieving files and old messages send
  11400.  "help" to the same address.  Do not use quotes in your message.
  11401.  
  11402.  
  11403. -------------------------------------------------------------------------------
  11404.  
  11405. From: Aaron Nabil <nabil@spiritone.com>
  11406. Subject: Re: (usr-tc) SREJ on Quads
  11407. Date: 11 Mar 1999 03:34:55 -0800 (PST)
  11408.  
  11409. Jim Johnson writes...
  11410. >What is the consensus opinion of leaving Selective Reject enabled on the
  11411. >quads? 
  11412.  
  11413. I re-enable it on my H-DSP's.
  11414.  
  11415. >The default setting is enabled when you restore a quad from defaults,
  11416. >but not on the HDMs.
  11417. >
  11418. >Does it cause more problems than it helps?
  11419.  
  11420. I hope not.
  11421.  
  11422. -a
  11423.  
  11424. -
  11425.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11426.  with "unsubscribe usr-tc" in the body of the message.
  11427.  For information on digests or retrieving files and old messages send
  11428.  "help" to the same address.  Do not use quotes in your message.
  11429.  
  11430.  
  11431. -------------------------------------------------------------------------------
  11432.  
  11433. From: Robert von Bismarck <rvb@petrel.ch>
  11434. Subject: (usr-tc) About that Siemens-3com deal...
  11435. Date: 11 Mar 1999 14:48:19 +0100
  11436.  
  11437. Here's one more hint...
  11438.  
  11439. http://www.internet.siemens.com/ISB/products/ip/iXpress2000.html
  11440.  
  11441. Cheers,
  11442.  
  11443. Robert
  11444.  
  11445. --
  11446. Robert von Bismarck
  11447. Network Systems Engineer
  11448. Petrel Communications SA / SPAN
  11449. Tel : +41 22 304 47 47
  11450. Fax : +41 22 300 48 43
  11451. WWW : http://www.petrel.ch
  11452. e-mail : rvb@petrel.ch
  11453.  
  11454.  
  11455. -
  11456.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11457.  with "unsubscribe usr-tc" in the body of the message.
  11458.  For information on digests or retrieving files and old messages send
  11459.  "help" to the same address.  Do not use quotes in your message.
  11460.  
  11461.  
  11462. -------------------------------------------------------------------------------
  11463.  
  11464. From: "Jason W." <jwatkins@iland.net>
  11465. Subject: (usr-tc) root logging to radius..
  11466. Date: 11 Mar 1999 12:10:58 -0600
  11467.  
  11468. If this has been answered before I apologize...
  11469. Is there anyway to prevent the HiPer ARC from
  11470. logging telnet sessions to Radius Accounting?
  11471.  
  11472.  
  11473. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  11474. Jason W   jwatkins@iland.net 
  11475. I-Land NOC Tech http://www.iland.net
  11476. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  11477.  
  11478.  
  11479. -
  11480.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11481.  with "unsubscribe usr-tc" in the body of the message.
  11482.  For information on digests or retrieving files and old messages send
  11483.  "help" to the same address.  Do not use quotes in your message.
  11484.  
  11485.  
  11486. -------------------------------------------------------------------------------
  11487.  
  11488. From: <vanhalen@coredcs.com>
  11489. Subject: Re: (usr-tc) root logging to radius..
  11490. Date: 11 Mar 1999 12:35:56 -0600 (CST)
  11491.  
  11492. I couldbe way off base here, but it may be that you need to turn root
  11493. dialin access off.
  11494.  
  11495. Steve
  11496.  
  11497. On Thu, 11 Mar 1999, Jason W. wrote:
  11498.  
  11499. > If this has been answered before I apologize...
  11500. > Is there anyway to prevent the HiPer ARC from
  11501. > logging telnet sessions to Radius Accounting?
  11502. > 
  11503. > 
  11504. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  11505. > Jason W   jwatkins@iland.net 
  11506. > I-Land NOC Tech http://www.iland.net
  11507. > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
  11508. > 
  11509. > 
  11510. > -
  11511. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11512. >  with "unsubscribe usr-tc" in the body of the message.
  11513. >  For information on digests or retrieving files and old messages send
  11514. >  "help" to the same address.  Do not use quotes in your message.
  11515. > 
  11516.  
  11517.  
  11518. -
  11519.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11520.  with "unsubscribe usr-tc" in the body of the message.
  11521.  For information on digests or retrieving files and old messages send
  11522.  "help" to the same address.  Do not use quotes in your message.
  11523.  
  11524.  
  11525. -------------------------------------------------------------------------------
  11526.  
  11527. From: "Jason Cropper" <jason@clearsail.net>
  11528. Subject: RE: (usr-tc) Port Limit
  11529. Date: 11 Mar 1999 15:44:02 -0600
  11530.  
  11531. I am using Merit Radius 3.6b (freely available)on FreeBSD.  This is my
  11532. default user entry:
  11533.  
  11534. DEFAULT Authentication-Type = Unix-PW
  11535.         Service-Type = Framed,
  11536.         Simultaneous-Use = 1,
  11537.         Port-Limit = 1,
  11538.         Session-Timeout = 14400,
  11539.         Idle-Timeout = 900,
  11540.         Filter-Id = filter,
  11541.         Framed-Protocol = PPP,
  11542.         Framed-IP-Netmask = 255.255.255.0,
  11543.         Framed-Routing = None,
  11544.         Framed-MTU = 1500,
  11545.         Framed-Compression = Van-Jacobson-TCP-IP
  11546.  
  11547. Works like a charm with HiperARCs and Netservers.  For Multilink customers,
  11548. I enter a separate profile with no port limitation.
  11549.  
  11550. Jason Cropper
  11551. CTO
  11552. ClearSail Communications
  11553. http://www.clearsail.net
  11554.  
  11555. > -----Original Message-----
  11556. > From: owner-usr-tc@lists.xmission.com
  11557. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jamie Orzechowski
  11558. > Sent: Wednesday, March 10, 1999 19:44
  11559. > To: usr-tc@lists.xmission.com
  11560. > Subject: Re: (usr-tc) Port Limit
  11561. >
  11562. >
  11563. > I believe www.tsmon.com will do what I need ...
  11564. >
  11565. > -----Original Message-----
  11566. > From: Stephen Amadei <amadei@dandy.net>
  11567. > To: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  11568. > Date: Wednesday, March 10, 1999 8:31 PM
  11569. > Subject: Re: (usr-tc) Port Limit
  11570. >
  11571. >
  11572. > >On Wed, 10 Mar 1999, Jamie Orzechowski wrote:
  11573. > >
  11574. > >> I am just wondering about port limits.
  11575. > >>
  11576. > >> I want to set my ARC up so that ONLY 1 userID can be logged in at once.
  11577. > >> I still want to allow for multilink PPP though sp that if there radius
  11578. > >> attribute of Port-Limit = 2 they will be allowed multilink.
  11579. > >>
  11580. > >> I tried a "set user default port_limit 1" but then I noticed that some
  11581. > >> people we logged in multiple times ... any ideas??
  11582. > >>
  11583. > >> is this possible on netserver also??
  11584. > >
  11585. > >Apparently, Port-Limit won't stop multiple logins.
  11586. > >
  11587. > >Really, Radius is a poor tool for limiting multiple logins. However, if
  11588. > >you use Cistron Radius, it has a Simultaneous-Use attribute that you can
  11589. > >use... that's the good news.  It calls a small script that checks your
  11590. > >access server to see if the original user is still on.  The bad news is
  11591. > >that the Total Control is a PITA to check what users are on.  The good
  11592. > >news is that a few Perl add-ons will give you the ability to
  11593. > check the TC.
  11594. > >However, this is as far as I have gotten since I can't find the "pmcmd"
  11595. > >script/program.  Oh well...
  11596. > >
  11597. > > ----Steve
  11598. > >Stephen Amadei
  11599. > >Director of MIS
  11600. > >Dandy Connections, Inc.
  11601. > >Atlantic City, NJ
  11602. > >
  11603. > >
  11604. > >-
  11605. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11606. > > with "unsubscribe usr-tc" in the body of the message.
  11607. > > For information on digests or retrieving files and old messages send
  11608. > > "help" to the same address.  Do not use quotes in your message.
  11609. > >
  11610. > >
  11611. >
  11612. >
  11613. > -
  11614. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11615. >  with "unsubscribe usr-tc" in the body of the message.
  11616. >  For information on digests or retrieving files and old messages send
  11617. >  "help" to the same address.  Do not use quotes in your message.
  11618. >
  11619.  
  11620.  
  11621. -
  11622.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11623.  with "unsubscribe usr-tc" in the body of the message.
  11624.  For information on digests or retrieving files and old messages send
  11625.  "help" to the same address.  Do not use quotes in your message.
  11626.  
  11627.  
  11628. -------------------------------------------------------------------------------
  11629.  
  11630. From: Lostboy <lostboy@spacelink.com>
  11631. Subject: (usr-tc) Formula...
  11632. Date: 12 Mar 1999 00:42:52 +0000 (GMT)
  11633.  
  11634.  
  11635.   Does anyone know how to translate between the accounting
  11636. session ID as returned in Radius accounting packets and the
  11637. session ID's returned via SNMP?  I'm guessing the SNMP items
  11638. are internal versions of the same ID's?
  11639.  
  11640.   Also, is there any easy way to get a list of sessions via SNMP?
  11641.  
  11642. -Jim
  11643.  
  11644. -
  11645.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11646.  with "unsubscribe usr-tc" in the body of the message.
  11647.  For information on digests or retrieving files and old messages send
  11648.  "help" to the same address.  Do not use quotes in your message.
  11649.  
  11650.  
  11651. -------------------------------------------------------------------------------
  11652.  
  11653. From: Jesse Sipprell <jss@evcom.net>
  11654. Subject: (usr-tc) TFTP Access Violation?
  11655. Date: 12 Mar 1999 11:29:07 -0500
  11656.  
  11657. Tried to upload new code to a HARC today, twice (remotely, no less).
  11658.  
  11659. First time, at 13% complete, TCM informed me "Failed: TFTP Access Violation".
  11660. Second time, at 17% complete, same error.
  11661.  
  11662. Anyone have any clues?
  11663.  
  11664. Thanks!
  11665.  
  11666. -- 
  11667. Jesse Sipprell
  11668. Technical Operations Director
  11669. Evolution Communications, Inc.
  11670. 800-496-4736 (ext 106)
  11671.  
  11672. * Finger jss@evcom.net for my PGP Public Key *
  11673.  
  11674. -
  11675.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11676.  with "unsubscribe usr-tc" in the body of the message.
  11677.  For information on digests or retrieving files and old messages send
  11678.  "help" to the same address.  Do not use quotes in your message.
  11679.  
  11680.  
  11681. -------------------------------------------------------------------------------
  11682.  
  11683. From: "Kalev Nurklik" <kalev@mail.lbi.ee>
  11684. Subject: Re: (usr-tc) TFTP Access Violation?
  11685. Date: 12 Mar 1999 18:40:49 +0200
  11686.  
  11687. > First time, at 13% complete, TCM informed me "Failed: TFTP Access
  11688. > Violation". Second time, at 17% complete, same error.
  11689. > 
  11690. > Anyone have any clues?
  11691.  
  11692. Reboot the HARC. You probably have too many deleted sectors
  11693. on HARCs flash (do "list files") and rebooting seem to defrag it.
  11694. At least it worked for me.
  11695.  
  11696.  
  11697. __________________________________
  11698. Kalev Nurklik
  11699. MicroLink Online
  11700. Sakala 19, 10141 Tallinn, Estonia
  11701. Tel: +372 6 308 909
  11702. Fax: +372 6 308 901
  11703. E-mail: k.nurklik@online.ee
  11704. http://www.online.ee
  11705.  
  11706. -
  11707.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11708.  with "unsubscribe usr-tc" in the body of the message.
  11709.  For information on digests or retrieving files and old messages send
  11710.  "help" to the same address.  Do not use quotes in your message.
  11711.  
  11712.  
  11713. -------------------------------------------------------------------------------
  11714.  
  11715. From: "John Verreault" <john@aei.ca>
  11716. Subject: RE: (usr-tc) TFTP Access Violation?
  11717. Date: 12 Mar 1999 11:44:43 -0500
  11718.  
  11719. I had the same probmen. I think this is very serious. I had to load the code
  11720. by booting the unit and loading the code from a tftp server.
  11721. Here are the instructions from 3com
  11722.  
  11723. john
  11724.  
  11725. Here are two options to load code.
  11726.  
  11727. 1. You can use the console port and zmodem download the code
  11728. 2. You can set the hiper arc to load the code from bootp.
  11729.  
  11730. Here is how you do it and its merits/de-merits
  11731.  
  11732. case 1:
  11733.  
  11734. Reboot the card and make sure you have a console / Hiper term  and when
  11735. the card boots download the code using zmodem.
  11736.  
  11737. only one problem here - you will loose all the cofiguration.
  11738.  
  11739.  
  11740. Case 2:
  11741.  
  11742. set the hiper arc to load code from a boot p server
  11743.  
  11744. First set the tftp server and put the code at the tftp server.
  11745.  
  11746. second configure the hiper arc to load the code from the bootp server.
  11747.  
  11748. set booTROM ip inTERFACE eth:1 addRESS <ip address ofyour hiper arc>
  11749. netmask <netmask for the hiper arc> tftpserver <ip address of the tftp
  11750. server> tftp_boot once gateway <gateway/router's ip address from the
  11751. hiper arc> loadfile < the code file name on the tftpserver>
  11752.  
  11753. save all
  11754.  
  11755.  
  11756. now reboot the card
  11757.  
  11758. it will then start loading the file
  11759.  
  11760. no crash or loss of any config in this case
  11761.  
  11762. krish
  11763.  
  11764.         \    T.S.V. Krishnan  \
  11765.          \      Network System Engineer \ ( : - : )
  11766.           \     3Com ............   \
  11767.         ----------------------------------------------/
  11768.  
  11769.  
  11770.  
  11771. > -----Original Message-----
  11772. > From: owner-usr-tc@lists.xmission.com
  11773. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jesse Sipprell
  11774. > Sent: Friday, March 12, 1999 11:29 AM
  11775. > To: usr-tc@lists.xmission.com
  11776. > Subject: (usr-tc) TFTP Access Violation?
  11777. >
  11778. >
  11779. > Tried to upload new code to a HARC today, twice (remotely, no less).
  11780. >
  11781. > First time, at 13% complete, TCM informed me "Failed: TFTP Access
  11782. > Violation".
  11783. > Second time, at 17% complete, same error.
  11784. >
  11785. > Anyone have any clues?
  11786. >
  11787. > Thanks!
  11788. >
  11789. > --
  11790. > Jesse Sipprell
  11791. > Technical Operations Director
  11792. > Evolution Communications, Inc.
  11793. > 800-496-4736 (ext 106)
  11794. >
  11795. > * Finger jss@evcom.net for my PGP Public Key *
  11796. >
  11797. > -
  11798. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11799. >  with "unsubscribe usr-tc" in the body of the message.
  11800. >  For information on digests or retrieving files and old messages send
  11801. >  "help" to the same address.  Do not use quotes in your message.
  11802. >
  11803.  
  11804.  
  11805. -
  11806.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11807.  with "unsubscribe usr-tc" in the body of the message.
  11808.  For information on digests or retrieving files and old messages send
  11809.  "help" to the same address.  Do not use quotes in your message.
  11810.  
  11811.  
  11812. -------------------------------------------------------------------------------
  11813.  
  11814. From: Marlo Montanaro <marlo@monmouth.com>
  11815. Subject: (usr-tc) V5.0 Security and Accounting Radius Server Software
  11816. Date: 12 Mar 1999 12:00:08 -0500
  11817.  
  11818. Does anyone know where I can find detailed information on 3COM V5.0 =
  11819. Security and Accounting Radius Server Software for Windows NT?
  11820.  
  11821. I've searched the 3COM website and can't seem to locate anything other =
  11822. than the basic "this is what it is" product info.  I would like to find =
  11823. part numbers, detailed specs, pricing info, etc. and there are no links =
  11824. to more detailed information.
  11825.  
  11826. Also, I would like comments from anyone using this software- how easy is =
  11827. it to install and configure, etc.?
  11828.  
  11829. Thanks!
  11830.  
  11831. Regards...
  11832. Marlo Montanaro
  11833.  
  11834.  
  11835. -
  11836.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11837.  with "unsubscribe usr-tc" in the body of the message.
  11838.  For information on digests or retrieving files and old messages send
  11839.  "help" to the same address.  Do not use quotes in your message.
  11840.  
  11841.  
  11842. -------------------------------------------------------------------------------
  11843.  
  11844. From: andy <smitha@mach3ww.com>
  11845. Subject: (usr-tc) modem settings
  11846. Date: 12 Mar 1999 11:58:34 -0600 (CST)
  11847.  
  11848.  
  11849. I have a few questions... They have been touched on in the past but I
  11850. didn't see any def. answers in the archives...
  11851.  
  11852. 1. Should I enable or disable selective reject on my quad modems and
  11853. hdms? Do enough modems have SREJ to make it worth while? 
  11854.  
  11855. 2. Should I enable or disable v.42bis on my quads and HDMs? Is this worth
  11856. while in the long run? Will I have to do this with an init string?
  11857.  
  11858. 3. Is ppp offloading good or bad for quads? hdms? What does it do???
  11859.  
  11860. I'm trying to set the best modem configuration that will work for the
  11861. widest type and number of modems in order to minimize drop-out and
  11862. connection problems. 
  11863.  
  11864. Thank you.
  11865.  
  11866. -
  11867.     andrew
  11868.  
  11869.  
  11870. -
  11871.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11872.  with "unsubscribe usr-tc" in the body of the message.
  11873.  For information on digests or retrieving files and old messages send
  11874.  "help" to the same address.  Do not use quotes in your message.
  11875.  
  11876.  
  11877. -------------------------------------------------------------------------------
  11878.  
  11879. From: "Tony Loosle" <tony@tcsourceone.com>
  11880. Subject: Re: (usr-tc) V5.0 Security and Accounting Radius Server Software
  11881. Date: 12 Mar 1999 11:01:02 -0700
  11882.  
  11883. stay away from it at ALL costs.  stay far away!!
  11884.  
  11885. they acutally have a version 6.??, but it's full of bugs, use's access, run's your cpu to 100% all the time.  You can't use port restrictions in every other version, it forgets who is logged in, then won't log them out and won't let them back in.
  11886.  
  11887. There is of couse NO support whatsoever from USR!
  11888.  
  11889. tony
  11890.  
  11891.  
  11892. Marlo Montanaro wrote:
  11893.  
  11894. > Does anyone know where I can find detailed information on 3COM V5.0 Security and Accounting Radius Server Software for Windows NT?
  11895. >
  11896. > I've searched the 3COM website and can't seem to locate anything other than the basic "this is what it is" product info.  I would like to find part numbers, detailed specs, pricing info, etc. and there are no links to more detailed information.
  11897. >
  11898. > Also, I would like comments from anyone using this software- how easy is it to install and configure, etc.?
  11899. >
  11900. > Thanks!
  11901. >
  11902. > Regards...
  11903. > Marlo Montanaro
  11904. >
  11905. > -
  11906. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11907. >  with "unsubscribe usr-tc" in the body of the message.
  11908. >  For information on digests or retrieving files and old messages send
  11909. >  "help" to the same address.  Do not use quotes in your message.
  11910.  
  11911.  
  11912. -
  11913.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  11914.  with "unsubscribe usr-tc" in the body of the message.
  11915.  For information on digests or retrieving files and old messages send
  11916.  "help" to the same address.  Do not use quotes in your message.
  11917.  
  11918.  
  11919. -------------------------------------------------------------------------------
  11920.  
  11921. From: "David Bachta" <David_Bachta@mw.3com.com>
  11922. Subject: Re: (usr-tc) TFTP Access Violation?
  11923. Date: 12 Mar 1999 12:28:44 -0600
  11924.  
  11925.  
  11926.  
  11927. Hi Jesse,
  11928.  
  11929. Have you tried taking TCM out of the picture and TFTPing the file directly to
  11930. the ARC?  Below are directions if you want to give it a shot.  Hope this helps.
  11931.  
  11932. Regards,
  11933. David
  11934.  
  11935.  
  11936. 1)  At ARC "add tftp client <ip address>" (this is the address of the box
  11937. you are tftping from.  You can use 0.0.0.0 to allow anyone to tftp to the
  11938. ARC, although probably not a good idea)
  11939.  
  11940. 2)  At TFTP box "tftp <ip address>" (this is the IP address or hostname of
  11941. the ARC)
  11942.  
  11943. 3)  At TFTP prompt "bin" (binary mode transfer)
  11944.  
  11945. 4)  At TFTP prompt "verbose" (verbose mode if you like)
  11946.  
  11947. 5)  At TFTP prompt "trace" (trace packet progress if you like)
  11948.  
  11949. 6)  At TFTP prompt "put <filename> netserve.dmf"  (if the filename that you
  11950. are uploading is named 'netserve.dmf' then you can just do a "put
  11951. netserve.dmf".  If it isn't named netserve.dmf you have to add the second
  11952. argument so it gets renamed on the ARC as netserve.dmf.  For example, "put
  11953. ne040111.dmf netserve.dmf"
  11954.  
  11955. 7) Reboot ARC for code to take effect.
  11956.  
  11957. I always use a Sun box to TX files but if you are a windows guy there are lots
  11958. of TFTP clients
  11959. available for W95 and NT.  I can't make any recommendations but I know
  11960. there are a few you might want to check out on www.winfiles.com.
  11961.  
  11962.  
  11963.  
  11964.  
  11965. Jesse Sipprell <jss@evcom.net> on 03/12/99 11:22:06 AM
  11966.  
  11967. Please respond to usr-tc@lists.xmission.com
  11968.  
  11969. cc:    (David Bachta/MW/US/3Com)
  11970.  
  11971.  
  11972.  
  11973.  
  11974. On Fri, Mar 12, 1999 at 11:44:43AM -0500, John Verreault wrote:
  11975. > I had the same probmen. I think this is very serious. I had to load the code
  11976. > by booting the unit and loading the code from a tftp server.
  11977. > Here are the instructions from 3com
  11978. >
  11979. > john
  11980.  
  11981. Ugg.  This is indeed painful for us, especially since the unit is located 250
  11982. miles away and no staff are available at the location to manually attend to
  11983. it [although we can remotely power the unit on/off].
  11984.  
  11985. > Here are two options to load code.
  11986. >
  11987. > 1. You can use the console port and zmodem download the code
  11988. > 2. You can set the hiper arc to load the code from bootp.
  11989. >
  11990. > Here is how you do it and its merits/de-merits
  11991. >
  11992. > case 1:
  11993. >
  11994. > Reboot the card and make sure you have a console / Hiper term  and when
  11995. > the card boots download the code using zmodem.
  11996. >
  11997. > only one problem here - you will loose all the cofiguration.
  11998. >
  11999. >
  12000. > Case 2:
  12001. >
  12002. > set the hiper arc to load code from a boot p server
  12003. >
  12004. > First set the tftp server and put the code at the tftp server.
  12005. >
  12006. > second configure the hiper arc to load the code from the bootp server.
  12007. >
  12008. > set booTROM ip inTERFACE eth:1 addRESS <ip address ofyour hiper arc>
  12009. > netmask <netmask for the hiper arc> tftpserver <ip address of the tftp
  12010. > server> tftp_boot once gateway <gateway/router's ip address from the
  12011. > hiper arc> loadfile < the code file name on the tftpserver>
  12012. >
  12013. > save all
  12014. >
  12015. >
  12016. > now reboot the card
  12017. >
  12018. > it will then start loading the file
  12019. >
  12020. > no crash or loss of any config in this case
  12021. >
  12022. > krish
  12023. >
  12024. > -----------------------------------------
  12025. >         \    T.S.V. Krishnan  \
  12026. >          \      Network System Engineer \ ( : - : )
  12027. >           \     3Com ............   \
  12028. >         ----------------------------------------------/
  12029. >
  12030. >
  12031. >
  12032. > > -----Original Message-----
  12033. > > From: owner-usr-tc@lists.xmission.com
  12034. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Jesse Sipprell
  12035. > > Sent: Friday, March 12, 1999 11:29 AM
  12036. > > To: usr-tc@lists.xmission.com
  12037. > > Subject: (usr-tc) TFTP Access Violation?
  12038. > >
  12039. > >
  12040. > > Tried to upload new code to a HARC today, twice (remotely, no less).
  12041. > >
  12042. > > First time, at 13% complete, TCM informed me "Failed: TFTP Access
  12043. > > Violation".
  12044. > > Second time, at 17% complete, same error.
  12045. > >
  12046. > > Anyone have any clues?
  12047. > >
  12048. > > Thanks!
  12049. > >
  12050. > > --
  12051. > > Jesse Sipprell
  12052. > > Technical Operations Director
  12053. > > Evolution Communications, Inc.
  12054. > > 800-496-4736 (ext 106)
  12055. > >
  12056. > > * Finger jss@evcom.net for my PGP Public Key *
  12057. > >
  12058. > > -
  12059. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12060. > >  with "unsubscribe usr-tc" in the body of the message.
  12061. > >  For information on digests or retrieving files and old messages send
  12062. > >  "help" to the same address.  Do not use quotes in your message.
  12063. > >
  12064. >
  12065. >
  12066. > -
  12067. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12068. >  with "unsubscribe usr-tc" in the body of the message.
  12069. >  For information on digests or retrieving files and old messages send
  12070. >  "help" to the same address.  Do not use quotes in your message.
  12071.  
  12072. --
  12073. Jesse Sipprell
  12074. Technical Operations Director
  12075. Evolution Communications, Inc.
  12076. 800-496-4736 (ext 106)
  12077.  
  12078. * Finger jss@evcom.net for my PGP Public Key *
  12079.  
  12080. -
  12081.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12082.  with "unsubscribe usr-tc" in the body of the message.
  12083.  For information on digests or retrieving files and old messages send
  12084.  "help" to the same address.  Do not use quotes in your message.
  12085.  
  12086.  
  12087.  
  12088.  
  12089.  
  12090.  
  12091.  
  12092.  
  12093. -
  12094.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12095.  with "unsubscribe usr-tc" in the body of the message.
  12096.  For information on digests or retrieving files and old messages send
  12097.  "help" to the same address.  Do not use quotes in your message.
  12098.  
  12099.  
  12100. -------------------------------------------------------------------------------
  12101.  
  12102. From: Blake Fithen <fithen@NetworksPlus.com>
  12103. Subject: RE: (usr-tc) V5.0 Security and Accounting Radius Server Software
  12104. Date: 12 Mar 1999 12:28:17 -0600
  12105.  
  12106. I would also recommend staying away.  Use Emerald or Cistron or
  12107. something else.  3Com claims the 100% cpu thing is a MS bug (surprised?)
  12108. and i somewhat believe them because the machine we ran it on did 
  12109. not behave like it was stressed.  also i you look at the you look at 
  12110. the password in the access database will notice the "encryption"
  12111. is nothing more than a constant added to the ASCII value of the 
  12112. character in the password.  i may be totally ignorant on this type 
  12113. of encryption but it looks like you only need your Cap'n Crunch decoder
  12114. ring, the access file, half a brain and your in!  when we realized this
  12115. we turned white with fear.  IOW stay away from 3com's SA server.  we
  12116. went with emerald a while ago and although there is a bit of a learning
  12117. curve it was well worth it.  contact me privately if you want more
  12118. reasons to stay away.
  12119.  
  12120. blake
  12121.  
  12122.  
  12123.     
  12124.  
  12125.  
  12126. > -----Original Message-----
  12127. > From: Tony Loosle [mailto:tony@tcsourceone.com]
  12128. > Sent: Friday, March 12, 1999 12:01 PM
  12129. > To: usr-tc@lists.xmission.com
  12130. > Subject: Re: (usr-tc) V5.0 Security and Accounting Radius Server
  12131. > Software
  12132. > 
  12133. > 
  12134. > stay away from it at ALL costs.  stay far away!!
  12135. > 
  12136. > they acutally have a version 6.??, but it's full of bugs, 
  12137. > use's access, run's your cpu to 100% all the time.  You can't 
  12138. > use port restrictions in every other version, it forgets who 
  12139. > is logged in, then won't log them out and won't let them back in.
  12140. > 
  12141. > There is of couse NO support whatsoever from USR!
  12142. > 
  12143. > tony
  12144. > 
  12145. > 
  12146. > Marlo Montanaro wrote:
  12147. > 
  12148. > > Does anyone know where I can find detailed information on 
  12149. > 3COM V5.0 Security and Accounting Radius Server Software for 
  12150. > Windows NT?
  12151. > >
  12152. > > I've searched the 3COM website and can't seem to locate 
  12153. > anything other than the basic "this is what it is" product 
  12154. > info.  I would like to find part numbers, detailed specs, 
  12155. > pricing info, etc. and there are no links to more detailed 
  12156. > information.
  12157. > >
  12158. > > Also, I would like comments from anyone using this 
  12159. > software- how easy is it to install and configure, etc.?
  12160. > >
  12161. > > Thanks!
  12162. > >
  12163. > > Regards...
  12164. > > Marlo Montanaro
  12165. > >
  12166. > > -
  12167. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12168. > >  with "unsubscribe usr-tc" in the body of the message.
  12169. > >  For information on digests or retrieving files and old 
  12170. > messages send
  12171. > >  "help" to the same address.  Do not use quotes in your message.
  12172. > 
  12173. > 
  12174. > -
  12175. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12176. >  with "unsubscribe usr-tc" in the body of the message.
  12177. >  For information on digests or retrieving files and old messages send
  12178. >  "help" to the same address.  Do not use quotes in your message.
  12179. > 
  12180.  
  12181. -
  12182.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12183.  with "unsubscribe usr-tc" in the body of the message.
  12184.  For information on digests or retrieving files and old messages send
  12185.  "help" to the same address.  Do not use quotes in your message.
  12186.  
  12187.  
  12188. -------------------------------------------------------------------------------
  12189.  
  12190. From: Brian Jacklin <csabmj@mail.tds.net>
  12191. Subject: (usr-tc) 1200baud
  12192. Date: 12 Mar 1999 12:44:55 -0600 (CST)
  12193.  
  12194. I've got a couple of old quad A/D cards that I dug up.  I can only get them
  12195. to pick up at 1200baud, I checked all the DTE settings, and put the latest
  12196. code on them but no luck.  Is there anything else I can try?  
  12197. Thanks
  12198.  
  12199.  
  12200. -
  12201.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12202.  with "unsubscribe usr-tc" in the body of the message.
  12203.  For information on digests or retrieving files and old messages send
  12204.  "help" to the same address.  Do not use quotes in your message.
  12205.  
  12206.  
  12207. -------------------------------------------------------------------------------
  12208.  
  12209. From: Scott Boggs <sboggs@unitedbank.net>
  12210. Subject: (usr-tc) odd problem
  12211. Date: 12 Mar 1999 13:47:56 -0500
  12212.  
  12213. We have recently changed our HiperDSPs from channelized T1s
  12214. to PRIs.  The local dial up # works fine, an 800 # that directs to the
  12215. local # has stopped working.  The connection completes, and a valid
  12216. IP is assigned to the PC (verified by winipcfg).  The IP and user name do
  12217. not show up
  12218. on the TCtrl box (list sess, show users, etc.).  
  12219.  
  12220. The connection is there, but the client PC cant ping or route anywhere.
  12221. It is a plain-jane ISP set up (just PPP)
  12222.  
  12223. Any ideas?
  12224.  
  12225. Thanks,
  12226. Scott Boggs
  12227. IS Manager
  12228. United Bank
  12229.  
  12230.  
  12231.  
  12232. -
  12233.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12234.  with "unsubscribe usr-tc" in the body of the message.
  12235.  For information on digests or retrieving files and old messages send
  12236.  "help" to the same address.  Do not use quotes in your message.
  12237.  
  12238.  
  12239. -------------------------------------------------------------------------------
  12240.  
  12241. From: Scott Boggs <sboggs@unitedbank.net>
  12242. Subject: RE: (usr-tc) V5.0 Security and Accounting Radius Server Software
  12243. Date: 12 Mar 1999 14:35:46 -0500
  12244.  
  12245. We formerly used Ascend Access control with a max4000.
  12246. When we put in our TotCtrl box, we needed a RADIUS that
  12247. was usable with multiple hardware vendors.  The 3com RADIUS
  12248. couldnt do it.  And the Access97 guts was needless overhead in my opinion. 
  12249. I found a great RADIUS in "Steel belted RADIUS" from
  12250. Funk software.  No complaints, it supports generic
  12251. and vendor specific attributes.  Services both our Ascend MAX and TotCtrl.
  12252.  
  12253. Regards,
  12254. Scott Boggs
  12255. IS Manager
  12256. United Bank
  12257.  
  12258. > -----Original Message-----
  12259. > From:    Blake Fithen [SMTP:fithen@NetworksPlus.com]
  12260. > Sent:    Friday, March 12, 1999 1:28 PM
  12261. > To:    'usr-tc@lists.xmission.com'
  12262. > Subject:    RE: (usr-tc) V5.0 Security and Accounting Radius Server
  12263. > Software
  12264. > 
  12265. > I would also recommend staying away.  Use Emerald or Cistron or
  12266. > something else.  3Com claims the 100% cpu thing is a MS bug (surprised?)
  12267. > and i somewhat believe them because the machine we ran it on did 
  12268. > not behave like it was stressed.  also i you look at the you look at 
  12269. > the password in the access database will notice the "encryption"
  12270. > 
  12271.  
  12272. -
  12273.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12274.  with "unsubscribe usr-tc" in the body of the message.
  12275.  For information on digests or retrieving files and old messages send
  12276.  "help" to the same address.  Do not use quotes in your message.
  12277.  
  12278.  
  12279. -------------------------------------------------------------------------------
  12280.  
  12281. From: K Mitchell <mitch@keyconn.net>
  12282. Subject: RE: (usr-tc) V5.0 Security and Accounting Radius Server
  12283. Date: 12 Mar 1999 15:15:26 -0500
  12284.  
  12285. At 12:28 PM 3/12/99 -0600, you wrote:
  12286. >I would also recommend staying away.  Use Emerald or Cistron or
  12287. >something else.  3Com claims the 100% cpu thing is a MS bug (surprised?)
  12288. >and i somewhat believe them because the machine we ran it on did 
  12289. >not behave like it was stressed.  also i you look at the you look at 
  12290. >the password in the access database will notice the "encryption"
  12291. >is nothing more than a constant added to the ASCII value of the 
  12292. >character in the password.  i may be totally ignorant on this type 
  12293. >of encryption but it looks like you only need your Cap'n Crunch decoder
  12294. >ring, the access file, half a brain and your in!  when we realized this
  12295. >we turned white with fear.  IOW stay away from 3com's SA server.  we
  12296. >went with emerald a while ago and although there is a bit of a learning
  12297. >curve it was well worth it.  contact me privately if you want more
  12298. >reasons to stay away.
  12299.  
  12300.   I've been using S&A Server 5.5.3 mainly due to the cost(vendor threw it
  12301. in for free). It's been working ok for me as far as authentication goes,
  12302. but getting logging information from it has been a fruitless nightmare.
  12303. I've gone rounds with 3Com support about it that has been less than
  12304. helpful. Each time I approach 3Com, the scenario is similar;
  12305.  
  12306. Step 1: Reluctance to provide support since I didn't pay 3Com for it. I
  12307. don't care, take that up with the vendor that gave it to me. Finally, 3Com
  12308. grudgingly decides they'll help.
  12309.  
  12310. Step 2: After going over configuration/settings, etc, tech suggests a few
  12311. changes and tells me to make them and let him know whether or not that
  12312. solved the problem.
  12313.  
  12314. Step 3: I make the changes, seeing little or no improvement in the logging
  12315. information available. Try to contact the tech to inform him that the
  12316. changes haven't gotten things functional. Leave email and phone messages.
  12317.  
  12318. Step 4: Never hear back from tech, despite numerous emails/calls. After
  12319. another 2 months of frustration, revisit issue...back to Step 1.
  12320.  
  12321.   I've gone through this process 3 times in the last 7 or 8 months. As for
  12322. the CPU usage, it does keep my CPU pretty much pegged, but doesn't seem to
  12323. affect the machine. I have a mailserver on that machine also that doesn't
  12324. appear to be taking any performance hit from the Access CPU usage.
  12325.   I'd like to look at other RADIUS options, but I'm not sure what direction
  12326. to go in. I'm a little guy(250 or so users) and need something economical,
  12327. but also need to be able to import the S&A Server database as I don't keep
  12328. records of user passwords.
  12329.  
  12330. Any ideas?
  12331. Thanks,
  12332. Kirk
  12333.  
  12334.  
  12335.  
  12336. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  12337. Keystone Connect                http://www.keyconn.net
  12338. Altoona, PA   814-941-5000         We Unlock the World
  12339.  
  12340.  
  12341. -
  12342.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12343.  with "unsubscribe usr-tc" in the body of the message.
  12344.  For information on digests or retrieving files and old messages send
  12345.  "help" to the same address.  Do not use quotes in your message.
  12346.  
  12347.  
  12348. -------------------------------------------------------------------------------
  12349.  
  12350. From: Sean Herr <Sean@YNC.NET>
  12351. Subject: (usr-tc) How to clear ROM on ARC
  12352. Date: 12 Mar 1999 15:30:27 -0600
  12353.  
  12354. Can anyone tell me how to clear the Flash ROM on a HiperARC.  
  12355.  
  12356. Thanks,
  12357.  
  12358. Sean Herr
  12359.  
  12360. -
  12361.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12362.  with "unsubscribe usr-tc" in the body of the message.
  12363.  For information on digests or retrieving files and old messages send
  12364.  "help" to the same address.  Do not use quotes in your message.
  12365.  
  12366.  
  12367. -------------------------------------------------------------------------------
  12368.  
  12369. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  12370. Subject: Re: (usr-tc) How to clear ROM on ARC
  12371. Date: 12 Mar 1999 15:58:25 -0600 (CST)
  12372.  
  12373.  
  12374. On Fri, 12 Mar 1999, Sean Herr wrote:
  12375.  
  12376. > Can anyone tell me how to clear the Flash ROM on a HiperARC.  
  12377. > 
  12378.  
  12379. You can do a delete config
  12380.  
  12381. On the hiper arc login as admin and type delete config
  12382.  
  12383. or 
  12384.  
  12385. you can do a zmodem download of the code that will erase all the config 
  12386. and clear the flash.
  12387.  
  12388. krish
  12389.  
  12390.  
  12391. > Thanks,
  12392. > 
  12393. > Sean Herr
  12394. > 
  12395. > -
  12396. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12397. >  with "unsubscribe usr-tc" in the body of the message.
  12398. >  For information on digests or retrieving files and old messages send
  12399. >  "help" to the same address.  Do not use quotes in your message.
  12400. > 
  12401.  
  12402. -
  12403.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12404.  with "unsubscribe usr-tc" in the body of the message.
  12405.  For information on digests or retrieving files and old messages send
  12406.  "help" to the same address.  Do not use quotes in your message.
  12407.  
  12408.  
  12409. -------------------------------------------------------------------------------
  12410.  
  12411. From: Paul Oster <devious@minot.com>
  12412. Subject: Re: (usr-tc) odd problem
  12413. Date: 12 Mar 1999 15:49:49 -0600 (CST)
  12414.  
  12415. I've got a similar problem on my side too... ever since we started using
  12416. ARC's, I've had a HELL of a time with Sportster modems...  they will
  12417. connect, negotiate fine, get to SOME web site (3 that they have problems
  12418. with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a
  12419. WINMODEM, I dont have this problem from home, nor do I have this problem
  12420. from the office (I'm dialing into the SAME modem pool as my customers from
  12421. home)  The only difference in the setup is my modem vs theirs... it seems
  12422. to be centered around the Sportster 56K v.90 modem (X2's that were
  12423. converted are not affected.)  The problem exists in chassis that have both
  12424. Quad Modems, and DSP's, however, my remaining chassis with Quads and
  12425. Netservers are not affected... someone PLEASE toss me a bone, I've been on
  12426. the phone with 3com support for 42 minutes now, without so much as a clue
  12427. as to why this is happening, any suggestions?
  12428.  
  12429. Paul M. Oster <devious@minot.com>               http://www.minot.com/
  12430. Magic Internet Services                         (701) 838-1265
  12431. Minots FIRST Internet Connection
  12432.  
  12433. -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  12434.  
  12435. "I might not agree with what you have to say but I will defend, to 
  12436. my death, your right to say it." - Voltaire
  12437.  
  12438. On Fri, 12 Mar 1999, Scott Boggs wrote:
  12439.  
  12440. > We have recently changed our HiperDSPs from channelized T1s
  12441. > to PRIs.  The local dial up # works fine, an 800 # that directs to the
  12442. > local # has stopped working.  The connection completes, and a valid
  12443. > IP is assigned to the PC (verified by winipcfg).  The IP and user name do
  12444. > not show up
  12445. > on the TCtrl box (list sess, show users, etc.).  
  12446. > 
  12447. > The connection is there, but the client PC cant ping or route anywhere.
  12448. > It is a plain-jane ISP set up (just PPP)
  12449. > 
  12450. > Any ideas?
  12451. > 
  12452. > Thanks,
  12453. > Scott Boggs
  12454. > IS Manager
  12455. > United Bank
  12456. > 
  12457. > 
  12458. > 
  12459. > -
  12460. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12461. >  with "unsubscribe usr-tc" in the body of the message.
  12462. >  For information on digests or retrieving files and old messages send
  12463. >  "help" to the same address.  Do not use quotes in your message.
  12464. > 
  12465.  
  12466.  
  12467. -
  12468.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12469.  with "unsubscribe usr-tc" in the body of the message.
  12470.  For information on digests or retrieving files and old messages send
  12471.  "help" to the same address.  Do not use quotes in your message.
  12472.  
  12473.  
  12474. -------------------------------------------------------------------------------
  12475.  
  12476. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  12477. Subject: RE: (usr-tc) How to clear ROM on ARC
  12478. Date: 12 Mar 1999 15:51:35 -0600
  12479.  
  12480.  
  12481.  
  12482. |-----Original Message-----
  12483. |From: owner-usr-tc@lists.xmission.com
  12484. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Herr
  12485. |Sent: Friday, March 12, 1999 3:30 PM
  12486. |To: 'usr-tc@lists.xmission.com'
  12487. |Subject: (usr-tc) How to clear ROM on ARC
  12488. |
  12489. |
  12490. |Can anyone tell me how to clear the Flash ROM on a HiperARC.
  12491. |
  12492.  
  12493. Multiple Options below:
  12494.  
  12495. Format Flash:
  12496. Set up a console connection. Reboot the card. During the pause after the ROM
  12497. version number type (case sensative!)
  12498. "AT{ZF}"
  12499.  
  12500. Begin a zmodem upload of HARC software. You will have a completely clean software
  12501. install when the upload completes.
  12502.  
  12503.  
  12504. If you just want to erase the configuration, the command "DELETE CONFIGURATION"
  12505. will do. Unless you forgot the manage user password? Then use the console
  12506. connection and clear the ROM from the boot ROM menu.
  12507.  
  12508. -M
  12509.  
  12510.  
  12511. -
  12512.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12513.  with "unsubscribe usr-tc" in the body of the message.
  12514.  For information on digests or retrieving files and old messages send
  12515.  "help" to the same address.  Do not use quotes in your message.
  12516.  
  12517.  
  12518. -------------------------------------------------------------------------------
  12519.  
  12520. From: Chris <helpchris@rconnect.com>
  12521. Subject: (usr-tc) miuFailed
  12522. Date: 12 Mar 1999 16:08:07 -0600
  12523.  
  12524. I have a PRI hooked into a HiperDSP. Modem code is 1.2.59. 4 of the modems
  12525. had an operational status of miuFailed. I replaced the card with a brand
  12526. new HiperDSP running 1.2.59. The HiperArc on this chassis is running
  12527. 4.1.59-1. 3com told me they had never seen this error message before and
  12528. they said it was probably a bad card. I replaced the card and the message
  12529. came back, but it is on different modems than before. Any ideas?
  12530. Chris Henderson
  12531. Rural Connections ~ Information Services
  12532.  
  12533.  
  12534. -
  12535.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12536.  with "unsubscribe usr-tc" in the body of the message.
  12537.  For information on digests or retrieving files and old messages send
  12538.  "help" to the same address.  Do not use quotes in your message.
  12539.  
  12540.  
  12541. -------------------------------------------------------------------------------
  12542.  
  12543. From: Paul Oster <devious@minot.com>
  12544. Subject: Re: (usr-tc) odd problem
  12545. Date: 12 Mar 1999 16:41:13 -0600 (CST)
  12546.  
  12547.  
  12548.  
  12549.   umm, well, my call with 3com seems to have solved this, they told me not
  12550. to set MTU in radius....  Who do I call to make this into an official bug
  12551. report.  
  12552.  
  12553. Paul M. Oster <devious@minot.com>               http://www.minot.com/
  12554. Magic Internet Services                         (701) 838-1265
  12555. Minots FIRST Internet Connection
  12556.  
  12557. -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  12558.  
  12559. "I might not agree with what you have to say but I will defend, to 
  12560. my death, your right to say it." - Voltaire
  12561.  
  12562. On Fri, 12 Mar 1999, Paul Oster wrote:
  12563.  
  12564. > I've got a similar problem on my side too... ever since we started using
  12565. > ARC's, I've had a HELL of a time with Sportster modems...  they will
  12566. > connect, negotiate fine, get to SOME web site (3 that they have problems
  12567. > with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a
  12568. > WINMODEM, I dont have this problem from home, nor do I have this problem
  12569. > from the office (I'm dialing into the SAME modem pool as my customers from
  12570. > home)  The only difference in the setup is my modem vs theirs... it seems
  12571. > to be centered around the Sportster 56K v.90 modem (X2's that were
  12572. > converted are not affected.)  The problem exists in chassis that have both
  12573. > Quad Modems, and DSP's, however, my remaining chassis with Quads and
  12574. > Netservers are not affected... someone PLEASE toss me a bone, I've been on
  12575. > the phone with 3com support for 42 minutes now, without so much as a clue
  12576. > as to why this is happening, any suggestions?
  12577. > 
  12578. > Paul M. Oster <devious@minot.com>               http://www.minot.com/
  12579. > Magic Internet Services                         (701) 838-1265
  12580. > Minots FIRST Internet Connection
  12581. > 
  12582. > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  12583. > 
  12584. > "I might not agree with what you have to say but I will defend, to 
  12585. > my death, your right to say it." - Voltaire
  12586. > 
  12587. > On Fri, 12 Mar 1999, Scott Boggs wrote:
  12588. > 
  12589. > > We have recently changed our HiperDSPs from channelized T1s
  12590. > > to PRIs.  The local dial up # works fine, an 800 # that directs to the
  12591. > > local # has stopped working.  The connection completes, and a valid
  12592. > > IP is assigned to the PC (verified by winipcfg).  The IP and user name do
  12593. > > not show up
  12594. > > on the TCtrl box (list sess, show users, etc.).  
  12595. > > 
  12596. > > The connection is there, but the client PC cant ping or route anywhere.
  12597. > > It is a plain-jane ISP set up (just PPP)
  12598. > > 
  12599. > > Any ideas?
  12600. > > 
  12601. > > Thanks,
  12602. > > Scott Boggs
  12603. > > IS Manager
  12604. > > United Bank
  12605. > > 
  12606. > > 
  12607. > > 
  12608. > > -
  12609. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12610. > >  with "unsubscribe usr-tc" in the body of the message.
  12611. > >  For information on digests or retrieving files and old messages send
  12612. > >  "help" to the same address.  Do not use quotes in your message.
  12613. > > 
  12614. > 
  12615. > 
  12616. > -
  12617. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12618. >  with "unsubscribe usr-tc" in the body of the message.
  12619. >  For information on digests or retrieving files and old messages send
  12620. >  "help" to the same address.  Do not use quotes in your message.
  12621. > 
  12622.  
  12623.  
  12624. -
  12625.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12626.  with "unsubscribe usr-tc" in the body of the message.
  12627.  For information on digests or retrieving files and old messages send
  12628.  "help" to the same address.  Do not use quotes in your message.
  12629.  
  12630.  
  12631. -------------------------------------------------------------------------------
  12632.  
  12633. From: jeff.binkley@asacomp.com (Jeff Binkley)
  12634. Subject: RE: (usr-tc) V5.0 Securit
  12635. Date: 12 Mar 1999 17:51:00 -0500
  12636.  
  12637.  
  12638.  
  12639.  
  12640.  
  12641. As long as you don't run it as a service you won't be faced with the cpu 
  12642. problem.  I put it in the startup group and it works fine.  Concurrency 
  12643. checking, that's another issue/problem.  I honestly believe it's i the 
  12644. HiPerArc because they had it fixed once but since the accounting record 
  12645. changes that were added around the 4.1 code, it's never worked since.  
  12646. As was mentioned, it will miss stop records and then folks will try to 
  12647. reauthenticate and poof, it thinks they are logged in.  Makes for some 
  12648. nasty tech support phone calls.  It's #1 on my wish list for them to fix 
  12649. (aside from being able to port the backend to an SQL type of server).
  12650.  
  12651. Jeff Binkley
  12652. ASA Network Computing
  12653.  
  12654.  
  12655. u>I would also recommend staying away.  Use Emerald or Cistron or
  12656. u>something else.  3Com claims the 100% cpu thing is a MS bug
  12657. u>(surprised?) and i somewhat believe them because the machine we ran it
  12658. u>on did  not behave like it was stressed.  also i you look at the you
  12659. u>look at  the password in the access database will notice the
  12660. u>"encryption" is nothing more than a constant added to the ASCII value
  12661. u>of the  character in the password.  i may be totally ignorant on this
  12662. u>type  of encryption but it looks like you only need your Cap'n Crunch
  12663. u>decoder ring, the access file, half a brain and your in!  when we
  12664. u>realized this we turned white with fear.  IOW stay away from 3com's SA
  12665. u>server.  we went with emerald a while ago and although there is a bit
  12666. u>of a learning curve it was well worth it.  contact me privately if you
  12667. u>want more reasons to stay away.
  12668.  
  12669. u>blake
  12670.  
  12671.  
  12672. u> 
  12673.  
  12674.  
  12675. u>> -----Original Message-----
  12676. u>> From: Tony Loosle [mailto:tony@tcsourceone.com]
  12677. u>> Sent: Friday, March 12, 1999 12:01 PM
  12678. u>> To: usr-tc@lists.xmission.com
  12679. u>> Subject: Re: (usr-tc) V5.0 Security and Accounting Radius Server
  12680. u>> Software
  12681.  
  12682.  
  12683. u>> stay away from it at ALL costs.  stay far away!!
  12684.  
  12685. u>> they acutally have a version 6.??, but it's full of bugs, 
  12686. u>> use's access, run's your cpu to 100% all the time.  You can't 
  12687. u>> use port restrictions in every other version, it forgets who 
  12688. u>> is logged in, then won't log them out and won't let them back in.
  12689.  
  12690. u>> There is of couse NO support whatsoever from USR!
  12691.  
  12692. u>> tony
  12693.  
  12694.  
  12695. u>> Marlo Montanaro wrote:
  12696.  
  12697. u>> > Does anyone know where I can find detailed information on 
  12698. u>> 3COM V5.0 Security and Accounting Radius Server Software for 
  12699. u>> Windows NT?
  12700. u>> >
  12701. u>> > I've searched the 3COM website and can't seem to locate 
  12702. u>> anything other than the basic "this is what it is" product 
  12703. u>> info.  I would like to find part numbers, detailed specs, 
  12704. u>> pricing info, etc. and there are no links to more detailed 
  12705. u>> information.
  12706. u>> >
  12707. u>> > Also, I would like comments from anyone using this 
  12708. u>> software- how easy is it to install and configure, etc.?
  12709. u>> >
  12710. u>> > Thanks!
  12711.  
  12712. u>> > Regards...
  12713. u>> > Marlo Montanaro
  12714.  
  12715. u>> > -
  12716. u>> >  To unsubscribe to usr-tc, send an email to
  12717. u>> >  "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of
  12718. u>> >  the message. For information on digests or retrieving files and
  12719. u>> old  messages send
  12720. u>> >  "help" to the same address.  Do not use quotes in your message.
  12721.  
  12722.  
  12723. u>> -
  12724. u>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12725. u>>  with "unsubscribe usr-tc" in the body of the message.
  12726. u>>  For information on digests or retrieving files and old messages
  12727. u>>  send "help" to the same address.  Do not use quotes in your
  12728. u>> message. 
  12729.  
  12730.  
  12731. u>-
  12732. u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12733. u> with "unsubscribe usr-tc" in the body of the message.
  12734. u> For information on digests or retrieving files and old messages send
  12735. u> "help" to the same address.  Do not use quotes in your message.
  12736.  
  12737. CMPQwk 1.42-21 9999
  12738.  
  12739.  
  12740. -
  12741.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12742.  with "unsubscribe usr-tc" in the body of the message.
  12743.  For information on digests or retrieving files and old messages send
  12744.  "help" to the same address.  Do not use quotes in your message.
  12745.  
  12746.  
  12747. -------------------------------------------------------------------------------
  12748.  
  12749. From: <vanhalen@coredcs.com>
  12750. Subject: Re: (usr-tc) odd problem
  12751. Date: 12 Mar 1999 19:48:48 -0600 (CST)
  12752.  
  12753. What version of the codes are you running on the ARC, DSP's and Quads?
  12754.  
  12755. Also can anyone else confirm that we're _not_ supposed to be shooting the
  12756. MTU value in radius?
  12757.  
  12758. Steve
  12759.  
  12760. On Fri, 12 Mar 1999, Paul Oster wrote:
  12761.  
  12762. > 
  12763. > 
  12764. >   umm, well, my call with 3com seems to have solved this, they told me not
  12765. > to set MTU in radius....  Who do I call to make this into an official bug
  12766. > report.  
  12767. > 
  12768. > Paul M. Oster <devious@minot.com>               http://www.minot.com/
  12769. > Magic Internet Services                         (701) 838-1265
  12770. > Minots FIRST Internet Connection
  12771. > 
  12772. > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  12773. > 
  12774. > "I might not agree with what you have to say but I will defend, to 
  12775. > my death, your right to say it." - Voltaire
  12776. > 
  12777. > On Fri, 12 Mar 1999, Paul Oster wrote:
  12778. > 
  12779. > > I've got a similar problem on my side too... ever since we started using
  12780. > > ARC's, I've had a HELL of a time with Sportster modems...  they will
  12781. > > connect, negotiate fine, get to SOME web site (3 that they have problems
  12782. > > with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a
  12783. > > WINMODEM, I dont have this problem from home, nor do I have this problem
  12784. > > from the office (I'm dialing into the SAME modem pool as my customers from
  12785. > > home)  The only difference in the setup is my modem vs theirs... it seems
  12786. > > to be centered around the Sportster 56K v.90 modem (X2's that were
  12787. > > converted are not affected.)  The problem exists in chassis that have both
  12788. > > Quad Modems, and DSP's, however, my remaining chassis with Quads and
  12789. > > Netservers are not affected... someone PLEASE toss me a bone, I've been on
  12790. > > the phone with 3com support for 42 minutes now, without so much as a clue
  12791. > > as to why this is happening, any suggestions?
  12792. > > 
  12793. > > Paul M. Oster <devious@minot.com>               http://www.minot.com/
  12794. > > Magic Internet Services                         (701) 838-1265
  12795. > > Minots FIRST Internet Connection
  12796. > > 
  12797. > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  12798. > > 
  12799. > > "I might not agree with what you have to say but I will defend, to 
  12800. > > my death, your right to say it." - Voltaire
  12801. > > 
  12802. > > On Fri, 12 Mar 1999, Scott Boggs wrote:
  12803. > > 
  12804. > > > We have recently changed our HiperDSPs from channelized T1s
  12805. > > > to PRIs.  The local dial up # works fine, an 800 # that directs to the
  12806. > > > local # has stopped working.  The connection completes, and a valid
  12807. > > > IP is assigned to the PC (verified by winipcfg).  The IP and user name do
  12808. > > > not show up
  12809. > > > on the TCtrl box (list sess, show users, etc.).  
  12810. > > > 
  12811. > > > The connection is there, but the client PC cant ping or route anywhere.
  12812. > > > It is a plain-jane ISP set up (just PPP)
  12813. > > > 
  12814. > > > Any ideas?
  12815. > > > 
  12816. > > > Thanks,
  12817. > > > Scott Boggs
  12818. > > > IS Manager
  12819. > > > United Bank
  12820. > > > 
  12821. > > > 
  12822. > > > 
  12823. > > > -
  12824. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12825. > > >  with "unsubscribe usr-tc" in the body of the message.
  12826. > > >  For information on digests or retrieving files and old messages send
  12827. > > >  "help" to the same address.  Do not use quotes in your message.
  12828. > > > 
  12829. > > 
  12830. > > 
  12831. > > -
  12832. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12833. > >  with "unsubscribe usr-tc" in the body of the message.
  12834. > >  For information on digests or retrieving files and old messages send
  12835. > >  "help" to the same address.  Do not use quotes in your message.
  12836. > > 
  12837. > 
  12838. > 
  12839. > -
  12840. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12841. >  with "unsubscribe usr-tc" in the body of the message.
  12842. >  For information on digests or retrieving files and old messages send
  12843. >  "help" to the same address.  Do not use quotes in your message.
  12844. > 
  12845.  
  12846.  
  12847. -
  12848.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12849.  with "unsubscribe usr-tc" in the body of the message.
  12850.  For information on digests or retrieving files and old messages send
  12851.  "help" to the same address.  Do not use quotes in your message.
  12852.  
  12853.  
  12854. -------------------------------------------------------------------------------
  12855.  
  12856. From: Paul Oster <devious@minot.com>
  12857. Subject: Re: (usr-tc) odd problem
  12858. Date: 12 Mar 1999 20:38:31 -0600 (CST)
  12859.  
  12860.  
  12861. ARCs are 4.1.59-6, DSP's are 1.2.59, Netservers are 3.8.1, NMC's are
  12862. either 5.4.95 or 5.5.5 (depending on 4M or 16M version)... Quads are
  12863. mostly 5.10.9 or 5.x.9 (whatever the double sided cards are, I've only got
  12864. a vew of them)  in other words, completely up to date... I'll let everyone
  12865. know if my complaints are eliminated by this change...
  12866.  
  12867. NOTE, NetServer cards are/were unaffected by this problem.  Time for yet
  12868. another maintenance release?
  12869.  
  12870. Paul M. Oster <devious@minot.com>               http://www.minot.com/
  12871. Magic Internet Services                         (701) 838-1265
  12872. Minots FIRST Internet Connection
  12873.  
  12874. -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  12875.  
  12876. "I might not agree with what you have to say but I will defend, to 
  12877. my death, your right to say it." - Voltaire
  12878.  
  12879. On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote:
  12880.  
  12881. > What version of the codes are you running on the ARC, DSP's and Quads?
  12882. > 
  12883. > Also can anyone else confirm that we're _not_ supposed to be shooting the
  12884. > MTU value in radius?
  12885. > 
  12886. > Steve
  12887. > 
  12888. > On Fri, 12 Mar 1999, Paul Oster wrote:
  12889. > 
  12890. > > 
  12891. > > 
  12892. > >   umm, well, my call with 3com seems to have solved this, they told me not
  12893. > > to set MTU in radius....  Who do I call to make this into an official bug
  12894. > > report.  
  12895. > > 
  12896. > > Paul M. Oster <devious@minot.com>               http://www.minot.com/
  12897. > > Magic Internet Services                         (701) 838-1265
  12898. > > Minots FIRST Internet Connection
  12899. > > 
  12900. > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  12901. > > 
  12902. > > "I might not agree with what you have to say but I will defend, to 
  12903. > > my death, your right to say it." - Voltaire
  12904. > > 
  12905. > > On Fri, 12 Mar 1999, Paul Oster wrote:
  12906. > > 
  12907. > > > I've got a similar problem on my side too... ever since we started using
  12908. > > > ARC's, I've had a HELL of a time with Sportster modems...  they will
  12909. > > > connect, negotiate fine, get to SOME web site (3 that they have problems
  12910. > > > with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a
  12911. > > > WINMODEM, I dont have this problem from home, nor do I have this problem
  12912. > > > from the office (I'm dialing into the SAME modem pool as my customers from
  12913. > > > home)  The only difference in the setup is my modem vs theirs... it seems
  12914. > > > to be centered around the Sportster 56K v.90 modem (X2's that were
  12915. > > > converted are not affected.)  The problem exists in chassis that have both
  12916. > > > Quad Modems, and DSP's, however, my remaining chassis with Quads and
  12917. > > > Netservers are not affected... someone PLEASE toss me a bone, I've been on
  12918. > > > the phone with 3com support for 42 minutes now, without so much as a clue
  12919. > > > as to why this is happening, any suggestions?
  12920. > > > 
  12921. > > > Paul M. Oster <devious@minot.com>               http://www.minot.com/
  12922. > > > Magic Internet Services                         (701) 838-1265
  12923. > > > Minots FIRST Internet Connection
  12924. > > > 
  12925. > > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  12926. > > > 
  12927. > > > "I might not agree with what you have to say but I will defend, to 
  12928. > > > my death, your right to say it." - Voltaire
  12929. > > > 
  12930. > > > On Fri, 12 Mar 1999, Scott Boggs wrote:
  12931. > > > 
  12932. > > > > We have recently changed our HiperDSPs from channelized T1s
  12933. > > > > to PRIs.  The local dial up # works fine, an 800 # that directs to the
  12934. > > > > local # has stopped working.  The connection completes, and a valid
  12935. > > > > IP is assigned to the PC (verified by winipcfg).  The IP and user name do
  12936. > > > > not show up
  12937. > > > > on the TCtrl box (list sess, show users, etc.).  
  12938. > > > > 
  12939. > > > > The connection is there, but the client PC cant ping or route anywhere.
  12940. > > > > It is a plain-jane ISP set up (just PPP)
  12941. > > > > 
  12942. > > > > Any ideas?
  12943. > > > > 
  12944. > > > > Thanks,
  12945. > > > > Scott Boggs
  12946. > > > > IS Manager
  12947. > > > > United Bank
  12948. > > > > 
  12949. > > > > 
  12950. > > > > 
  12951. > > > > -
  12952. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12953. > > > >  with "unsubscribe usr-tc" in the body of the message.
  12954. > > > >  For information on digests or retrieving files and old messages send
  12955. > > > >  "help" to the same address.  Do not use quotes in your message.
  12956. > > > > 
  12957. > > > 
  12958. > > > 
  12959. > > > -
  12960. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12961. > > >  with "unsubscribe usr-tc" in the body of the message.
  12962. > > >  For information on digests or retrieving files and old messages send
  12963. > > >  "help" to the same address.  Do not use quotes in your message.
  12964. > > > 
  12965. > > 
  12966. > > 
  12967. > > -
  12968. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12969. > >  with "unsubscribe usr-tc" in the body of the message.
  12970. > >  For information on digests or retrieving files and old messages send
  12971. > >  "help" to the same address.  Do not use quotes in your message.
  12972. > > 
  12973. > 
  12974. > 
  12975. > -
  12976. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12977. >  with "unsubscribe usr-tc" in the body of the message.
  12978. >  For information on digests or retrieving files and old messages send
  12979. >  "help" to the same address.  Do not use quotes in your message.
  12980. > 
  12981.  
  12982.  
  12983. -
  12984.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  12985.  with "unsubscribe usr-tc" in the body of the message.
  12986.  For information on digests or retrieving files and old messages send
  12987.  "help" to the same address.  Do not use quotes in your message.
  12988.  
  12989.  
  12990. -------------------------------------------------------------------------------
  12991.  
  12992. From: Sean Herr <Sean@YNC.NET>
  12993. Subject: RE: (usr-tc) How to clear ROM on ARC
  12994. Date: 12 Mar 1999 20:41:54 -0600
  12995.  
  12996. Yes. I was an ass and forgot the password.
  12997.  
  12998. Sean Herr
  12999. @YourNET Connection, Inc.
  13000. 847-524-3910
  13001. http://www.ync.net
  13002.  
  13003.  
  13004. -----Original Message-----
  13005. Sent: Friday, March 12, 1999 3:52 PM
  13006.  
  13007.  
  13008.  
  13009.  
  13010. |-----Original Message-----
  13011. |From: owner-usr-tc@lists.xmission.com
  13012. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Herr
  13013. |Sent: Friday, March 12, 1999 3:30 PM
  13014. |To: 'usr-tc@lists.xmission.com'
  13015. |Subject: (usr-tc) How to clear ROM on ARC
  13016. |
  13017. |
  13018. |Can anyone tell me how to clear the Flash ROM on a HiperARC.
  13019. |
  13020.  
  13021. Multiple Options below:
  13022.  
  13023. Format Flash:
  13024. Set up a console connection. Reboot the card. During the pause after the ROM
  13025. version number type (case sensative!)
  13026. "AT{ZF}"
  13027.  
  13028. Begin a zmodem upload of HARC software. You will have a completely clean
  13029. software
  13030. install when the upload completes.
  13031.  
  13032.  
  13033. If you just want to erase the configuration, the command "DELETE
  13034. CONFIGURATION"
  13035. will do. Unless you forgot the manage user password? Then use the console
  13036. connection and clear the ROM from the boot ROM menu.
  13037.  
  13038. -M
  13039.  
  13040.  
  13041. -
  13042.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13043.  with "unsubscribe usr-tc" in the body of the message.
  13044.  For information on digests or retrieving files and old messages send
  13045.  "help" to the same address.  Do not use quotes in your message.
  13046.  
  13047. -
  13048.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13049.  with "unsubscribe usr-tc" in the body of the message.
  13050.  For information on digests or retrieving files and old messages send
  13051.  "help" to the same address.  Do not use quotes in your message.
  13052.  
  13053.  
  13054. -------------------------------------------------------------------------------
  13055.  
  13056. From: Jeff Mcadams <jeffm@iglou.com>
  13057. Subject: Re: (usr-tc) odd problem
  13058. Date: 12 Mar 1999 22:53:54 -0500 (EST)
  13059.  
  13060. Thus spake Paul Oster
  13061. >  umm, well, my call with 3com seems to have solved this, they told me not
  13062. >to set MTU in radius....  Who do I call to make this into an official bug
  13063. >report.  
  13064.  
  13065. The PPP IETF working group?  Actually...that's not necessarily true.
  13066.  
  13067. Background...
  13068.  
  13069. During PPP negotiation, LCP is negotiated first, MTU is a part of LCP.
  13070. *Then* PAP, CHAP, EAP, which authentication protocol you use is
  13071. "negotiated", meaning that the MTU in RADIUS isn't received by the
  13072. RADIUS until *after* the MTU was already negotiated in LCP.
  13073.  
  13074. The question then becomes...where really is the bug.  When the Arc gets
  13075. the RADIUS response, it could, in theory at least, lower its own MTU
  13076. without any problems (the other side already said it would accept
  13077. packets up to size x, if you only send packets up to size x-y, that's
  13078. not going to screw up the other side).  If it needs to lower the MRU (or
  13079. conceivably MRRU), then it would need to restart LCP, which is
  13080. problematic at best as I doubt there are all that many PPP
  13081. implementations out there that will handle having LCP restarted.
  13082.  
  13083. Obviously, there are all sorts of other permutations of what can be
  13084. going on in here, but hopefully this gives you a direction to start from
  13085. to help understand what issues are involved.  :)
  13086. -- 
  13087. Jeff McAdams                            Email: jeffm@iglou.com
  13088. Head Network Administrator              Voice: (502) 966-3848
  13089. IgLou Internet Services                        (800) 436-4456
  13090.  
  13091. -
  13092.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13093.  with "unsubscribe usr-tc" in the body of the message.
  13094.  For information on digests or retrieving files and old messages send
  13095.  "help" to the same address.  Do not use quotes in your message.
  13096.  
  13097.  
  13098. -------------------------------------------------------------------------------
  13099.  
  13100. From: Jeff Mcadams <jeffm@iglou.com>
  13101. Subject: Re: (usr-tc) odd problem
  13102. Date: 12 Mar 1999 22:56:06 -0500 (EST)
  13103.  
  13104. Thus spake vanhalen@coredcs.com
  13105. >Also can anyone else confirm that we're _not_ supposed to be shooting the
  13106. >MTU value in radius?
  13107.  
  13108. Other than, for the most part its not really going to do you much good?
  13109. Since the MTU is already negotiated in LCP before the RADIUS response is
  13110. received in PAP, most systems will just drop the MTU setting on the
  13111. floor.  See my other message for how it *might* be useful to use this
  13112. value, even in this situation (and I'm sure other RADIUS guru's like MZ
  13113. and David Bolen can correct me if I've misstated something).
  13114. -- 
  13115. Jeff McAdams                            Email: jeffm@iglou.com
  13116. Head Network Administrator              Voice: (502) 966-3848
  13117. IgLou Internet Services                        (800) 436-4456
  13118.  
  13119. -
  13120.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13121.  with "unsubscribe usr-tc" in the body of the message.
  13122.  For information on digests or retrieving files and old messages send
  13123.  "help" to the same address.  Do not use quotes in your message.
  13124.  
  13125.  
  13126. -------------------------------------------------------------------------------
  13127.  
  13128. From: mark@vielle.datasys.net (Mark R. Lindsey)
  13129. Subject: (usr-tc) Dual PRI: DS0-to-modem inconsistency
  13130. Date: 12 Mar 1999 23:19:42 -0500
  13131.  
  13132. Howdy.
  13133.  
  13134. We're having trouble getting a couple of dual-PRI cards working. We've
  13135. followed the directions given in the docs, and referred to in the archives,
  13136. but with no luck. I'm going to paste some table output here that
  13137. might lend some clues.
  13138.  
  13139. Our problem is this: the dual PRI won't take any calls. My theory is
  13140. that because it's not showing a mapping of DS0s to modems, it doesn't
  13141. think there are any modems available for the incoming calls. However: in
  13142. some other displayable tables, the PRI card itself is saying that both
  13143. the modems and the ISDN gateway (a Netserver, in this case) are
  13144. available.  
  13145.  
  13146. It bothers me that, on one hand, we have a good DS0-to-modem mapping,
  13147. but it's not showing up in the DS0 status table.
  13148.  
  13149. Have a look, and please help us figure out how to slay this beast.
  13150. I'll appreciate any help.
  13151.  
  13152.  
  13153. ---
  13154. Mark R. Lindsey, mark@datasys.net
  13155. Internet Engineering, DSS Online
  13156. Voice: 912.241.0607, Fax: 912.241.0190 (US)
  13157.  
  13158.  
  13159.  
  13160.  
  13161.  
  13162.  
  13163.  
  13164.  
  13165.  Copyright (c) 3Com Corporation, 1995-1997
  13166.  
  13167.  Dual T1 PRI Application Card Revision   3.0.2     (Card Id: 27)
  13168.  Boot Code Linked Date     : Mon Dec 04 17:41:48 1995
  13169.  Operation Code Linked Date: Fri Sep 05 12:11:37 1997
  13170.  
  13171.  
  13172.  
  13173.  
  13174.  Chassis Slot Device  Configuration  Status
  13175.  
  13176.  Current Configuration Status
  13177.          Device             Device
  13178.  Slot#    Type      Slot#    Type
  13179.    1     Dual-PRI     9     Qbch-I_mdm
  13180.    2     NONE        10     Qbch-I_mdm
  13181.    3     Qbch-I_mdm  11     Qbch-I_mdm
  13182.    4     Qbch-I_mdm  12     Qbch-I_mdm
  13183.    5     Qbch-I_mdm  13     Qbch-I_mdm
  13184.    6     Qbch-I_mdm  14     Qbch-I_mdm
  13185.    7     Qbch-I_mdm  15     NONE
  13186.    8     Qbch-I_mdm  16     ISDN-GW
  13187.  Assign device types to chassis slot numbers given the format below:
  13188.        DEVICE_TYPE#:S#[,S#,S#-S#]
  13189.  Where,
  13190.    DEVICE_TYPE# -> q - QBCH-MDM,g - ISDN-GW,n - NONE (no ISDN Device in Slot)
  13191.                    i - QBCH-I_MDM,S# -> Chassis Slot# (1-16)
  13192.  Example: q:4,5 assigns the QBCH-MDM NAC device type to slots 4 and 5.
  13193.  >:
  13194.  
  13195.  
  13196.  
  13197.  
  13198.  
  13199.  
  13200.     Card Configuration                        Current Setting
  13201.  
  13202.  1 Save current Configuration to NVRAM
  13203.  2 Restore NVRAM Configuration
  13204.  3 Restore Default Configuration
  13205.  4 Timing Source Priority Assignment           Span-1=1 Span-2=2
  13206.  5 Chassis Slot Device Configuration
  13207.  6 Modem Routing Method                        Fixed Assignment
  13208.  7 Configure Local Console Password
  13209.  8 Change DS0 state on Quad Modem NAC action   Disabled
  13210.  9 Companding Code Configuration               U-Law
  13211.  
  13212.  
  13213.  
  13214.  
  13215.  
  13216.  
  13217.  
  13218.  
  13219.  Inbound Call Routing Configuration
  13220.                                    Current
  13221.  1 Default ISDN-GW Slot:             16
  13222.  2 Allow Analog Modem Calls:       Enabled
  13223.  3 Inbound Phone Number Routing Configuration
  13224.  4 Inbound Phone Number Routing Configuration Status (Entries 1-24)
  13225.  5 Inbound Phone Number Routing Configuration Status (Entries 25-48)
  13226.  6 Reserved Pool to Inbound Phone Number Assignment
  13227.  7 Modem /I-Modem to Reserved Pool Assignment
  13228.  8 ISDN-GWC to Reserved Pool Assignment
  13229.  
  13230.  
  13231.  
  13232.  
  13233.     Span Line 1 Configuration            Current Setting
  13234.  
  13235.  1  Framing Mode                             ESF
  13236.  2  Line Coding                              B8ZS
  13237.  3  Remotely Initiated Loopback              Ignore
  13238.  4  Jitter Attenuation                       Transmitter
  13239.  5  Transmit Line Build Out                  0.0 dB
  13240.  6  Switch Type (Boot time)              Config=DMS-100(NT)Act.=DMS-100(NT)
  13241.  7  Idle Byte Sent to TELCO                  FE Hex
  13242.  8  DS0 to Modem Slot/Chan Mapping
  13243.  9  Signaling Channel Config (Boot time)     Config=D-channel Act.=D-channel
  13244.  10 Interface ID                             0
  13245.  11 Span Level Call Type Blocking            No Call Blocked
  13246.  12 Span Level Cause Codes
  13247.  13 DS0 Level Call Type Blocking
  13248.  14 DS0 Level Service State
  13249.  15 Short Haul NIC Line Length               Not Applicable
  13250.  16 Use ALERTING Response                    NO
  13251.  
  13252.  
  13253.  
  13254.  
  13255.  
  13256.  
  13257.  
  13258.  
  13259.  Span Line 1 DS0 Status
  13260.  
  13261.  DS0 DS0            Device       Slot/   DS0 DS0           Device       Slot/
  13262.      Status         Type         Chan        Status        Type         Chan
  13263.  
  13264.   1  IDLE           NONE          -/-    13  OOS            NONE          -/-
  13265.   2  IDLE           NONE          -/-    14  OOS            NONE          -/-
  13266.   3  IDLE           NONE          -/-    15  OOS            NONE          -/-
  13267.   4  IDLE           NONE          -/-    16  OOS            NONE          -/-
  13268.   5  IDLE           NONE          -/-    17  OOS            NONE          -/-
  13269.   6  IDLE           NONE          -/-    18  OOS            NONE          -/-
  13270.   7  IDLE           NONE          -/-    19  OOS            NONE          -/-
  13271.   8  IDLE           NONE          -/-    20  OOS            NONE          -/-
  13272.   9  IDLE           NONE          -/-    21  OOS            NONE          -/-
  13273.  10  IDLE           NONE          -/-    22  OOS            NONE          -/-
  13274.  11  OOS            NONE          -/-    23  OOS            NONE          -/-
  13275.  12  OOS            NONE          -/-    24  D-CHANNEL      NONE          -/-
  13276.  
  13277.  Press Return to Update status or press ESC to exit
  13278.  
  13279.  
  13280.  
  13281.  
  13282.  
  13283.  
  13284.  
  13285.  
  13286.  
  13287.  Span Line 2 DS0 Status
  13288.  
  13289.  DS0 DS0            Device       Slot/   DS0 DS0           Device       Slot/
  13290.      Status         Type         Chan        Status        Type         Chan
  13291.  
  13292.   1  IDLE           NONE          -/-    13  OOS            NONE          -/-
  13293.   2  IDLE           NONE          -/-    14  OOS            NONE          -/-
  13294.   3  IDLE           NONE          -/-    15  OOS            NONE          -/-
  13295.   4  IDLE           NONE          -/-    16  OOS            NONE          -/-
  13296.   5  IDLE           NONE          -/-    17  OOS            NONE          -/-
  13297.   6  IDLE           NONE          -/-    18  OOS            NONE          -/-
  13298.   7  IDLE           NONE          -/-    19  OOS            NONE          -/-
  13299.   8  IDLE           NONE          -/-    20  OOS            NONE          -/-
  13300.   9  IDLE           NONE          -/-    21  OOS            NONE          -/-
  13301.  10  IDLE           NONE          -/-    22  OOS            NONE          -/-
  13302.  11  OOS            NONE          -/-    23  OOS            NONE          -/-
  13303.  12  OOS            NONE          -/-    24  D-CHANNEL      NONE          -/-
  13304.  
  13305.  Press Return to Update status or press ESC to exit
  13306.  
  13307.  
  13308.  
  13309.  
  13310.  
  13311.  
  13312.  
  13313.  
  13314.  Card Status
  13315.  
  13316.  Current PRI Timing Source:  Span Line 1.
  13317.  Current PBus Timing Source: Slave.
  13318.  NIC Type:                   Dual T1 v2
  13319.  PRI Chassis Slot Number:    01
  13320.  NAC Uptime (days::hh:mm:ss):  0::5:23:34
  13321.  DRAM Installed:             4 M
  13322.  FLASH ROM Installed:        1 M
  13323.  
  13324.  Press Esc to exit.
  13325.  
  13326.  
  13327.  
  13328.  
  13329.  
  13330.  
  13331.  
  13332.  Chassis Slot Device Configuration Status
  13333.  
  13334.        Device
  13335.  Slot# Type
  13336.  
  13337.   1    Dual-PRI
  13338.   2    NONE
  13339.   3    Qbch-I_mdm
  13340.   4    Qbch-I_mdm
  13341.   5    Qbch-I_mdm
  13342.   6    Qbch-I_mdm
  13343.   7    Qbch-I_mdm
  13344.   8    Qbch-I_mdm
  13345.   9    Qbch-I_mdm
  13346.  10    Qbch-I_mdm
  13347.  11    Qbch-I_mdm
  13348.  12    Qbch-I_mdm
  13349.  13    Qbch-I_mdm
  13350.  14    Qbch-I_mdm
  13351.  15    NONE
  13352.  16    ISDN-GW
  13353.  
  13354.  Press Return to update status or press Esc to exit.
  13355.  
  13356.  
  13357.  
  13358.  
  13359.  
  13360.  
  13361.  
  13362.  Span Line 1 DS0 to Modem Slot/Chan Mapping
  13363.  
  13364.  DS0        Slot/Chan                   DS0        Slot/Chan
  13365.  
  13366.   1            3/1                      13            6/1
  13367.   2            3/2                      14            6/2
  13368.   3            3/3                      15            6/3
  13369.   4            3/4                      16            6/4
  13370.   5            4/1                      17            7/1
  13371.   6            4/2                      18            7/2
  13372.   7            4/3                      19            7/3
  13373.   8            4/4                      20            7/4
  13374.   9            5/1                      21            8/1
  13375.  10            5/2                      22            8/2
  13376.  11            5/3                      23            8/3
  13377.  12            5/4                      24       Unmapped -in use
  13378.  
  13379.  Example: 2:14/1 maps DS0 2 to slot 14, channel 1
  13380.  (ds0:slot/chan,):
  13381.  
  13382.  
  13383.  
  13384. -
  13385.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13386.  with "unsubscribe usr-tc" in the body of the message.
  13387.  For information on digests or retrieving files and old messages send
  13388.  "help" to the same address.  Do not use quotes in your message.
  13389.  
  13390.  
  13391. -------------------------------------------------------------------------------
  13392.  
  13393. From: Jeff Mcadams <jeffm@iglou.com>
  13394. Subject: Re: (usr-tc) Dual PRI: DS0-to-modem inconsistency
  13395. Date: 13 Mar 1999 09:09:04 -0500 (EST)
  13396.  
  13397. Thus spake Mark R. Lindsey
  13398. >Our problem is this: the dual PRI won't take any calls. My theory is
  13399. >that because it's not showing a mapping of DS0s to modems, it doesn't
  13400. >think there are any modems available for the incoming calls. However: in
  13401. >some other displayable tables, the PRI card itself is saying that both
  13402. >the modems and the ISDN gateway (a Netserver, in this case) are
  13403. >available.  
  13404.  
  13405. Not that it should affect it, but change your ISDN GW to 0, let the
  13406. quads handle it...you'll be much better off with it.
  13407.  
  13408. The other thing to check is on the modems, make sure they are set to
  13409. line src of pritdm and not t1tdm.
  13410. -- 
  13411. Jeff McAdams                            Email: jeffm@iglou.com
  13412. Head Network Administrator              Voice: (502) 966-3848
  13413. IgLou Internet Services                        (800) 436-4456
  13414.  
  13415. -
  13416.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13417.  with "unsubscribe usr-tc" in the body of the message.
  13418.  For information on digests or retrieving files and old messages send
  13419.  "help" to the same address.  Do not use quotes in your message.
  13420.  
  13421.  
  13422. -------------------------------------------------------------------------------
  13423.  
  13424. From: mark@vielle.datasys.net (Mark R. Lindsey)
  13425. Subject: Re: (usr-tc) Dual PRI: DS0-to-modem inconsistency
  13426. Date: 13 Mar 1999 10:49:42 -0500
  13427.  
  13428. : >Our problem is this: the dual PRI won't take any calls. My theory is
  13429. : >that because it's not showing a mapping of DS0s to modems, it doesn't
  13430. : >think there are any modems available for the incoming calls. However: in
  13431. : >some other displayable tables, the PRI card itself is saying that both
  13432. : >the modems and the ISDN gateway (a Netserver, in this case) are
  13433. : >available.  
  13434. : 
  13435. : Not that it should affect it, but change your ISDN GW to 0, let the
  13436. : quads handle it...you'll be much better off with it.
  13437.  
  13438. I thought the ISDN GW was supposed to be the Netserver or HARC.  I guess not.
  13439.  
  13440.  
  13441. : The other thing to check is on the modems, make sure they are set to
  13442. : line src of pritdm and not t1tdm.
  13443.  
  13444. Right. Thanks.
  13445.  
  13446.  
  13447. -
  13448.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13449.  with "unsubscribe usr-tc" in the body of the message.
  13450.  For information on digests or retrieving files and old messages send
  13451.  "help" to the same address.  Do not use quotes in your message.
  13452.  
  13453.  
  13454. -------------------------------------------------------------------------------
  13455.  
  13456. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  13457. Subject: Re: (usr-tc) odd problem
  13458. Date: 13 Mar 1999 10:16:16 -0600 (CST)
  13459.  
  13460. On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote:
  13461.  
  13462. > What version of the codes are you running on the ARC, DSP's and Quads?
  13463. > 
  13464. > Also can anyone else confirm that we're _not_ supposed to be shooting the
  13465. > MTU value in radius?
  13466. > 
  13467.  
  13468. This has nothing to do with HiPer arc code or DSP or Quad code.  For all 
  13469. HiPer arcs you either set the MTU to 1500 or do not set any value.  
  13470. Setting the MTU to a lower value other than 1500 will cause users unable 
  13471. to browse certain websites.
  13472.  
  13473. krish
  13474.  
  13475. > Steve
  13476. > 
  13477. > On Fri, 12 Mar 1999, Paul Oster wrote:
  13478. > 
  13479. > > 
  13480. > > 
  13481. > >   umm, well, my call with 3com seems to have solved this, they told me not
  13482. > > to set MTU in radius....  Who do I call to make this into an official bug
  13483. > > report.  
  13484. > > 
  13485. > > Paul M. Oster <devious@minot.com>               http://www.minot.com/
  13486. > > Magic Internet Services                         (701) 838-1265
  13487. > > Minots FIRST Internet Connection
  13488. > > 
  13489. > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  13490. > > 
  13491. > > "I might not agree with what you have to say but I will defend, to 
  13492. > > my death, your right to say it." - Voltaire
  13493. > > 
  13494. > > On Fri, 12 Mar 1999, Paul Oster wrote:
  13495. > > 
  13496. > > > I've got a similar problem on my side too... ever since we started using
  13497. > > > ARC's, I've had a HELL of a time with Sportster modems...  they will
  13498. > > > connect, negotiate fine, get to SOME web site (3 that they have problems
  13499. > > > with, www.espn.com www.abn.com and www.hotmail.com) ... now, with a
  13500. > > > WINMODEM, I dont have this problem from home, nor do I have this problem
  13501. > > > from the office (I'm dialing into the SAME modem pool as my customers from
  13502. > > > home)  The only difference in the setup is my modem vs theirs... it seems
  13503. > > > to be centered around the Sportster 56K v.90 modem (X2's that were
  13504. > > > converted are not affected.)  The problem exists in chassis that have both
  13505. > > > Quad Modems, and DSP's, however, my remaining chassis with Quads and
  13506. > > > Netservers are not affected... someone PLEASE toss me a bone, I've been on
  13507. > > > the phone with 3com support for 42 minutes now, without so much as a clue
  13508. > > > as to why this is happening, any suggestions?
  13509. > > > 
  13510. > > > Paul M. Oster <devious@minot.com>               http://www.minot.com/
  13511. > > > Magic Internet Services                         (701) 838-1265
  13512. > > > Minots FIRST Internet Connection
  13513. > > > 
  13514. > > > -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  13515. > > > 
  13516. > > > "I might not agree with what you have to say but I will defend, to 
  13517. > > > my death, your right to say it." - Voltaire
  13518. > > > 
  13519. > > > On Fri, 12 Mar 1999, Scott Boggs wrote:
  13520. > > > 
  13521. > > > > We have recently changed our HiperDSPs from channelized T1s
  13522. > > > > to PRIs.  The local dial up # works fine, an 800 # that directs to the
  13523. > > > > local # has stopped working.  The connection completes, and a valid
  13524. > > > > IP is assigned to the PC (verified by winipcfg).  The IP and user name do
  13525. > > > > not show up
  13526. > > > > on the TCtrl box (list sess, show users, etc.).  
  13527. > > > > 
  13528. > > > > The connection is there, but the client PC cant ping or route anywhere.
  13529. > > > > It is a plain-jane ISP set up (just PPP)
  13530. > > > > 
  13531. > > > > Any ideas?
  13532. > > > > 
  13533. > > > > Thanks,
  13534. > > > > Scott Boggs
  13535. > > > > IS Manager
  13536. > > > > United Bank
  13537. > > > > 
  13538. > > > > 
  13539. > > > > 
  13540. > > > > -
  13541. > > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13542. > > > >  with "unsubscribe usr-tc" in the body of the message.
  13543. > > > >  For information on digests or retrieving files and old messages send
  13544. > > > >  "help" to the same address.  Do not use quotes in your message.
  13545. > > > > 
  13546. > > > 
  13547. > > > 
  13548. > > > -
  13549. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13550. > > >  with "unsubscribe usr-tc" in the body of the message.
  13551. > > >  For information on digests or retrieving files and old messages send
  13552. > > >  "help" to the same address.  Do not use quotes in your message.
  13553. > > > 
  13554. > > 
  13555. > > 
  13556. > > -
  13557. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13558. > >  with "unsubscribe usr-tc" in the body of the message.
  13559. > >  For information on digests or retrieving files and old messages send
  13560. > >  "help" to the same address.  Do not use quotes in your message.
  13561. > > 
  13562. > 
  13563. > 
  13564. > -
  13565. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13566. >  with "unsubscribe usr-tc" in the body of the message.
  13567. >  For information on digests or retrieving files and old messages send
  13568. >  "help" to the same address.  Do not use quotes in your message.
  13569. > 
  13570.  
  13571. -
  13572.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13573.  with "unsubscribe usr-tc" in the body of the message.
  13574.  For information on digests or retrieving files and old messages send
  13575.  "help" to the same address.  Do not use quotes in your message.
  13576.  
  13577.  
  13578. -------------------------------------------------------------------------------
  13579.  
  13580. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  13581. Subject: RE: (usr-tc) How to clear ROM on ARC
  13582. Date: 13 Mar 1999 10:21:33 -0600 (CST)
  13583.  
  13584. If you have forgot your password and if radius is already configured for 
  13585. the hiper arc, then you can add a login user of type adminstrator and 
  13586. logon to the hiper arc.
  13587.  
  13588. krish
  13589.  
  13590.         \    T.S.V. Krishnan  \
  13591.          \      Network System Engineer \ ( : - : )
  13592.           \     3Com ............   \
  13593.         ----------------------------------------------/
  13594. tkrishna@bubba.ae.usr.com  
  13595. ----------------------------/ http://interproc.ae.usr.com ----/
  13596. The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html
  13597.     Any Sufficiently advanced bug is indistinguishable for a feature.
  13598.                         - Rick Kulawiec
  13599.  
  13600. On Fri, 12 Mar 1999, Sean Herr wrote:
  13601.  
  13602. > Yes. I was an ass and forgot the password.
  13603. > 
  13604. > Sean Herr
  13605. > @YourNET Connection, Inc.
  13606. > 847-524-3910
  13607. > http://www.ync.net
  13608. > 
  13609. > 
  13610. > -----Original Message-----
  13611. > From: Mike Wronski [mailto:mike@coredump.ae.usr.com]
  13612. > Sent: Friday, March 12, 1999 3:52 PM
  13613. > To: usr-tc@lists.xmission.com
  13614. > Subject: RE: (usr-tc) How to clear ROM on ARC
  13615. > 
  13616. > 
  13617. > 
  13618. > 
  13619. > |-----Original Message-----
  13620. > |From: owner-usr-tc@lists.xmission.com
  13621. > |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Sean Herr
  13622. > |Sent: Friday, March 12, 1999 3:30 PM
  13623. > |To: 'usr-tc@lists.xmission.com'
  13624. > |Subject: (usr-tc) How to clear ROM on ARC
  13625. > |
  13626. > |
  13627. > |Can anyone tell me how to clear the Flash ROM on a HiperARC.
  13628. > |
  13629. > 
  13630. > Multiple Options below:
  13631. > 
  13632. > Format Flash:
  13633. > Set up a console connection. Reboot the card. During the pause after the ROM
  13634. > version number type (case sensative!)
  13635. > "AT{ZF}"
  13636. > 
  13637. > Begin a zmodem upload of HARC software. You will have a completely clean
  13638. > software
  13639. > install when the upload completes.
  13640. > 
  13641. > 
  13642. > If you just want to erase the configuration, the command "DELETE
  13643. > CONFIGURATION"
  13644. > will do. Unless you forgot the manage user password? Then use the console
  13645. > connection and clear the ROM from the boot ROM menu.
  13646. > 
  13647. > -M
  13648. > 
  13649. > 
  13650. > -
  13651. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13652. >  with "unsubscribe usr-tc" in the body of the message.
  13653. >  For information on digests or retrieving files and old messages send
  13654. >  "help" to the same address.  Do not use quotes in your message.
  13655. > 
  13656. > -
  13657. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13658. >  with "unsubscribe usr-tc" in the body of the message.
  13659. >  For information on digests or retrieving files and old messages send
  13660. >  "help" to the same address.  Do not use quotes in your message.
  13661. > 
  13662.  
  13663. -
  13664.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13665.  with "unsubscribe usr-tc" in the body of the message.
  13666.  For information on digests or retrieving files and old messages send
  13667.  "help" to the same address.  Do not use quotes in your message.
  13668.  
  13669.  
  13670. -------------------------------------------------------------------------------
  13671.  
  13672. From: Jeff Mcadams <jeffm@iglou.com>
  13673. Subject: Re: (usr-tc) Dual PRI: DS0-to-modem inconsistency
  13674. Date: 13 Mar 1999 12:05:02 -0500 (EST)
  13675.  
  13676. Thus spake Mark R. Lindsey
  13677. >: >Our problem is this: the dual PRI won't take any calls. My theory is
  13678. >: >that because it's not showing a mapping of DS0s to modems, it doesn't
  13679. >: >think there are any modems available for the incoming calls. However: in
  13680. >: >some other displayable tables, the PRI card itself is saying that both
  13681. >: >the modems and the ISDN gateway (a Netserver, in this case) are
  13682. >: >available.  
  13683. >: 
  13684. >: Not that it should affect it, but change your ISDN GW to 0, let the
  13685. >: quads handle it...you'll be much better off with it.
  13686.  
  13687. >I thought the ISDN GW was supposed to be the Netserver or HARC.  I guess not.
  13688.  
  13689. The ISDN GW is the card(s) that the PRI card hands off ISDN calls to in
  13690. order to handle the ISDN data signaling.  The NETServer can do this
  13691. because of the Munich daughter card, you're better off letting the quads
  13692. handle it though (indicate this by setting the gw to 0)
  13693.  
  13694. >: The other thing to check is on the modems, make sure they are set to
  13695. >: line src of pritdm and not t1tdm.
  13696.  
  13697. >Right. Thanks.
  13698.  
  13699. There are other things that can cause what you were/are seeing, but this
  13700. is the first thing I check.  :)
  13701. -- 
  13702. Jeff McAdams                            Email: jeffm@iglou.com
  13703. Head Network Administrator              Voice: (502) 966-3848
  13704. IgLou Internet Services                        (800) 436-4456
  13705.  
  13706. -
  13707.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13708.  with "unsubscribe usr-tc" in the body of the message.
  13709.  For information on digests or retrieving files and old messages send
  13710.  "help" to the same address.  Do not use quotes in your message.
  13711.  
  13712.  
  13713. -------------------------------------------------------------------------------
  13714.  
  13715. From: Jeff Mcadams <jeffm@iglou.com>
  13716. Subject: Re: (usr-tc) odd problem
  13717. Date: 13 Mar 1999 12:06:34 -0500 (EST)
  13718.  
  13719. Thus spake Tatai SV Krishnan
  13720. >On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote:
  13721. >> What version of the codes are you running on the ARC, DSP's and Quads?
  13722. >> 
  13723. >> Also can anyone else confirm that we're _not_ supposed to be shooting the
  13724. >> MTU value in radius?
  13725. >> 
  13726.  
  13727. >This has nothing to do with HiPer arc code or DSP or Quad code.  For all 
  13728. >HiPer arcs you either set the MTU to 1500 or do not set any value.  
  13729. >Setting the MTU to a lower value other than 1500 will cause users unable 
  13730. >to browse certain websites.
  13731.  
  13732. Boy is *that* an oversimplification of the situation.  Care to expound
  13733. on *why* this occurs?  Are we talking about broken path mtu discovery
  13734. here or what?  if so, where is it broken?  if not, what else is causing
  13735. this?
  13736. -- 
  13737. Jeff McAdams                            Email: jeffm@iglou.com
  13738. Head Network Administrator              Voice: (502) 966-3848
  13739. IgLou Internet Services                        (800) 436-4456
  13740.  
  13741. -
  13742.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13743.  with "unsubscribe usr-tc" in the body of the message.
  13744.  For information on digests or retrieving files and old messages send
  13745.  "help" to the same address.  Do not use quotes in your message.
  13746.  
  13747.  
  13748. -------------------------------------------------------------------------------
  13749.  
  13750. From: jeff.binkley@asacomp.com (Jeff Binkley)
  13751. Subject: Re: (usr-tc) odd problem
  13752. Date: 13 Mar 1999 13:54:00 -0500
  13753.  
  13754.  
  13755.  
  13756.  
  13757. More likely simple packet fragmentation problems.  I've seen users mess 
  13758. with their MTU setting and make them too high and have the exact same 
  13759. effect.
  13760.  
  13761. Jeff Binkley
  13762. ASA Network Computing
  13763.  
  13764.  
  13765. u>Thus spake Tatai SV Krishnan
  13766. u>>On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote:
  13767. u>>> What version of the codes are you running on the ARC, DSP's and
  13768. u>>> Quads? 
  13769.  
  13770. u>>> Also can anyone else confirm that we're _not_ supposed to be
  13771. u>>> shooting the MTU value in radius?
  13772.  
  13773.  
  13774. u>>This has nothing to do with HiPer arc code or DSP or Quad code.  For
  13775. u>all  >HiPer arcs you either set the MTU to 1500 or do not set any
  13776. u>value.   >Setting the MTU to a lower value other than 1500 will cause
  13777. u>users unable  >to browse certain websites.
  13778.  
  13779. u>Boy is *that* an oversimplification of the situation.  Care to expound
  13780. u>on *why* this occurs?  Are we talking about broken path mtu discovery
  13781. u>here or what?  if so, where is it broken?  if not, what else is
  13782. u>causing this?
  13783. u>-- 
  13784. u>Jeff McAdams                            Email: jeffm@iglou.com
  13785. u>Head Network Administrator              Voice: (502) 966-3848
  13786. u>IgLou Internet Services                        (800) 436-4456
  13787.  
  13788. u>-
  13789. u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13790. u> with "unsubscribe usr-tc" in the body of the message.
  13791. u> For information on digests or retrieving files and old messages send
  13792. u> "help" to the same address.  Do not use quotes in your message.
  13793.  
  13794. CMPQwk 1.42-21 9999
  13795.  
  13796.  
  13797. -
  13798.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13799.  with "unsubscribe usr-tc" in the body of the message.
  13800.  For information on digests or retrieving files and old messages send
  13801.  "help" to the same address.  Do not use quotes in your message.
  13802.  
  13803.  
  13804. -------------------------------------------------------------------------------
  13805.  
  13806. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  13807. Subject: Re: (usr-tc) odd problem
  13808. Date: 13 Mar 1999 14:44:11 -0600 (CST)
  13809.  
  13810. On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  13811.  
  13812. > >This has nothing to do with HiPer arc code or DSP or Quad code.  For all 
  13813. > >HiPer arcs you either set the MTU to 1500 or do not set any value.  
  13814. > >Setting the MTU to a lower value other than 1500 will cause users unable 
  13815. > >to browse certain websites.
  13816. > 
  13817. > Boy is *that* an oversimplification of the situation.  Care to expound
  13818. > on *why* this occurs?  Are we talking about broken path mtu discovery
  13819. > here or what?  if so, where is it broken?  if not, what else is causing
  13820. > this?
  13821. > -- 
  13822.  
  13823.  
  13824. It is not a oversimplification of the situation.  Here the situation 
  13825. itself is very simple.  Its nothing to do with broken path mtu or 
  13826. discovery here.  MTU - here is the MRU requested by the peer and it opten 
  13827. maps locally into the interface as MTU as long as MP is not in use.  If 
  13828. you look at the RFC 1661 the MTU that is mapped which is the peer MRU  - 
  13829. which is sent in a configure-request message is the maximum size of PPP 
  13830. information field that the implementation can receive. The negotiated MRU 
  13831. is used for both subsequenct NCP negotiations messages and actual user 
  13832. data.  This means that the actual MRU negotiated must be atlesat as large 
  13833. as the largest negotiation messages or user datagram sent.  In particualr 
  13834. if this value is smaill the it may need to be alterned to allow 
  13835. authentication to proceed. 
  13836.  
  13837.  
  13838. Some implementations are requried to accept a PPP information field of 
  13839. atleast 1500 octets at all times, regardless of the negotiated value.  
  13840. Some implementations caluculate this value based on connection speed, but 
  13841. then again in case of speed greater than 14.4 K this is not worthwile.
  13842.  
  13843. Hiper arc is implemented in sucha a way that the value here should be 
  13844. 1500 buytes at all times.
  13845.  
  13846.  
  13847. Krish
  13848.  
  13849.  
  13850.  
  13851. > Jeff McAdams                            Email: jeffm@iglou.com
  13852. > Head Network Administrator              Voice: (502) 966-3848
  13853. > IgLou Internet Services                        (800) 436-4456
  13854. > 
  13855. > -
  13856. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13857. >  with "unsubscribe usr-tc" in the body of the message.
  13858. >  For information on digests or retrieving files and old messages send
  13859. >  "help" to the same address.  Do not use quotes in your message.
  13860. > 
  13861.  
  13862. -
  13863.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13864.  with "unsubscribe usr-tc" in the body of the message.
  13865.  For information on digests or retrieving files and old messages send
  13866.  "help" to the same address.  Do not use quotes in your message.
  13867.  
  13868.  
  13869. -------------------------------------------------------------------------------
  13870.  
  13871. From: Jeff Mcadams <jeffm@iglou.com>
  13872. Subject: Re: (usr-tc) odd problem
  13873. Date: 13 Mar 1999 16:01:50 -0500 (EST)
  13874.  
  13875. Thus spake Tatai SV Krishnan
  13876. >On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  13877. >> Boy is *that* an oversimplification of the situation.  Care to expound
  13878. >> on *why* this occurs?  Are we talking about broken path mtu discovery
  13879. >> here or what?  if so, where is it broken?  if not, what else is causing
  13880. >> this?
  13881.  
  13882. >Some implementations are requried to accept a PPP information field of 
  13883. >atleast 1500 octets at all times, regardless of the negotiated value.  
  13884. >Some implementations caluculate this value based on connection speed, but 
  13885. >then again in case of speed greater than 14.4 K this is not worthwile.
  13886.  
  13887. >Hiper arc is implemented in sucha a way that the value here should be 
  13888. >1500 buytes at all times.
  13889.  
  13890. So how does the HiPer Arc respond if the MTU/MRU is set (either on the
  13891. interface, default user, or whatever) is set to something other than
  13892. 1500 (the default on the default user from what I've seen is 1514, so
  13893. please comment on when its set higher than 1500 and lower).
  13894. -- 
  13895. Jeff McAdams                            Email: jeffm@iglou.com
  13896. Head Network Administrator              Voice: (502) 966-3848
  13897. IgLou Internet Services                        (800) 436-4456
  13898.  
  13899. -
  13900.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13901.  with "unsubscribe usr-tc" in the body of the message.
  13902.  For information on digests or retrieving files and old messages send
  13903.  "help" to the same address.  Do not use quotes in your message.
  13904.  
  13905.  
  13906. -------------------------------------------------------------------------------
  13907.  
  13908. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  13909. Subject: Re: (usr-tc) odd problem
  13910. Date: 13 Mar 1999 15:30:59 -0600 (CST)
  13911.  
  13912. On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  13913.  
  13914. > So how does the HiPer Arc respond if the MTU/MRU is set (either on the
  13915. > interface, default user, or whatever) is set to something other than
  13916. > 1500 (the default on the default user from what I've seen is 1514, so
  13917. > please comment on when its set higher than 1500 and lower).
  13918. > -- 
  13919.  
  13920. The default user is set to a value of 1514.  Eventhough only 1500 is set 
  13921. and used, the default user setup is still set to 1514.  There is a 
  13922. open issue where we have requested this value to be set at 1500.
  13923.  
  13924. If the radius server sends a MTU then the default user MTU is not 
  13925. applied.  Meaning - the default user is a template so when a user is 
  13926. authenticated via radius - all values that are sent by radius are applied 
  13927. to the user and other values that are not sent by the radius are taken 
  13928. from the default user.  So if you do not send a MTU then the default user 
  13929. MTU is used.  I have never tried sending a MTU value greater than 1500 
  13930. from radius.  I am not sure what will happen if this is done.  Need to 
  13931. get back to you on this issue.  
  13932.  
  13933.  
  13934. krish
  13935.  
  13936.  
  13937.  
  13938. > Jeff McAdams                            Email: jeffm@iglou.com
  13939. > Head Network Administrator              Voice: (502) 966-3848
  13940. > IgLou Internet Services                        (800) 436-4456
  13941. > 
  13942. > -
  13943. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13944. >  with "unsubscribe usr-tc" in the body of the message.
  13945. >  For information on digests or retrieving files and old messages send
  13946. >  "help" to the same address.  Do not use quotes in your message.
  13947. > 
  13948.  
  13949. -
  13950.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  13951.  with "unsubscribe usr-tc" in the body of the message.
  13952.  For information on digests or retrieving files and old messages send
  13953.  "help" to the same address.  Do not use quotes in your message.
  13954.  
  13955.  
  13956. -------------------------------------------------------------------------------
  13957.  
  13958. From: Jeff Mcadams <jeffm@iglou.com>
  13959. Subject: Re: (usr-tc) odd problem
  13960. Date: 13 Mar 1999 16:32:26 -0500 (EST)
  13961.  
  13962. Thus spake Tatai SV Krishnan
  13963. >On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  13964. >> So how does the HiPer Arc respond if the MTU/MRU is set (either on the
  13965. >> interface, default user, or whatever) is set to something other than
  13966. >> 1500 (the default on the default user from what I've seen is 1514, so
  13967. >> please comment on when its set higher than 1500 and lower).
  13968.  
  13969. >The default user is set to a value of 1514.  Eventhough only 1500 is set 
  13970. >and used, the default user setup is still set to 1514.  There is a 
  13971. >open issue where we have requested this value to be set at 1500.
  13972.  
  13973. >If the radius server sends a MTU then the default user MTU is not 
  13974. >applied.  Meaning - the default user is a template so when a user is 
  13975. >authenticated via radius - all values that are sent by radius are applied 
  13976. >to the user and other values that are not sent by the radius are taken 
  13977. >from the default user.  So if you do not send a MTU then the default user 
  13978. >MTU is used.  
  13979.  
  13980. Right, I understand that...and I have a lot of users getting MTU's of
  13981. 1514.  Also, since the MTU is negotiated in LCP, before the RADIUS
  13982. response is received in PAP, how is that handled?  Does it go ahead and
  13983. use the value set on the default user.  I'm pretty sure it doesn't
  13984. restart LCP.  Does it set its own MTU down without restarting LCP?  That
  13985. would be in spec if the MTU was lowered from what was negotiated in LCP.
  13986.  
  13987. Other questions...how does it behave if the default user has an MTU set
  13988. of 576 (a common value), and isn't overridden in RADIUS?  What happens
  13989. when a 1500 byte packet comes at it?  drop it?  send it anyway?
  13990.  
  13991. The reason I'm asking and trying to get a good answer here is that from
  13992. what you're saying, it sounds like the implementation is broken.
  13993.  
  13994. >I have never tried sending a MTU value greater than 1500 
  13995. >from radius.  I am not sure what will happen if this is done.  Need to 
  13996. >get back to you on this issue.  
  13997.  
  13998. I'm *more* concerned about MTU's smaller than 1500.  I would also be
  13999. concerned if an MTU bigger than what was negotiated in LCP was received
  14000. and used during PAP...that would be broken as well...but I doubt that's
  14001. happening.
  14002. -- 
  14003. Jeff McAdams                            Email: jeffm@iglou.com
  14004. Head Network Administrator              Voice: (502) 966-3848
  14005. IgLou Internet Services                        (800) 436-4456
  14006.  
  14007. -
  14008.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14009.  with "unsubscribe usr-tc" in the body of the message.
  14010.  For information on digests or retrieving files and old messages send
  14011.  "help" to the same address.  Do not use quotes in your message.
  14012.  
  14013.  
  14014. -------------------------------------------------------------------------------
  14015.  
  14016. From: mark@vielle.datasys.net (Mark R. Lindsey)
  14017. Subject: Re: (usr-tc) Dual PRI: DS0-to-modem inconsistency
  14018. Date: 13 Mar 1999 13:13:14 -0500
  14019.  
  14020. : The ISDN GW is the card(s) that the PRI card hands off ISDN calls to in
  14021. : order to handle the ISDN data signaling.  The NETServer can do this
  14022. : because of the Munich daughter card, you're better off letting the quads
  14023. : handle it though (indicate this by setting the gw to 0)
  14024.  
  14025. Aha. The console interface won't let you configure this to 0, so I
  14026. set it to `None'.
  14027.  
  14028. : >: The other thing to check is on the modems, make sure they are set to
  14029. : >: line src of pritdm and not t1tdm.
  14030. : 
  14031. : >Right. Thanks.
  14032. : 
  14033. : There are other things that can cause what you were/are seeing, but this
  14034. : is the first thing I check.  :)
  14035.  
  14036. I verified that that was setup, and I see no change.
  14037.  
  14038. Should the DS0 status (Main Menu -> 2 -> 6 or 8) show modem cards
  14039. together with slots?
  14040.  
  14041. This may be related: When I try to change the slot devices from Qbch-I_mdm
  14042. to Qbch-Mdm, I get a bunch of errors. Here's a log of an attempt to do so.
  14043. (Scanning over the archives, I see that this has been mentioned before.)
  14044.  
  14045.  
  14046.  
  14047.  
  14048.  
  14049.  
  14050.  
  14051.  
  14052.  Chassis Slot Device  Configuration  Status
  14053.  
  14054.  Current Configuration Status
  14055.          Device             Device
  14056.  Slot#    Type      Slot#    Type
  14057.    1     Dual-PRI     9     Qbch-I_mdm
  14058.    2     NONE        10     Qbch-I_mdm
  14059.    3     Qbch-I_mdm  11     Qbch-I_mdm
  14060.    4     Qbch-I_mdm  12     Qbch-I_mdm
  14061.    5     Qbch-I_mdm  13     Qbch-I_mdm
  14062.    6     Qbch-I_mdm  14     Qbch-I_mdm
  14063.    7     Qbch-I_mdm  15     NONE
  14064.    8     Qbch-I_mdm  16     ISDN-GW
  14065.  Assign device types to chassis slot numbers given the format below:
  14066.        DEVICE_TYPE#:S#[,S#,S#-S#]
  14067.  Where,
  14068.    DEVICE_TYPE# -> q - QBCH-MDM,g - ISDN-GW,n - NONE (no ISDN Device in Slot)
  14069.                    i - QBCH-I_MDM,S# -> Chassis Slot# (1-16)
  14070.  Example: q:4,5 assigns the QBCH-MDM NAC device type to slots 4 and 5.
  14071.  >: q:3-14ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14072. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14073. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14074. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14075. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14076. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14077. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14078. eRROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14079. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14080. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14081. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14082. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14083. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14084. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14085. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14086. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14087. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14088. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14089. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14090. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14091. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14092. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14093. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14094. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14095. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14096. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14097. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14098. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14099. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14100. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14101. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14102. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14103. ERROR uccproc_install_qmdm_chan: pb_dg__open() failed, err = -1
  14104. ERROR uccpbus_closed_cb: handle >0< being closed is invalid.
  14105. ERROR uccpbus_closed_cb: handle >1< being closed is invalid.
  14106. ERROR uccpbus_closed_cb: handle >2< being closed is invalid.
  14107. ERROR uccpbus_closed_cb: handle >3< being closed is invalid.
  14108. ERROR uccpbus_opened_cb: handle >49< already up OR not pending.
  14109. ERROR uccpbus_opened_cb: handle >50< already up OR not pending.
  14110. ERROR uccpbus_opened_cb: handle >51< already up OR not pending.
  14111. ERROR uccpbus_opened_cb: handle >52< already up OR not pending.
  14112. ERROR uccpbus_closed_cb: handle >4< being closed is invalid.
  14113. ERROR uccpbus_closed_cb: handle >5< being closed is invalid.
  14114. ERROR uccpbus_closed_cb: handle >6< being closed is invalid.
  14115. ERROR uccpbus_closed_cb: handle >7< being closed is invalid.
  14116. ERROR uccpbus_opened_cb: handle >53< already up OR not pending.
  14117. ERROR uccpbus_opened_cb: handle >54< already up OR not pending.
  14118. ERROR uccpbus_opened_cb: handle >55< already up OR not pending.
  14119. ERROR uccpbus_opened_cb: handle >56< already up OR not pending.
  14120. ERROR uccpbus_closed_cb: handle >8< being closed is invalid.
  14121. ERROR uccpbus_closed_cb: handle >9< being closed is invalid.
  14122. ERROR uccpbus_closed_cb: handle >10< being closed is invalid.
  14123. ERROR uccpbus_closed_cb: handle >11< being closed is invalid.
  14124. ERROR uccpbus_opened_cb: handle >57< already up OR not pending.
  14125. ERROR uccpbus_opened_cb: handle >58< already up OR not pending.
  14126. ERROR uccpbus_opened_cb: handle >59< already up OR not pending.
  14127. ERROR uccpbus_opened_cb: handle >60< already up OR not pending.
  14128. ERROR uccpbus_closed_cb: handle >12< being closed is invalid.
  14129. ERROR uccpbus_closed_cb: handle >13< being closed is invalid.
  14130. ERROR uccpbus_closed_cb: handle >14< being closed is invalid.
  14131. ERROR uccpbus_closed_cb: handle >15< being closed is invalid.
  14132. ERROR uccpbus_opened_cb: handle >61< already up OR not pending.
  14133. ERROR uccpbus_opened_cb: handle >62< already up OR not pending.
  14134. ERROR uccpbus_opened_cb: handle >63< already up OR not pending.
  14135. ERROR uccpbus_closed_cb: handle >16< being closed is invalid.
  14136. ERROR uccpbus_closed_cb: handle >17< being closed is invalid.
  14137. ERROR uccpbus_closed_cb: handle >18< being closed is invalid.
  14138. ERROR uccpbus_closed_cb: handle >19< being closed is invalid.
  14139. ERROR uccpbus_closed_cb: handle >20< being closed is invalid.
  14140. ERROR uccpbus_closed_cb: handle >21< being closed is invalid.
  14141. ERROR uccpbus_closed_cb: handle >22< being closed is invalid.
  14142. ERROR uccpbus_closed_cb: handle >23< being closed is invalid.
  14143. ERROR uccpbus_closed_cb: handle >24< being closed is invalid.
  14144. ERROR uccpbus_closed_cb: handle >25< being closed is invalid.
  14145. ERROR uccpbus_closed_cb: handle >26< being closed is invalid.
  14146. ERROR uccpbus_closed_cb: handle >27< being closed is invalid.
  14147. ERROR uccpbus_closed_cb: handle >28< being closed is invalid.
  14148. ERROR uccpbus_closed_cb: handle >29< being closed is invalid.
  14149. ERROR uccpbus_closed_cb: handle >30< being closed is invalid.
  14150. ERROR uccpbus_closed_cb: handle >31< being closed is invalid.
  14151. ERROR uccpbus_closed_cb: handle >32< being closed is invalid.
  14152. ERROR uccpbus_closed_cb: handle >33< being closed is invalid.
  14153. ERROR uccpbus_closed_cb: handle >34< being closed is invalid.
  14154. ERROR uccpbus_closed_cb: handle >35< being closed is invalid.
  14155. ERROR uccpbus_closed_cb: handle >36< being closed is invalid.
  14156. ERROR uccpbus_closed_cb: handle >37< being closed is invalid.
  14157. ERROR uccpbus_closed_cb: handle >38< being closed is invalid.
  14158. ERROR uccpbus_closed_cb: handle >39< being closed is invalid.
  14159. ERROR uccpbus_closed_cb: handle >40< being closed is invalid.
  14160. ERROR uccpbus_closed_cb: handle >41< being closed is invalid.
  14161. ERROR uccpbus_closed_cb: handle >42< being closed is invalid.
  14162. ERROR uccpbus_closed_cb: handle >43< being closed is invalid.
  14163. ERROR uccpbus_closed_cb: handle >44< being closed is invalid.
  14164. ERROR uccpbus_closed_cb: handle >45< being closed is invalid.
  14165. ERROR uccpbus_closed_cb: handle >46< being closed is invalid.
  14166. ERROR uccpbus_closed_cb: handle >47< being closed is invalid.
  14167. ERROR uccpbus_closed_cb: handle >49< being closed is invalid.
  14168. ERROR uccpbus_closed_cb: handle >50< being closed is invalid.
  14169. ERROR uccpbus_closed_cb: handle >51< being closed is invalid.
  14170. ERROR uccpbus_closed_cb: handle >52< being closed is invalid.
  14171. ERROR uccpbus_opened_cb: handle >0< already up OR not pending.
  14172. ERROR uccpbus_opened_cb: handle >1< already up OR not pending.
  14173. ERROR uccpbus_opened_cb: handle >2< already up OR not pending.
  14174. ERROR uccpbus_opened_cb: handle >3< already up OR not pending.
  14175. ERROR uccpbus_closed_cb: handle >53< being closed is invalid.
  14176. ERROR uccpbus_closed_cb: handle >54< being closed is invalid.
  14177. ERROR uccpbus_closed_cb: handle >55< being closed is invalid.
  14178. ERROR uccpbus_closed_cb: handle >56< being closed is invalid.
  14179. ERROR uccpbus_opened_cb: handle >4< already up OR not pending.
  14180. ERROR uccpbus_opened_cb: handle >5< already up OR not pending.
  14181. ERROR uccpbus_opened_cb: handle >6< already up OR not pending.
  14182. ERROR uccpbus_opened_cb: handle >7< already up OR not pending.
  14183. ERROR uccpbus_closed_cb: handle >57< being closed is invalid.
  14184. ERROR uccpbus_closed_cb: handle >58< being closed is invalid.
  14185. ERROR uccpbus_closed_cb: handle >59< being closed is invalid.
  14186. ERROR uccpbus_closed_cb: handle >60< being closed is invalid.
  14187. ERROR uccpbus_opened_cb: handle >8< already up OR not pending.
  14188. ERROR uccpbus_opened_cb: handle >9< already up OR not pending.
  14189. ERROR uccpbus_opened_cb: handle >10< already up OR not pending.
  14190. ERROR uccpbus_opened_cb: handle >11< already up OR not pending.
  14191. ERROR uccpbus_closed_cb: handle >61< being closed is invalid.
  14192. ERROR uccpbus_closed_cb: handle >62< being closed is invalid.
  14193. ERROR uccpbus_closed_cb: handle >63< being closed is invalid.
  14194. ERROR uccpbus_opened_cb: handle >12< already up OR not pending.
  14195. ERROR uccpbus_opened_cb: handle >13< already up OR not pending.
  14196. ERROR uccpbus_opened_cb: handle >14< already up OR not pending.
  14197. ERROR uccpbus_opened_cb: handle >15< already up OR not pending.
  14198. ERROR uccpbus_opened_cb: handle >16< already up OR not pending.
  14199. ERROR uccpbus_opened_cb: handle >17< already up OR not pending.
  14200. ERROR uccpbus_opened_cb: handle >18< already up OR not pending.
  14201. ERROR uccpbus_opened_cb: handle >19< already up OR not pending.
  14202. ERROR uccpbus_opened_cb: handle >20< already up OR not pending.
  14203. ERROR uccpbus_opened_cb: handle >21< already up OR not pending.
  14204. ERROR uccpbus_opened_cb: handle >22< already up OR not pending.
  14205. ERROR uccpbus_opened_cb: handle >23< already up OR not pending.
  14206. ERROR uccpbus_opened_cb: handle >24< already up OR not pending.
  14207. ERROR uccpbus_opened_cb: handle >25< already up OR not pending.
  14208. ERROR uccpbus_opened_cb: handle >26< already up OR not pending.
  14209. ERROR uccpbus_opened_cb: handle >27< already up OR not pending.
  14210. ERROR uccpbus_opened_cb: handle >28< already up OR not pending.
  14211. ERROR uccpbus_opened_cb: handle >29< already up OR not pending.
  14212. ERROR uccpbus_opened_cb: handle >30< already up OR not pending.
  14213. ERROR uccpbus_opened_cb: handle >31< already up OR not pending.
  14214. ERROR uccpbus_opened_cb: handle >32< already up OR not pending.
  14215. ERROR uccpbus_opened_cb: handle >33< already up OR not pending.
  14216. ERROR uccpbus_opened_cb: handle >34< already up OR not pending.
  14217. ERROR uccpbus_opened_cb: handle >35< already up OR not pending.
  14218. ERROR uccpbus_opened_cb: handle >36< already up OR not pending.
  14219. ERROR uccpbus_opened_cb: handle >37< already up OR not pending.
  14220. ERROR uccpbus_opened_cb: handle >38< already up OR not pending.
  14221. ERROR uccpbus_opened_cb: handle >39< already up OR not pending.
  14222. ERROR uccpbus_opened_cb: handle >40< already up OR not pending.
  14223. ERROR uccpbus_opened_cb: handle >41< already up OR not pending.
  14224. ERROR uccpbus_opened_cb: handle >42< already up OR not pending.
  14225. ERROR uccpbus_opened_cb: handle >43< already up OR not pending.
  14226. ERROR uccpbus_opened_cb: handle >44< already up OR not pending.
  14227. ERROR uccpbus_opened_cb: handle >45< already up OR not pending.
  14228. ERROR uccpbus_opened_cb: handle >46< already up OR not pending.
  14229. ERROR uccpbus_opened_cb: handle >47< already up OR not pending.
  14230.  
  14231.  
  14232.  
  14233.  
  14234.  
  14235.  
  14236.  
  14237.  
  14238.  
  14239.  
  14240.  
  14241.  
  14242.  
  14243.  
  14244.  
  14245.  
  14246.  
  14247.  
  14248.  
  14249.  
  14250.  
  14251.  
  14252.  
  14253.  
  14254.  
  14255.     Card Configuration                        Current Setting
  14256.  
  14257.  1 Save current Configuration to NVRAM
  14258.  2 Restore NVRAM Configuration
  14259.  3 Restore Default Configuration
  14260.  4 Timing Source Priority Assignment           Span-1=1 Span-2=2 
  14261.  5 Chassis Slot Device Configuration 
  14262.  6 Modem Routing Method                        Fixed Assignment
  14263.  7 Configure Local Console Password
  14264.  8 Change DS0 state on Quad Modem NAC action   Disabled
  14265.  9 Companding Code Configuration               U-Law
  14266.  
  14267.  (NOTE: Changing configuration parameters may effect calls in progress.)
  14268.  
  14269.  Enter menu selection and press Return or press Esc to exit.
  14270.  Menu Selection (1-9):
  14271.  
  14272. -
  14273.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14274.  with "unsubscribe usr-tc" in the body of the message.
  14275.  For information on digests or retrieving files and old messages send
  14276.  "help" to the same address.  Do not use quotes in your message.
  14277.  
  14278.  
  14279. -------------------------------------------------------------------------------
  14280.  
  14281. From: "Daniel M. Vesledahl" <vesledah@teleline.es>
  14282. Subject: (usr-tc) Total Control Manager Questions
  14283. Date: 13 Mar 1999 17:28:22 +0100
  14284.  
  14285. I just picked up a couple Total Control Units.  Is the Total Control Manager
  14286. software required for configuration of these units, of does it just make it
  14287. easier?  Any additional info as to what software I would need for
  14288. configuration would be appreciated.  Also, can you run your primary backbone
  14289. t-1 line through a t-1 card on this chassis?  If not, how would you
  14290. recommend configuring for the backbone line (i.e. What kind of router / csu
  14291. / Dsu)
  14292.  
  14293. Thanks for the help in advance,,,
  14294. Daniel V.
  14295. vesledah@teleline.es
  14296.  
  14297. -
  14298.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14299.  with "unsubscribe usr-tc" in the body of the message.
  14300.  For information on digests or retrieving files and old messages send
  14301.  "help" to the same address.  Do not use quotes in your message.
  14302.  
  14303.  
  14304. -------------------------------------------------------------------------------
  14305.  
  14306. From: Ricky Beam <jfbeam@beaker.interpath.net>
  14307. Subject: RE: (usr-tc) V5.0 Security and Accounting Radius Server Software
  14308. Date: 12 Mar 1999 15:20:49 -0500 (EST)
  14309.  
  14310. On Fri, 12 Mar 1999, Scott Boggs wrote:
  14311. >We formerly used Ascend Access control with a max4000.
  14312. >When we put in our TotCtrl box, we needed a RADIUS that
  14313. >was usable with multiple hardware vendors.  The 3com RADIUS
  14314. >couldnt do it.  And the Access97 guts was needless overhead in my opinion. 
  14315.  
  14316. SA6 can handle multiple vendors.  And yes, I've hated the MS Access BS forever
  14317. as well.  But, if you don't run it under windows, then you don't have that
  14318. problem.
  14319.  
  14320. What's up with all you nuts using NT for a RADIUS server?  Gez.
  14321.  
  14322. --Ricky
  14323.  
  14324. -
  14325.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14326.  with "unsubscribe usr-tc" in the body of the message.
  14327.  For information on digests or retrieving files and old messages send
  14328.  "help" to the same address.  Do not use quotes in your message.
  14329.  
  14330.  
  14331. -------------------------------------------------------------------------------
  14332.  
  14333. From: Ricky Beam <jfbeam@beaker.interpath.net>
  14334. Subject: Re: (usr-tc) V5.0 Security and Accounting Radius Server Software
  14335. Date: 12 Mar 1999 15:14:31 -0500 (EST)
  14336.  
  14337. On Fri, 12 Mar 1999, Tony Loosle wrote:
  14338. >stay away from it at ALL costs.  stay far away!!
  14339. >
  14340. >they acutally have a version 6.??, but it's full of bugs, use's access,
  14341. >run's your cpu to 100% all the time.  You can't use port restrictions in
  14342. >every other version, it forgets who is logged in, then won't log them out
  14343. >and won't let them back in.
  14344.  
  14345. The server itself is not "full of bugs" -- it may still have a few, but they
  14346. aren't serious problems.  Only under NT does it use Access at "run you cpu to
  14347. 100%".  It can use Oracle, or any other ODBC capable database.  I've used
  14348. it with postgres, mysql, Oracle, Sybase, and flat files under UNIX.  The 100%
  14349. CPU thing is NT lying to you.  It is not using 100% of the CPU -- if it were,
  14350. then it would be interfering with other applications and it simply isn't.  (Of
  14351. course, that's a good reason to not use NT for a RADIUS server.)
  14352.  
  14353. HOWEVER, I do strongly recommend you burn the script and database schema USR
  14354. ships with the thing... it's just _ugly_.  I spent about a month rewriting the
  14355. database and the script to work in a more sane fashion -- it's written for
  14356. SA4, however, and alot has changed from SA4 -> SA5 -> SA6.  I started updating
  14357. the system, but the company I formerly worked for abandoned all my work in
  14358. favor of the far inferior CiscoSecure (6 months later, they still don't have
  14359. CiscoSecure doing all the things SA4 _is_ doing -- I doubt they ever will.)
  14360.  
  14361. If anyone is interested in that setup, drop me a note and I'll let you at it.
  14362.  
  14363. As for the RADIUS server keeping up with who is logged in where... that's
  14364. always been a mess.  I've yet to see a RADIUS system that did it correctly
  14365. without some outside help.  The RADIUS protocol is too stateless to construct
  14366. such a stateful restriction.  (Of course, USR goes about the restriction in
  14367. the wrong way from the get go... just because they authenticated doesn't mean
  14368. they are logged in.)
  14369.  
  14370. >There is of couse NO support whatsoever from USR!
  14371.  
  14372. And this suprises you?  USR does support it, but it hard to find the right
  14373. people.  Once you get past the muck, there are people who will help you with
  14374. it.  Of course, the best help comes from those who have used the product.
  14375. (esp. those who have had source code access to the product *grin*)
  14376.  
  14377. For all the bad press, I still think the USR RADIUS server is most full
  14378. featured and customizable of any RADIUS system.  It's a bit slow, but very
  14379. powerful.  (It'd be a screamer if it was multithreaded, but 3Com management is
  14380. too blind and/or stupid to see the benefits.)
  14381.  
  14382. --Ricky
  14383.  
  14384. -
  14385.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14386.  with "unsubscribe usr-tc" in the body of the message.
  14387.  For information on digests or retrieving files and old messages send
  14388.  "help" to the same address.  Do not use quotes in your message.
  14389.  
  14390.  
  14391. -------------------------------------------------------------------------------
  14392.  
  14393. From: "acparks" <acparks@bakersfieldrealtor.com>
  14394. Subject: Re: (usr-tc) x2Status - excessiveHFAttenuation
  14395. Date: 09 Apr 1999 12:13:16 -0700
  14396.  
  14397. Did you ad any new t1's? or PRI's?
  14398.  
  14399. We had the same problem but as a result of us adding more chassis and pri's
  14400. to our network room.
  14401.  
  14402. -----Original Message-----
  14403.  
  14404.  
  14405. It's definitely not everyone.  It has been working fine until today.  We are
  14406. also getting a lot of users that are not able to handshake at all.  Must be
  14407. a problem at the switch I guess.
  14408.  
  14409. -----Original Message-----
  14410.  
  14411.  
  14412. >Generally correct.  It could be a "line-side" T1, but then EVERYONE that
  14413. >tries x2/V.90 would get that result.
  14414. >
  14415. >On Fri, 26 Feb 1999, Mike Andrews wrote:
  14416. >
  14417. >> Nope...  Bad local loop on the client end, or a non-optimal SLC setup, or
  14418. >> something else that puts extra D/A conversions on their line that keep
  14419. >> x2/v.90 from working.
  14420. >>
  14421. >>
  14422. >> Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort
  14423. KY
  14424. >> mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see
  14425. me
  14426. >> getting beaten by the police, put down the video camera and come help
  14427. me!"
  14428. >>
  14429. >> On Fri, 26 Feb 1999, Theodore Cekan wrote:
  14430. >>
  14431. >> > What would cause an x2 Status value of excessiveHFAttenuation(12)?  Is
  14432. this
  14433. >> > a T1 problem?
  14434. >> >
  14435. >> > Ted
  14436. >>
  14437. >>
  14438. >> -
  14439. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14440. >>  with "unsubscribe usr-tc" in the body of the message.
  14441. >>  For information on digests or retrieving files and old messages send
  14442. >>  "help" to the same address.  Do not use quotes in your message.
  14443. >>
  14444. >
  14445. >
  14446. >-
  14447. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14448. > with "unsubscribe usr-tc" in the body of the message.
  14449. > For information on digests or retrieving files and old messages send
  14450. > "help" to the same address.  Do not use quotes in your message.
  14451. >
  14452.  
  14453.  
  14454. -
  14455. To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14456. with "unsubscribe usr-tc" in the body of the message.
  14457. For information on digests or retrieving files and old messages send
  14458. "help" to the same address.  Do not use quotes in your message.
  14459.  
  14460. -
  14461.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14462.  with "unsubscribe usr-tc" in the body of the message.
  14463.  For information on digests or retrieving files and old messages send
  14464.  "help" to the same address.  Do not use quotes in your message.
  14465.  
  14466.  
  14467. -------------------------------------------------------------------------------
  14468.  
  14469. From: Mahinder Kumar <mahinder@gto.net.om>
  14470. Subject: (usr-tc) Netserver 8 V.34 Configuration....
  14471. Date: 12 Mar 1999 21:22:16 +0400
  14472.  
  14473. Hi,
  14474. I am in the process of configuring a Netserver 8 V.34 device. I have =
  14475. tried following the steps described in Users Manual. Following is the =
  14476. summary
  14477. Of commands issued so far.=20
  14478. netserver>netserver>set system name "netserver"
  14479. netserver>set system location "ABC"
  14480. netserver>set system contact "XYZ"
  14481. netserver>set command login_required yes
  14482. netserver>add user "administrator" password "password" type login,manage
  14483. netserver>add snmp community public address 0.0.0.0 access RW
  14484. netserver>enable security_option remote_user_administration telnet
  14485. netserver>add syslog 172.16.8.2 loglevel critical
  14486. netserver>set accounting primary_server 172.16.8.2
  14487. netserver>set authentication primary_server 172.16.8.2 primary_secret =
  14488. "unknown"
  14489. netserver>add ip network "drcnet" interface eth:1 address =
  14490. 172.16.8.4/255.255.248
  14491. .0 frame ethernet_ii enable no
  14492. netserver>enable ip network "net"
  14493. netserver>enable ip forwarding
  14494. netserver>add dns server 172.16.8.2 preference 1
  14495. netserver>set dns domain_name "xyz.com"
  14496. netserver>set ip system initial_pool_address 172.16.9.101 pool_members 8
  14497. netserver>add tftp client 0.0.0.0
  14498. netserver>save all
  14499. Saving..... SAVE ALL
  14500. SAVE ALL  Complete
  14501. netserver>add user test password test type network network_service ppp
  14502. netserver>set network user test address_selection assign
  14503. netserver>save all
  14504. Saving..... SAVE ALL
  14505. SAVE ALL  Complete
  14506.  
  14507. Problem is that when I try connecting to Netserver from my PC through =
  14508. modem, message " server couldn't negotiate compatible set of protocols =
  14509. defined
  14510. Under Network Configuration , check your network configuration under =
  14511. control panel" appears, and fails to make a connection.
  14512. On my PC I have configured TCP/IP for dial up connection, PPP is defined =
  14513. as protocol for dial up connection.
  14514. I have tried disabling remote authentication as Radius is still not =
  14515. configured.
  14516.  
  14517. Any idea what I am missing while configuring. TIA
  14518.  
  14519. Regards,
  14520.  
  14521. -
  14522.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14523.  with "unsubscribe usr-tc" in the body of the message.
  14524.  For information on digests or retrieving files and old messages send
  14525.  "help" to the same address.  Do not use quotes in your message.
  14526.  
  14527.  
  14528. -------------------------------------------------------------------------------
  14529.  
  14530. From: Ricky Beam <jfbeam@beaker.interpath.net>
  14531. Subject: RE: (usr-tc) 3Com Problems.
  14532. Date: 10 Mar 1999 04:22:58 -0500 (EST)
  14533.  
  14534. BGP4 didn't exist way back then :-)
  14535.  
  14536. On Wed, 10 Mar 1999, Robert von Bismarck wrote:
  14537.  
  14538. >     Even the PM2 does BGP... but it's BGP3 which is pretty useless.
  14539. > 
  14540.  
  14541. -
  14542.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14543.  with "unsubscribe usr-tc" in the body of the message.
  14544.  For information on digests or retrieving files and old messages send
  14545.  "help" to the same address.  Do not use quotes in your message.
  14546.  
  14547.  
  14548. -------------------------------------------------------------------------------
  14549.  
  14550. From: "Mike Hamrich" <mhamrich@drfast.net>
  14551. Subject: (usr-tc) Help, upgraded from netserver to hyperarc now lot's of disconnects.
  14552. Date: 09 Mar 1999 21:37:12 -0500
  14553.  
  14554. This is a multi-part message in MIME format.
  14555.  
  14556. ------=_NextPart_000_0023_01BE6A74.FE3E5100
  14557. Content-Type: text/plain;
  14558.     charset="iso-8859-1"
  14559. Content-Transfer-Encoding: quoted-printable
  14560.  
  14561. Hi all,
  14562.  
  14563. We just upgraded from Netserver based code relase 2.5.1 to HyperArc =
  14564. release 3.3.3 And now we are getting tons of disconnects. Within 30 =
  14565. seconds or less of logging on. 90% of the quickly disconnected  users =
  14566. show V42Disconect(42) command while 10% show GatewayDisconnect(62) =
  14567. Mostly USR modems Sportsters a few Courier and few Sportster Winmodems. =
  14568. ISDN clients work great.
  14569.  
  14570. We have the latest code on the Quads, they were running 5.1.7 now 5.10.9 =
  14571. ,NMC is 5.5.5 with the inculded mem upgrade. and the HyperArc is the =
  14572. latest 4.1.59 -6, though on chassiy inventory the -6 is missing.
  14573.  
  14574. Before we upgraded we put the PRI's out of service, onhooked offhooked =
  14575. the modem's and set all the Quads to "default" then saved to NVRAM and =
  14576. rebooted. Any Ideas?
  14577.  
  14578.  
  14579.  
  14580. ------=_NextPart_000_0023_01BE6A74.FE3E5100
  14581. Content-Type: text/html;
  14582.     charset="iso-8859-1"
  14583. Content-Transfer-Encoding: quoted-printable
  14584.  
  14585. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  14586. <HTML>
  14587. <HEAD>
  14588.  
  14589. <META content=3Dtext/html;charset=3Diso-8859-1 =
  14590. http-equiv=3DContent-Type>
  14591. <META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
  14592. </HEAD>
  14593. <BODY bgColor=3D#ffffff>
  14594. <DIV><FONT color=3D#000000 size=3D2>Hi all,</FONT></DIV>
  14595. <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
  14596. <DIV><FONT size=3D2>We just upgraded from Netserver based code relase =
  14597. 2.5.1 to=20
  14598. HyperArc release 3.3.3 And now we are getting tons of disconnects. =
  14599. Within 30=20
  14600. seconds or less of logging on. 90% of the quickly disconnected  =
  14601. users show=20
  14602. V42Disconect(42) command while 10% show GatewayDisconnect(62) Mostly USR =
  14603. modems=20
  14604. Sportsters a few Courier and few Sportster Winmodems. ISDN clients work=20
  14605. great.</FONT></DIV>
  14606. <DIV><FONT size=3D2></FONT> </DIV>
  14607. <DIV><FONT size=3D2>We have the latest code on the Quads, they were =
  14608. running 5.1.7=20
  14609. now 5.10.9 ,NMC is 5.5.5 with the inculded mem upgrade. and the HyperArc =
  14610. is the=20
  14611. latest 4.1.59 -6, though on chassiy inventory the -6 is =
  14612. missing.</FONT></DIV>
  14613. <DIV> </DIV>
  14614. <DIV><FONT color=3D#000000 size=3D2>Before we upgraded we put the PRI's =
  14615. out of=20
  14616. service, onhooked offhooked the modem's and set all the Quads to=20
  14617. "default" then saved to NVRAM and rebooted. Any =
  14618. Ideas?</FONT></DIV>
  14619. <DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
  14620. <DIV> </DIV></BODY></HTML>
  14621.  
  14622. ------=_NextPart_000_0023_01BE6A74.FE3E5100--
  14623.  
  14624. -
  14625.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14626.  with "unsubscribe usr-tc" in the body of the message.
  14627.  For information on digests or retrieving files and old messages send
  14628.  "help" to the same address.  Do not use quotes in your message.
  14629.  
  14630.  
  14631. -------------------------------------------------------------------------------
  14632.  
  14633. From: Jose Roberto Sonquit <jobert@impactnet.com>
  14634. Subject: (usr-tc) V.90 Problem with DSP
  14635. Date: 09 Mar 1999 21:03:55 +0800
  14636.  
  14637. I have just installed 4 hiper DSP (sw:1.1.93 E1/CAS), 1 ARC in a tcs hub
  14638. (sw:4.1.1) , may problem is how come that almost all of the v.90
  14639. connections I have doesn't go beyond 33K if they do they get
  14640. disconnected in a few sec ... also how do you set  a connection x2 first
  14641. then v.90 ?
  14642.  
  14643. I hope you can help me on this
  14644. Thanks
  14645.  
  14646. Jobert
  14647.  
  14648. -
  14649.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14650.  with "unsubscribe usr-tc" in the body of the message.
  14651.  For information on digests or retrieving files and old messages send
  14652.  "help" to the same address.  Do not use quotes in your message.
  14653.  
  14654.  
  14655. -------------------------------------------------------------------------------
  14656.  
  14657. From: Charles Sprickman <spork@inch.com>
  14658. Subject: Re: (usr-tc) odd problem
  14659. Date: 13 Mar 1999 17:31:02 -0500 (EST)
  14660.  
  14661. As an aside, I've always been confused on this point.  On a Cisco, for
  14662. example, you can set two different(?) mtu values.  You have one setting at
  14663. the IP level and one at the interface level...  I guess that means a PPP
  14664. (L2) value and an IP (L3) value???  Are dialup interfaces the same?  Am I
  14665. totally confused?
  14666.  
  14667. Charles
  14668.  
  14669. -- 
  14670. =-----------------=                                        = 
  14671. | Charles Sprickman                       Internet Channel |
  14672. | INCH System Administration Team         (212)243-5200    |
  14673. | spork@inch.com                          access@inch.com  |
  14674. =                                         =----------------=
  14675.  
  14676. On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  14677.  
  14678. > Thus spake Tatai SV Krishnan
  14679. > >On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  14680. > >> So how does the HiPer Arc respond if the MTU/MRU is set (either on the
  14681. > >> interface, default user, or whatever) is set to something other than
  14682. > >> 1500 (the default on the default user from what I've seen is 1514, so
  14683. > >> please comment on when its set higher than 1500 and lower).
  14684. > 
  14685. > >The default user is set to a value of 1514.  Eventhough only 1500 is set 
  14686. > >and used, the default user setup is still set to 1514.  There is a 
  14687. > >open issue where we have requested this value to be set at 1500.
  14688. > 
  14689. > >If the radius server sends a MTU then the default user MTU is not 
  14690. > >applied.  Meaning - the default user is a template so when a user is 
  14691. > >authenticated via radius - all values that are sent by radius are applied 
  14692. > >to the user and other values that are not sent by the radius are taken 
  14693. > >from the default user.  So if you do not send a MTU then the default user 
  14694. > >MTU is used.  
  14695. > 
  14696. > Right, I understand that...and I have a lot of users getting MTU's of
  14697. > 1514.  Also, since the MTU is negotiated in LCP, before the RADIUS
  14698. > response is received in PAP, how is that handled?  Does it go ahead and
  14699. > use the value set on the default user.  I'm pretty sure it doesn't
  14700. > restart LCP.  Does it set its own MTU down without restarting LCP?  That
  14701. > would be in spec if the MTU was lowered from what was negotiated in LCP.
  14702. > 
  14703. > Other questions...how does it behave if the default user has an MTU set
  14704. > of 576 (a common value), and isn't overridden in RADIUS?  What happens
  14705. > when a 1500 byte packet comes at it?  drop it?  send it anyway?
  14706. > 
  14707. > The reason I'm asking and trying to get a good answer here is that from
  14708. > what you're saying, it sounds like the implementation is broken.
  14709. > 
  14710. > >I have never tried sending a MTU value greater than 1500 
  14711. > >from radius.  I am not sure what will happen if this is done.  Need to 
  14712. > >get back to you on this issue.  
  14713. > 
  14714. > I'm *more* concerned about MTU's smaller than 1500.  I would also be
  14715. > concerned if an MTU bigger than what was negotiated in LCP was received
  14716. > and used during PAP...that would be broken as well...but I doubt that's
  14717. > happening.
  14718. > 
  14719.  
  14720.  
  14721. -
  14722.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14723.  with "unsubscribe usr-tc" in the body of the message.
  14724.  For information on digests or retrieving files and old messages send
  14725.  "help" to the same address.  Do not use quotes in your message.
  14726.  
  14727.  
  14728. -------------------------------------------------------------------------------
  14729.  
  14730. From: Ricky Beam <jfbeam@beaker.interpath.net>
  14731. Subject: Re: (usr-tc) Need sw to analyze Netserver Log
  14732. Date: 07 Mar 1999 18:41:05 -0500 (EST)
  14733.  
  14734. > Is there any commercial software or shareware, w/ whatever the Language
  14735. > it was written,
  14736. > that can be used to analyze the user login info that was logged from TC
  14737. > box into our
  14738. > Unix syslogd file. ?
  14739. > 
  14740. > We tried 3com's Accounting software before and not too enthusastic about
  14741. > it.
  14742. > And we do not have Radius.
  14743.  
  14744. Well, I've found the syslog data to be wrong too often to use it to bill
  14745. people.  I'll post the perl based junk I have for processing the syslog data
  14746. after I dig it back up.
  14747.  
  14748. --Ricky
  14749.  
  14750. -
  14751.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14752.  with "unsubscribe usr-tc" in the body of the message.
  14753.  For information on digests or retrieving files and old messages send
  14754.  "help" to the same address.  Do not use quotes in your message.
  14755.  
  14756.  
  14757. -------------------------------------------------------------------------------
  14758.  
  14759. From: Ricky Beam <jfbeam@beaker.interpath.net>
  14760. Subject: Re: (usr-tc) Seimens in talks to buy 3Com Unit
  14761. Date: 07 Mar 1999 16:23:48 -0500 (EST)
  14762.  
  14763. > I've heard the rumor about 3Com offloading the Total Control unit a few
  14764. > times now, so I'm starting to believe it.  This Siemens story makes me
  14765. > think it's going to happen.
  14766. > 
  14767. > > http://www.infoworld.com/cgi-bin/displayStory.pl?99034.ensiemens.htm
  14768. > 
  14769. > I hope the deal is beneficial for everyone.  Maybe Siemens will commit
  14770. > more resources to developing the Total Control products than 3Com has. 
  14771. > Higher density and DS3 ingress would be nice.
  14772.  
  14773. Seimens is the ones who payed for the development of VoIP in the TC.
  14774. (Maybe I want to move to Chicago after all :-))
  14775.  
  14776. --Ricky
  14777.  
  14778. -
  14779.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14780.  with "unsubscribe usr-tc" in the body of the message.
  14781.  For information on digests or retrieving files and old messages send
  14782.  "help" to the same address.  Do not use quotes in your message.
  14783.  
  14784.  
  14785. -------------------------------------------------------------------------------
  14786.  
  14787. From: Pete Ashdown <pashdown@xmission.com>
  14788. Subject: (usr-tc) Swanky universal gateway features
  14789. Date: 13 Mar 1999 15:34:29 -0700 (MST)
  14790.  
  14791. I just saw the Mediagate universal messaging box at ISPF and must say it
  14792. was one of the few things I was impressed with at the show.  However, it
  14793. had a couple of drawbacks (IMHO), it runs on NT (no flames please), and I
  14794. hate the $39 per mailbox "license fee" they charge for each person you
  14795. setup on YOUR OWN HARDWARE.
  14796.  
  14797. It sure would be swell if I could turn my TC's into a massive universal
  14798. messaging gateway.  If wishes were fishes...
  14799.  
  14800. Does anyone know of any other similar products?
  14801.  
  14802. -
  14803.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14804.  with "unsubscribe usr-tc" in the body of the message.
  14805.  For information on digests or retrieving files and old messages send
  14806.  "help" to the same address.  Do not use quotes in your message.
  14807.  
  14808.  
  14809. -------------------------------------------------------------------------------
  14810.  
  14811. From: Jeff Mcadams <jeffm@iglou.com>
  14812. Subject: Re: (usr-tc) Dual PRI: DS0-to-modem inconsistency
  14813. Date: 13 Mar 1999 17:40:28 -0500 (EST)
  14814.  
  14815. Thus spake Mark R. Lindsey
  14816. >: The ISDN GW is the card(s) that the PRI card hands off ISDN calls to in
  14817. >: order to handle the ISDN data signaling.  The NETServer can do this
  14818. >: because of the Munich daughter card, you're better off letting the quads
  14819. >: handle it though (indicate this by setting the gw to 0)
  14820.  
  14821. >Aha. The console interface won't let you configure this to 0, so I
  14822. >set it to `None'.
  14823.  
  14824. OK...that should work too.  I do it through SNMP/TCM.
  14825.  
  14826. >Should the DS0 status (Main Menu -> 2 -> 6 or 8) show modem cards
  14827. >together with slots?
  14828.  
  14829. Uhm...don't think so...(dredging out of memory here).  DS0 status is in
  14830. reference to the b channels on the PRI, not having anything to do with
  14831. the modems.
  14832.  
  14833. >This may be related: When I try to change the slot devices from Qbch-I_mdm
  14834. >to Qbch-Mdm, I get a bunch of errors. 
  14835.  
  14836. That's proly cause you don't want to do that.  If you have any halfway
  14837. recent code on the quads, you have qbch-i-mdm's.  Basically, that
  14838. indicates quad, b channel, I-modems.  I think that designation showed
  14839. up in version...uhm...5.7/5.8 of the quads?  Basically means that they
  14840. can handle ISDN or analog calls...executive summary, leave it at i-mdm.
  14841. :)
  14842. -- 
  14843. Jeff McAdams                            Email: jeffm@iglou.com
  14844. Head Network Administrator              Voice: (502) 966-3848
  14845. IgLou Internet Services                        (800) 436-4456
  14846.  
  14847. -
  14848.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14849.  with "unsubscribe usr-tc" in the body of the message.
  14850.  For information on digests or retrieving files and old messages send
  14851.  "help" to the same address.  Do not use quotes in your message.
  14852.  
  14853.  
  14854. -------------------------------------------------------------------------------
  14855.  
  14856. From: MegaZone <megazone@megazone.org>
  14857. Subject: Re: (usr-tc) Seimens in talks to buy 3Com Unit
  14858. Date: 13 Mar 1999 15:40:15 -0800 (PST)
  14859.  
  14860. Once upon a time Ricky Beam shaped the electrons to say...
  14861. >Seimens is the ones who payed for the development of VoIP in the TC.
  14862. >(Maybe I want to move to Chicago after all :-))
  14863.  
  14864. Not if what I heard from a number of people at ISPF is true, that there is
  14865. heavy downsizing in Chicago.
  14866.  
  14867. -MZ
  14868. -- 
  14869. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  14870. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  14871. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  14872. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  14873. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  14874.  
  14875. -
  14876.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14877.  with "unsubscribe usr-tc" in the body of the message.
  14878.  For information on digests or retrieving files and old messages send
  14879.  "help" to the same address.  Do not use quotes in your message.
  14880.  
  14881.  
  14882. -------------------------------------------------------------------------------
  14883.  
  14884. From: MegaZone <megazone@megazone.org>
  14885. Subject: Re: (usr-tc) 3Com Problems.
  14886. Date: 13 Mar 1999 15:43:52 -0800 (PST)
  14887.  
  14888. Once upon a time Robert von Bismarck shaped the electrons to say...
  14889. >  Disabled Modules: OSPF BGP
  14890. >
  14891. >Why mention it, if it's not inside or planned ? (I never tried to use it as
  14892. >it would have been pretty useless for me)
  14893.  
  14894. All ComOS builds, from the tiny OR to the mighty PM-4, come from the same
  14895. code tree.  There is a stub where the BGP code would be if it were included,
  14896. but there has never been any intention of actually putting it in a PM-2.
  14897. My OR-U has the same thing.  It is disabled - and cannot be enabled on that
  14898. platform.
  14899.  
  14900. -MZ
  14901. -- 
  14902. -=*X GOT CLUE? ISPF II - SAN DIEGO, CA 3/6-10 <URL:http://www.ispf.com/> X*=-
  14903. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  14904. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  14905. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  14906. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  14907.  
  14908. -
  14909.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14910.  with "unsubscribe usr-tc" in the body of the message.
  14911.  For information on digests or retrieving files and old messages send
  14912.  "help" to the same address.  Do not use quotes in your message.
  14913.  
  14914.  
  14915. -------------------------------------------------------------------------------
  14916.  
  14917. From: Dan Hollis <goemon@sasami.anime.net>
  14918. Subject: Re: (usr-tc) odd problem
  14919. Date: 13 Mar 1999 16:01:50 -0800 (PST)
  14920.  
  14921. On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  14922. > Boy is *that* an oversimplification of the situation.  Care to expound
  14923. > on *why* this occurs?  Are we talking about broken path mtu discovery
  14924. > here or what?  if so, where is it broken?  if not, what else is causing
  14925. > this?
  14926.  
  14927. WebTV's proxy servers have broken path mtu (theyre running an old version
  14928. of solaris and refuse to upgrade it) so if you lower the mtu then WebTV
  14929. users break.
  14930.  
  14931. -Dan
  14932.  
  14933.  
  14934. -
  14935.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14936.  with "unsubscribe usr-tc" in the body of the message.
  14937.  For information on digests or retrieving files and old messages send
  14938.  "help" to the same address.  Do not use quotes in your message.
  14939.  
  14940.  
  14941. -------------------------------------------------------------------------------
  14942.  
  14943. From: Jeff Mcadams <jeffm@iglou.com>
  14944. Subject: Re: (usr-tc) odd problem
  14945. Date: 13 Mar 1999 19:16:03 -0500 (EST)
  14946.  
  14947. Thus spake Dan Hollis
  14948. >On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  14949. >> Boy is *that* an oversimplification of the situation.  Care to expound
  14950. >> on *why* this occurs?  Are we talking about broken path mtu discovery
  14951. >> here or what?  if so, where is it broken?  if not, what else is causing
  14952. >> this?
  14953.  
  14954. >WebTV's proxy servers have broken path mtu (theyre running an old version
  14955. >of solaris and refuse to upgrade it) so if you lower the mtu then WebTV
  14956. >users break.
  14957.  
  14958. Well, that's assuming you even *CAN* lower the MTU.
  14959.  
  14960. FWIW...I did some experimenting this afternoon.
  14961.  
  14962. Only place I found to set the MTU on the Arc is:
  14963. set network user default Mtu <x>
  14964.  
  14965. Apparently, 3Com, in their infinite wisdom, decided not to even look at
  14966. the default user settings until the RADIUS Access-Accept packet is
  14967. received.
  14968.  
  14969. What does this mean?  Well, if you're using PPP based authentication
  14970. (like PAP, CHAP, whatever) it means you can't set the MTU for your PPP
  14971. links on your Arc *at all*.  Since the default user values aren't looked
  14972. at until the RADIUS Access-Accept packet is received, the MTU and MRU
  14973. have already been set during LCP, and the Arc refuses to revisit that
  14974. subject in any way...even if it doesn't require restarting LCP.
  14975.  
  14976. So, the *only* way I've found to set the MTU, and this won't work for
  14977. us, is to use a text based login, so the Access-Accept is returned
  14978. before PPP is even started up so the value can be used (either from the
  14979. default user, or from the RADIUS server) during LCP initially.
  14980.  
  14981. Come on 3Com, this stuff isn't exactly rocket science here.  How about
  14982. using a little bit of thought in how you do things?
  14983. -- 
  14984. Jeff McAdams                            Email: jeffm@iglou.com
  14985. Head Network Administrator              Voice: (502) 966-3848
  14986. IgLou Internet Services                        (800) 436-4456
  14987.  
  14988. -
  14989.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  14990.  with "unsubscribe usr-tc" in the body of the message.
  14991.  For information on digests or retrieving files and old messages send
  14992.  "help" to the same address.  Do not use quotes in your message.
  14993.  
  14994.  
  14995. -------------------------------------------------------------------------------
  14996.  
  14997. From: "Stainforth, Matthew (Sys Mgr - BrunNet)"
  14998. Subject: RE: (usr-tc) V5.0 Securit
  14999. Date: 13 Mar 1999 21:48:21 -0400
  15000.  
  15001.  
  15002. I use a different radius authentication and accounting package, Steel Belted
  15003. Radius v2.1 for NT and have been using its concurrent logon tracking for a
  15004. while now without too many problems.  Most users are flawlessly removed from
  15005. the list no problem.  I've never seen a problem with the HARCs in the same
  15006. office and same lan as the authentication box but have noticed an occasional
  15007. missed STOP from a remote POP.  The number of dropped STOPs don't seem to
  15008. differ from NETServer to HARC (there's one of each at the remote POP).  I'm
  15009. actually surprised it works as well as it does given that the remote POP is
  15010. roughly 14 router hops away (another wretched story altogether).
  15011.  
  15012. I did evaluate the 3Com S&A server and it left a bad taste in my mouth so I
  15013. continued on with Steel Belted.  It can apparently use an ODBC database for
  15014. authentication and accounting but I haven't attempted that yet.  Service has
  15015. been exceptional so far.  Any questions I've sent to them via email have
  15016. been answered quite competently within 24 hours - usually if I send them
  15017. email in the morning I will have an answer in the afternoon.  They have also
  15018. partnered with other developers who make billing packages in order to insure
  15019. compatibility in that area.
  15020.  
  15021. No, I don't sell the stuff, I just really like the product. :-)
  15022.  
  15023. -----Original Message-----
  15024. Sent: 3/12/99 6:51 PM
  15025.  
  15026.  
  15027.  
  15028.  
  15029.  
  15030. As long as you don't run it as a service you won't be faced with the cpu
  15031.  
  15032. problem.  I put it in the startup group and it works fine.  Concurrency 
  15033. checking, that's another issue/problem.  I honestly believe it's i the 
  15034. HiPerArc because they had it fixed once but since the accounting record 
  15035. changes that were added around the 4.1 code, it's never worked since.  
  15036. As was mentioned, it will miss stop records and then folks will try to 
  15037. reauthenticate and poof, it thinks they are logged in.  Makes for some 
  15038. nasty tech support phone calls.  It's #1 on my wish list for them to fix
  15039.  
  15040. (aside from being able to port the backend to an SQL type of server).
  15041.  
  15042. Jeff Binkley
  15043. ASA Network Computing
  15044.  
  15045.  
  15046. u>I would also recommend staying away.  Use Emerald or Cistron or
  15047. u>something else.  3Com claims the 100% cpu thing is a MS bug
  15048. u>(surprised?) and i somewhat believe them because the machine we ran it
  15049. u>on did  not behave like it was stressed.  also i you look at the you
  15050. u>look at  the password in the access database will notice the
  15051. u>"encryption" is nothing more than a constant added to the ASCII value
  15052. u>of the  character in the password.  i may be totally ignorant on this
  15053. u>type  of encryption but it looks like you only need your Cap'n Crunch
  15054. u>decoder ring, the access file, half a brain and your in!  when we
  15055. u>realized this we turned white with fear.  IOW stay away from 3com's SA
  15056. u>server.  we went with emerald a while ago and although there is a bit
  15057. u>of a learning curve it was well worth it.  contact me privately if you
  15058. u>want more reasons to stay away.
  15059.  
  15060. u>blake
  15061.  
  15062.  
  15063. u> 
  15064.  
  15065.  
  15066. u>> -----Original Message-----
  15067. u>> From: Tony Loosle [mailto:tony@tcsourceone.com]
  15068. u>> Sent: Friday, March 12, 1999 12:01 PM
  15069. u>> To: usr-tc@lists.xmission.com
  15070. u>> Subject: Re: (usr-tc) V5.0 Security and Accounting Radius Server
  15071. u>> Software
  15072.  
  15073.  
  15074. u>> stay away from it at ALL costs.  stay far away!!
  15075.  
  15076. u>> they acutally have a version 6.??, but it's full of bugs, 
  15077. u>> use's access, run's your cpu to 100% all the time.  You can't 
  15078. u>> use port restrictions in every other version, it forgets who 
  15079. u>> is logged in, then won't log them out and won't let them back in.
  15080.  
  15081. u>> There is of couse NO support whatsoever from USR!
  15082.  
  15083. u>> tony
  15084.  
  15085.  
  15086. u>> Marlo Montanaro wrote:
  15087.  
  15088. u>> > Does anyone know where I can find detailed information on 
  15089. u>> 3COM V5.0 Security and Accounting Radius Server Software for 
  15090. u>> Windows NT?
  15091. u>> >
  15092. u>> > I've searched the 3COM website and can't seem to locate 
  15093. u>> anything other than the basic "this is what it is" product 
  15094. u>> info.  I would like to find part numbers, detailed specs, 
  15095. u>> pricing info, etc. and there are no links to more detailed 
  15096. u>> information.
  15097. u>> >
  15098. u>> > Also, I would like comments from anyone using this 
  15099. u>> software- how easy is it to install and configure, etc.?
  15100. u>> >
  15101. u>> > Thanks!
  15102.  
  15103. u>> > Regards...
  15104. u>> > Marlo Montanaro
  15105.  
  15106. u>> > -
  15107. u>> >  To unsubscribe to usr-tc, send an email to
  15108. u>> >  "majordomo@xmission.com" with "unsubscribe usr-tc" in the body of
  15109. u>> >  the message. For information on digests or retrieving files and
  15110. u>> old  messages send
  15111. u>> >  "help" to the same address.  Do not use quotes in your message.
  15112.  
  15113.  
  15114. u>> -
  15115. u>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15116. u>>  with "unsubscribe usr-tc" in the body of the message.
  15117. u>>  For information on digests or retrieving files and old messages
  15118. u>>  send "help" to the same address.  Do not use quotes in your
  15119. u>> message. 
  15120.  
  15121.  
  15122. u>-
  15123. u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15124. u> with "unsubscribe usr-tc" in the body of the message.
  15125. u> For information on digests or retrieving files and old messages send
  15126. u> "help" to the same address.  Do not use quotes in your message.
  15127.  
  15128. CMPQwk 1.42-21 9999
  15129.  
  15130.  
  15131. -
  15132.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15133.  with "unsubscribe usr-tc" in the body of the message.
  15134.  For information on digests or retrieving files and old messages send
  15135.  "help" to the same address.  Do not use quotes in your message.
  15136.  
  15137. -
  15138.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15139.  with "unsubscribe usr-tc" in the body of the message.
  15140.  For information on digests or retrieving files and old messages send
  15141.  "help" to the same address.  Do not use quotes in your message.
  15142.  
  15143.  
  15144. -------------------------------------------------------------------------------
  15145.  
  15146. From: Mike Andrews <mandrews@termfrost.org>
  15147. Subject: Re: (usr-tc) odd problem
  15148. Date: 13 Mar 1999 22:47:45 -0500 (EST)
  15149.  
  15150. On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  15151.  
  15152. > Thus spake Tatai SV Krishnan
  15153. > >On Fri, 12 Mar 1999 vanhalen@coredcs.com wrote:
  15154. > >> What version of the codes are you running on the ARC, DSP's and Quads?
  15155. > >> 
  15156. > >> Also can anyone else confirm that we're _not_ supposed to be shooting the
  15157. > >> MTU value in radius?
  15158. > >> 
  15159. > 
  15160. > >This has nothing to do with HiPer arc code or DSP or Quad code.  For all 
  15161. > >HiPer arcs you either set the MTU to 1500 or do not set any value.  
  15162. > >Setting the MTU to a lower value other than 1500 will cause users unable 
  15163. > >to browse certain websites.
  15164. > 
  15165. > Boy is *that* an oversimplification of the situation.  Care to expound
  15166. > on *why* this occurs?  Are we talking about broken path mtu discovery
  15167. > here or what?  if so, where is it broken?  if not, what else is causing
  15168. > this?
  15169.  
  15170. Broken MTU path discovery.  Lots of people are now starting to block *ALL*
  15171. ICMP at their routers, because of security paranoia.  MTU Path Discovery
  15172. needs ICMP of course...  so, if your MTU is less than 1500, you lose if
  15173. you try to browse a web site behind such a paranoid router.
  15174.  
  15175. This isn't a 3com problem at all.  This is a much-too-paranoid network
  15176. admin problem.
  15177.  
  15178. I had this happen at home, using a combo of Ascend and Cisco stuff (no
  15179. 3com hardware anywhere) that cut the MTU down to 1460 for a while (because
  15180. we were tunneling IP in IP for a while).  You'd be surprised how many
  15181. major web sites block all ICMP...  Altavista was one... maybe still is.
  15182. Sun was another.
  15183.  
  15184.  
  15185.  
  15186. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  15187. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  15188. getting beaten by the police, put down the video camera and come help me!"
  15189.  
  15190.  
  15191. -
  15192.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15193.  with "unsubscribe usr-tc" in the body of the message.
  15194.  For information on digests or retrieving files and old messages send
  15195.  "help" to the same address.  Do not use quotes in your message.
  15196.  
  15197.  
  15198. -------------------------------------------------------------------------------
  15199.  
  15200. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  15201. Subject: Re: (usr-tc) odd problem
  15202. Date: 13 Mar 1999 22:17:16 -0600 (CST)
  15203.  
  15204. > Thus spake Dan Hollis
  15205. > >On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  15206. > >> Boy is *that* an oversimplification of the situation.  Care to expound
  15207. > >> on *why* this occurs?  Are we talking about broken path mtu discovery
  15208. > >> here or what?  if so, where is it broken?  if not, what else is causing
  15209. > >> this?
  15210. > 
  15211. > >WebTV's proxy servers have broken path mtu (theyre running an old version
  15212. > >of solaris and refuse to upgrade it) so if you lower the mtu then WebTV
  15213. > >users break.
  15214. > 
  15215. > Well, that's assuming you even *CAN* lower the MTU.
  15216. > 
  15217. > FWIW...I did some experimenting this afternoon.
  15218. > 
  15219. > Only place I found to set the MTU on the Arc is:
  15220. > set network user default Mtu <x>
  15221. > 
  15222. > Apparently, 3Com, in their infinite wisdom, decided not to even look at
  15223. > the default user settings until the RADIUS Access-Accept packet is
  15224. > received.
  15225.  
  15226. The default user is a template - if the options are not sent by radius 
  15227. then this template is applied.
  15228.  
  15229. > 
  15230. > What does this mean?  Well, if you're using PPP based authentication
  15231. > (like PAP, CHAP, whatever) it means you can't set the MTU for your PPP
  15232. > links on your Arc *at all*.  Since the default user values aren't looked
  15233. > at until the RADIUS Access-Accept packet is received, the MTU and MRU
  15234. > have already been set during LCP, and the Arc refuses to revisit that
  15235. > subject in any way...even if it doesn't require restarting LCP.
  15236. > 
  15237. > So, the *only* way I've found to set the MTU, and this won't work for
  15238. > us, is to use a text based login, so the Access-Accept is returned
  15239. > before PPP is even started up so the value can be used (either from the
  15240. > default user, or from the RADIUS server) during LCP initially.
  15241. > 
  15242. No you can change the default user setup or use radius - then again make 
  15243. sure that you have your clients also change their mru. 
  15244.  
  15245. krish
  15246.  
  15247. > Come on 3Com, this stuff isn't exactly rocket science here.  How about
  15248. > using a little bit of thought in how you do things?
  15249.  
  15250. > -- 
  15251. > Jeff McAdams                            Email: jeffm@iglou.com
  15252. > Head Network Administrator              Voice: (502) 966-3848
  15253. > IgLou Internet Services                        (800) 436-4456
  15254. > 
  15255. > -
  15256. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15257. >  with "unsubscribe usr-tc" in the body of the message.
  15258. >  For information on digests or retrieving files and old messages send
  15259. >  "help" to the same address.  Do not use quotes in your message.
  15260. > 
  15261.  
  15262. -
  15263.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15264.  with "unsubscribe usr-tc" in the body of the message.
  15265.  For information on digests or retrieving files and old messages send
  15266.  "help" to the same address.  Do not use quotes in your message.
  15267.  
  15268.  
  15269. -------------------------------------------------------------------------------
  15270.  
  15271. From: Jeff Mcadams <jeffm@iglou.com>
  15272. Subject: Re: (usr-tc) odd problem
  15273. Date: 14 Mar 1999 00:34:34 -0500 (EST)
  15274.  
  15275. Thus spake Tatai SV Krishnan
  15276. >> Only place I found to set the MTU on the Arc is:
  15277. >> set network user default Mtu <x>
  15278.  
  15279. >No you can change the default user setup or use radius - then again make 
  15280. >sure that you have your clients also change their mru. 
  15281.  
  15282. Well, all I know is that I did the set network user default mtu 576,
  15283. save all, mon ppp, and monitored the next ppp session that started up
  15284. (we don't do any text based logins at all), and the very first conf req
  15285. that went out had an MRU value of 1514.  I could find no way to
  15286. effectively change the MTU/MRU values of the link from the Arc side.
  15287.  
  15288. If the default user value is supposed to be used for this, then
  15289. something is broken and a bug report needs to be filed, if this value
  15290. isn't supposed to be used for this, then I guess a rfe should be filed
  15291. asking for an effective way to do this.  BTW, I'm using 4.1.59-2.
  15292.  
  15293. Also, changing the MTU/MRU value on the client side should *not* be
  15294. necessary.  Changing it on the client side avoids a conf-nak
  15295. theoretically, but that's about it wins you, and that's assuming there
  15296. aren't other values that have to be 'naked anyway.  That's the nice thing 
  15297. about PPP negotiation.
  15298. -- 
  15299. Jeff McAdams                            Email: jeffm@iglou.com
  15300. Head Network Administrator              Voice: (502) 966-3848
  15301. IgLou Internet Services                        (800) 436-4456
  15302.  
  15303. -
  15304.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15305.  with "unsubscribe usr-tc" in the body of the message.
  15306.  For information on digests or retrieving files and old messages send
  15307.  "help" to the same address.  Do not use quotes in your message.
  15308.  
  15309.  
  15310. -------------------------------------------------------------------------------
  15311.  
  15312. From: Jeff Mcadams <jeffm@iglou.com>
  15313. Subject: Re: (usr-tc) odd problem
  15314. Date: 14 Mar 1999 01:01:38 -0500 (EST)
  15315.  
  15316. Thus spake Tatai SV Krishnan
  15317. >On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  15318. >> I'm *more* concerned about MTU's smaller than 1500.  I would also be
  15319. >> concerned if an MTU bigger than what was negotiated in LCP was received
  15320. >> and used during PAP...that would be broken as well...but I doubt that's
  15321. >> happening.
  15322.  
  15323. >Well you first have to make sure that your client is happy with this.  
  15324.  
  15325. Well, that's what PPP negotiation is for.  :)
  15326.  
  15327. >The client PC should understand this MRU also - You have to go and change 
  15328. >the setup on win95/98 in the registry for proper functioning.  
  15329.  
  15330. Win95/98 brokeness is another thread entirely, and potentially quite a
  15331. long one, but that's irrelevant to what we're talking about here.
  15332.  
  15333. >If you are 
  15334. >doing PAP or CHAP - No clear text login then there are quite a few LCP 
  15335. >options that are negotiated.  
  15336.  
  15337. I agree...another is MRRU if using MP, which is just as significant really.
  15338.  
  15339. >The lcp options chage the framing level 
  15340. >details and also imply changes in authentication methods etc.
  15341.  
  15342. Yeah, I'm aware of that.  I've never seen PAP have trouble fitting into
  15343. the MRU, though, so that's really not significant to this particular
  15344. issue.
  15345.  
  15346. >The option 1 in lcp is your mru- which would be your mtu on the other 
  15347. >side. 
  15348.  
  15349. Not necessarily.  Your MTU does not *have* to be the same as the
  15350. remote's MRU, or even MRRU.  Meaning, if the MTU value received during
  15351. PAP is smaller than that negotiated during LCP, it could still be used
  15352. without any other changes being made.
  15353.  
  15354. >MRU negotiated should be atleast as large as the largest 
  15355. >negotiation message or the user datagram sent.  If MRU is small it may 
  15356. >need to be altered.  To send a confiure nak for this option may seem 
  15357. >illogical unless the message itself is corrupted.  
  15358.  
  15359. If the message is corrupted because the peer can't handle LCP packets up
  15360. to at least 1500, then *they* are broken by the RFC, but that's not
  15361. really relevant here.  Again, I'm aware of the details of the PPP
  15362. negotiation process and the implications of MRU/MTU settings, and the
  15363. requirements that the RFC's (most significantly 1661 here, though 1990
  15364. plays in on MP links).
  15365.  
  15366. >So make sure that your client understands this.  
  15367.  
  15368. This isn't an issue of a single client here.
  15369.  
  15370. >As far as the value of 
  15371. >the default user itself is considered., yes you can change it - changing 
  15372. >it does apply this templte to the users who do ppp via chap/pap staring 
  15373. >lcp options - unless radius specifies the same.  
  15374.  
  15375. Ack...just went back to make sure I wasn't going crazy on looking at
  15376. this...I was.  *sheepish grin*
  15377.  
  15378. I guess my excuse is that I'm not fully used to the Arc interface yet as
  15379. I'm not sure what I was looking at earlier today, but the MTU (even
  15380. gotten from RADIUS) was actually used on the link.
  15381.  
  15382. Can I at least get away with complaining that this information isn't all
  15383. available in the same place?  I think earlier I only did show ppp on int
  15384. slot:1/mod:10, which shows local and remote MRU's (and MRRU's), but the
  15385. MTU isn't available there, only in show connection slot:1/mod:10.  It
  15386. would be nice to have all these values in one place.
  15387.  
  15388. My apologies, and my previous messages were not all correct then.  I
  15389. haven't gone back and checked that the default user MTU settings are
  15390. applied, but I would assume they would be, since the RADIUS value is
  15391. used as well.
  15392.  
  15393. >Also you will need all 
  15394. >the routers in any path to be able to send proper ICMP info to make sure 
  15395. >that the NAS/Client can change this value based on the path discovery.
  15396.  
  15397. Yeah, broken pmtud is another question entirely and not one that I'm
  15398. faulting 3Com for.
  15399.  
  15400. >So the answer to your question is the default user is set at 1514 - you 
  15401. >can set it to 1500 or lower, but make sure the routers in all your path 
  15402. >support icmp and that no one blocks such icmp info - And also tell all 
  15403. >the clients to change their MRU.
  15404.  
  15405. OK, that's really the answer I was *hoping* for, and it seems to be on
  15406. track with what the arcs are doing (pardon me for not taking answers
  15407. received from tech support at face value, but I've been told wrong info
  15408. from tech support, and not just 3Com's, too many times to do that).
  15409.  
  15410. Again, my apologies for looking at the wrong values, but it really would
  15411. be nice if all of that information was available in the same location
  15412. rather than having to look at 8 different screens (an exaggeration, but
  15413. not much).
  15414. -- 
  15415. Jeff McAdams                            Email: jeffm@iglou.com
  15416. Head Network Administrator              Voice: (502) 966-3848
  15417. IgLou Internet Services                        (800) 436-4456
  15418.  
  15419. -
  15420.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15421.  with "unsubscribe usr-tc" in the body of the message.
  15422.  For information on digests or retrieving files and old messages send
  15423.  "help" to the same address.  Do not use quotes in your message.
  15424.  
  15425.  
  15426. -------------------------------------------------------------------------------
  15427.  
  15428. From: Ricky Beam <jfbeam@beaker.interpath.net>
  15429. Subject: Re: (usr-tc) Seimens in talks to buy 3Com Unit
  15430. Date: 14 Mar 1999 03:29:11 -0500 (EST)
  15431.  
  15432. On Sat, 13 Mar 1999, MegaZone wrote:
  15433. >Once upon a time Ricky Beam shaped the electrons to say...
  15434. >>Seimens is the ones who payed for the development of VoIP in the TC.
  15435. >>(Maybe I want to move to Chicago after all :-))
  15436. >
  15437. >Not if what I heard from a number of people at ISPF is true, that there is
  15438. >heavy downsizing in Chicago.
  15439.  
  15440. Look back through the list... the Seimens VoIP stuff was done a year ago???
  15441.  
  15442. I'd love to get my hands on the low-level interface specs within the TC
  15443. chassis itself.  There are so many brilliant things that _could_ be done with
  15444. that platform if someone would just write it.  (well, write it *effeciently*)
  15445.  
  15446. --Ricky
  15447.  
  15448.  
  15449.  
  15450. -
  15451.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15452.  with "unsubscribe usr-tc" in the body of the message.
  15453.  For information on digests or retrieving files and old messages send
  15454.  "help" to the same address.  Do not use quotes in your message.
  15455.  
  15456.  
  15457. -------------------------------------------------------------------------------
  15458.  
  15459. From: Ricky Beam <jfbeam@beaker.interpath.net>
  15460. Subject: Re: (usr-tc) odd problem
  15461. Date: 14 Mar 1999 03:46:52 -0500 (EST)
  15462.  
  15463. On Sat, 13 Mar 1999, Mike Andrews wrote:
  15464. >On Sat, 13 Mar 1999, Jeff Mcadams wrote:
  15465. >> Boy is *that* an oversimplification of the situation.  Care to expound
  15466. >> on *why* this occurs?  Are we talking about broken path mtu discovery
  15467. >> here or what?  if so, where is it broken?  if not, what else is causing
  15468. >> this?
  15469. >
  15470. >Broken MTU path discovery.  Lots of people are now starting to block *ALL*
  15471. >ICMP at their routers, because of security paranoia.  MTU Path Discovery
  15472. >needs ICMP of course...  so, if your MTU is less than 1500, you lose if
  15473. >you try to browse a web site behind such a paranoid router.
  15474. >
  15475. >This isn't a 3com problem at all.  This is a much-too-paranoid network
  15476. >admin problem.
  15477.  
  15478. I prefer to call it "fucking incompetant stupidity".  Any IP security
  15479. professional should have enough understanding of how TCP/IP works to know damn
  15480. well why ICMP is part of TCP/IP and exactly what the f*** it's there to do.
  15481. There are lots of "bugs" in TCP/IP -- some are expressly unfixed (the RFC
  15482. says, "this is a bug.  do not fix it."; ICMP ain't one of them.
  15483.  
  15484. This kind of stupidity is one of the many stupidities behind me not working
  15485. for Interpath any more.  I've had this kind of discussion with people before
  15486. upon blocking all ICMP into/out of their network -- I make them fully aware of
  15487. how much they are about to break in doing this.  Usually, the ICMP block is
  15488. only a "fast fix" to an attack or something along those lines.  (I once
  15489. "talked" with a network technician -- who now works for Cisco, btw -- for 
  15490. several hours about why blocking all ICMP is A Very Bad Thing (tm))
  15491.  
  15492. I won't waste my time detailing how screwed up an FTP gets when all ICMP is
  15493. block to/from it...
  15494.  
  15495. >I had this happen at home, using a combo of Ascend and Cisco stuff (no
  15496. >3com hardware anywhere) that cut the MTU down to 1460 for a while (because
  15497. >we were tunneling IP in IP for a while).  You'd be surprised how many
  15498. >major web sites block all ICMP...  Altavista was one... maybe still is.
  15499. >Sun was another.
  15500.  
  15501. Actually, I'm not...  I'd guess the problem with Sun was problems wrt PMTU.
  15502.  
  15503. --Ricky
  15504.  
  15505.  
  15506.  
  15507. -
  15508.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15509.  with "unsubscribe usr-tc" in the body of the message.
  15510.  For information on digests or retrieving files and old messages send
  15511.  "help" to the same address.  Do not use quotes in your message.
  15512.  
  15513.  
  15514. -------------------------------------------------------------------------------
  15515.  
  15516. From: Stephen Amadei <amadei@dandy.net>
  15517. Subject: (usr-tc) DSP 1.2.46?
  15518. Date: 14 Mar 1999 09:23:40 -0500 (EST)
  15519.  
  15520.  
  15521. While perusing the documents on the Totalservice website, I noticed
  15522. a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be
  15523. newer than the 1.2.59 I am currently using.  Is 1.2.46 a good release?
  15524. I looked all over the place for it, but couldn't find it... anybody know
  15525. where it is?
  15526.  
  15527.                     ----Steve
  15528. Stephen Amadei
  15529. Director of MIS
  15530. Dandy Connections, Inc.
  15531. Atlantic City, NJ
  15532.  
  15533.  
  15534. -
  15535.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15536.  with "unsubscribe usr-tc" in the body of the message.
  15537.  For information on digests or retrieving files and old messages send
  15538.  "help" to the same address.  Do not use quotes in your message.
  15539.  
  15540.  
  15541. -------------------------------------------------------------------------------
  15542.  
  15543. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  15544. Subject: Re: (usr-tc) DSP 1.2.46?
  15545. Date: 14 Mar 1999 09:33:12 -0600 (CST)
  15546.  
  15547. On Sun, 14 Mar 1999, Stephen Amadei wrote:
  15548.  
  15549. > 
  15550. > While perusing the documents on the Totalservice website, I noticed
  15551. > a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be
  15552. > newer than the 1.2.59 I am currently using.  Is 1.2.46 a good release?
  15553. > I looked all over the place for it, but couldn't find it... anybody know
  15554. > where it is?
  15555.  
  15556. 1.2.46 is a Engineering Release code.  This code is not a general/service 
  15557. release code.  To get this  code you would have to call support, and if 
  15558. this code would resolve your problem - you can get the same.
  15559.  
  15560. regards
  15561.  
  15562. krish
  15563.  
  15564. > 
  15565. >                     ----Steve
  15566. > Stephen Amadei
  15567. > Director of MIS
  15568. > Dandy Connections, Inc.
  15569. > Atlantic City, NJ
  15570. > 
  15571. > 
  15572. > -
  15573. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15574. >  with "unsubscribe usr-tc" in the body of the message.
  15575. >  For information on digests or retrieving files and old messages send
  15576. >  "help" to the same address.  Do not use quotes in your message.
  15577. > 
  15578.  
  15579. -
  15580.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15581.  with "unsubscribe usr-tc" in the body of the message.
  15582.  For information on digests or retrieving files and old messages send
  15583.  "help" to the same address.  Do not use quotes in your message.
  15584.  
  15585.  
  15586. -------------------------------------------------------------------------------
  15587.  
  15588. From: "Jamie Orzechowski" <mhz@ripnet.com>
  15589. Subject: Re: (usr-tc) DSP 1.2.46?
  15590. Date: 14 Mar 1999 10:36:21 -0500
  15591.  
  15592. does 1.2.46 resolve Windows 3.1 users (trumpet winsock 2.0) ... or Acer Open
  15593. peoople? or Rockwell v.90 people?? if so I would like a copy of the code so
  15594. I can try it ...
  15595.  
  15596. We have a terrible problem with Acer Open and rockwell v.90's ... AcerOpen's
  15597. will not even connect and everyone knows about the rockwell's ... I send
  15598. these users to quad modems and they have no problems ...
  15599.  
  15600. -----Original Message-----
  15601. Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  15602.  
  15603.  
  15604. >On Sun, 14 Mar 1999, Stephen Amadei wrote:
  15605. >
  15606. >>
  15607. >> While perusing the documents on the Totalservice website, I noticed
  15608. >> a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be
  15609. >> newer than the 1.2.59 I am currently using.  Is 1.2.46 a good release?
  15610. >> I looked all over the place for it, but couldn't find it... anybody know
  15611. >> where it is?
  15612. >
  15613. >1.2.46 is a Engineering Release code.  This code is not a general/service
  15614. >release code.  To get this  code you would have to call support, and if
  15615. >this code would resolve your problem - you can get the same.
  15616. >
  15617. >regards
  15618. >
  15619. >krish
  15620. >
  15621. >>
  15622. >> ----Steve
  15623. >> Stephen Amadei
  15624. >> Director of MIS
  15625. >> Dandy Connections, Inc.
  15626. >> Atlantic City, NJ
  15627. >>
  15628. >>
  15629. >> -
  15630. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15631. >>  with "unsubscribe usr-tc" in the body of the message.
  15632. >>  For information on digests or retrieving files and old messages send
  15633. >>  "help" to the same address.  Do not use quotes in your message.
  15634. >>
  15635. >
  15636. >-
  15637. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15638. > with "unsubscribe usr-tc" in the body of the message.
  15639. > For information on digests or retrieving files and old messages send
  15640. > "help" to the same address.  Do not use quotes in your message.
  15641. >
  15642. >
  15643.  
  15644.  
  15645. -
  15646.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15647.  with "unsubscribe usr-tc" in the body of the message.
  15648.  For information on digests or retrieving files and old messages send
  15649.  "help" to the same address.  Do not use quotes in your message.
  15650.  
  15651.  
  15652. -------------------------------------------------------------------------------
  15653.  
  15654. From: <vanhalen@coredcs.com>
  15655. Subject: Re: (usr-tc) DSP 1.2.46?
  15656. Date: 14 Mar 1999 10:15:17 -0600 (CST)
  15657.  
  15658. Is this the new code that will allow us to get the session stats from the
  15659. console too?  Or is that still in the future.
  15660.  
  15661. Thanks,
  15662. Steve
  15663. On Sun, 14 Mar 1999, Jamie Orzechowski wrote:
  15664.  
  15665. > does 1.2.46 resolve Windows 3.1 users (trumpet winsock 2.0) ... or Acer Open
  15666. > peoople? or Rockwell v.90 people?? if so I would like a copy of the code so
  15667. > I can try it ...
  15668. > 
  15669. > We have a terrible problem with Acer Open and rockwell v.90's ... AcerOpen's
  15670. > will not even connect and everyone knows about the rockwell's ... I send
  15671. > these users to quad modems and they have no problems ...
  15672. > 
  15673. > -----Original Message-----
  15674. > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  15675. > To: Stephen Amadei <amadei@dandy.net>
  15676. > Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  15677. > Date: Sunday, March 14, 1999 10:21 AM
  15678. > Subject: Re: (usr-tc) DSP 1.2.46?
  15679. > 
  15680. > 
  15681. > >On Sun, 14 Mar 1999, Stephen Amadei wrote:
  15682. > >
  15683. > >>
  15684. > >> While perusing the documents on the Totalservice website, I noticed
  15685. > >> a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be
  15686. > >> newer than the 1.2.59 I am currently using.  Is 1.2.46 a good release?
  15687. > >> I looked all over the place for it, but couldn't find it... anybody know
  15688. > >> where it is?
  15689. > >
  15690. > >1.2.46 is a Engineering Release code.  This code is not a general/service
  15691. > >release code.  To get this  code you would have to call support, and if
  15692. > >this code would resolve your problem - you can get the same.
  15693. > >
  15694. > >regards
  15695. > >
  15696. > >krish
  15697. > >
  15698. > >>
  15699. > >> ----Steve
  15700. > >> Stephen Amadei
  15701. > >> Director of MIS
  15702. > >> Dandy Connections, Inc.
  15703. > >> Atlantic City, NJ
  15704. > >>
  15705. > >>
  15706. > >> -
  15707. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15708. > >>  with "unsubscribe usr-tc" in the body of the message.
  15709. > >>  For information on digests or retrieving files and old messages send
  15710. > >>  "help" to the same address.  Do not use quotes in your message.
  15711. > >>
  15712. > >
  15713. > >-
  15714. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15715. > > with "unsubscribe usr-tc" in the body of the message.
  15716. > > For information on digests or retrieving files and old messages send
  15717. > > "help" to the same address.  Do not use quotes in your message.
  15718. > >
  15719. > >
  15720. > 
  15721. > 
  15722. > -
  15723. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15724. >  with "unsubscribe usr-tc" in the body of the message.
  15725. >  For information on digests or retrieving files and old messages send
  15726. >  "help" to the same address.  Do not use quotes in your message.
  15727. > 
  15728.  
  15729.  
  15730. -
  15731.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15732.  with "unsubscribe usr-tc" in the body of the message.
  15733.  For information on digests or retrieving files and old messages send
  15734.  "help" to the same address.  Do not use quotes in your message.
  15735.  
  15736.  
  15737. -------------------------------------------------------------------------------
  15738.  
  15739. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  15740. Subject: Re: (usr-tc) DSP 1.2.46?
  15741. Date: 14 Mar 1999 10:40:56 -0600 (CST)
  15742.  
  15743. On Sun, 14 Mar 1999, Jamie Orzechowski wrote:
  15744.  
  15745. > does 1.2.46 resolve Windows 3.1 users (trumpet winsock 2.0) ... or Acer Open
  15746. > peoople? or Rockwell v.90 people?? if so I would like a copy of the code so
  15747. > I can try it ...
  15748. 1.2.46 does resolve some isses, I am not sure on any fixes to Rockwell in 
  15749. particular - This code has some fixes to v.8 problems.  There are ER that 
  15750. were released after 1.2.46 also.  Again if you open a ticket and have 
  15751. support look at it - they sure could give you this code.
  15752.  
  15753. regards
  15754.  
  15755. krish
  15756.  
  15757. > 
  15758. > We have a terrible problem with Acer Open and rockwell v.90's ... AcerOpen's
  15759. > will not even connect and everyone knows about the rockwell's ... I send
  15760. > these users to quad modems and they have no problems ...
  15761. > 
  15762. > -----Original Message-----
  15763. > From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  15764. > To: Stephen Amadei <amadei@dandy.net>
  15765. > Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  15766. > Date: Sunday, March 14, 1999 10:21 AM
  15767. > Subject: Re: (usr-tc) DSP 1.2.46?
  15768. > 
  15769. > 
  15770. > >On Sun, 14 Mar 1999, Stephen Amadei wrote:
  15771. > >
  15772. > >>
  15773. > >> While perusing the documents on the Totalservice website, I noticed
  15774. > >> a Hiper DSP 1.2.46 service release dated 2/17/99, which seems to me to be
  15775. > >> newer than the 1.2.59 I am currently using.  Is 1.2.46 a good release?
  15776. > >> I looked all over the place for it, but couldn't find it... anybody know
  15777. > >> where it is?
  15778. > >
  15779. > >1.2.46 is a Engineering Release code.  This code is not a general/service
  15780. > >release code.  To get this  code you would have to call support, and if
  15781. > >this code would resolve your problem - you can get the same.
  15782. > >
  15783. > >regards
  15784. > >
  15785. > >krish
  15786. > >
  15787. > >>
  15788. > >> ----Steve
  15789. > >> Stephen Amadei
  15790. > >> Director of MIS
  15791. > >> Dandy Connections, Inc.
  15792. > >> Atlantic City, NJ
  15793. > >>
  15794. > >>
  15795. > >> -
  15796. > >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15797. > >>  with "unsubscribe usr-tc" in the body of the message.
  15798. > >>  For information on digests or retrieving files and old messages send
  15799. > >>  "help" to the same address.  Do not use quotes in your message.
  15800. > >>
  15801. > >
  15802. > >-
  15803. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15804. > > with "unsubscribe usr-tc" in the body of the message.
  15805. > > For information on digests or retrieving files and old messages send
  15806. > > "help" to the same address.  Do not use quotes in your message.
  15807. > >
  15808. > >
  15809. > 
  15810. > 
  15811. > -
  15812. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15813. >  with "unsubscribe usr-tc" in the body of the message.
  15814. >  For information on digests or retrieving files and old messages send
  15815. >  "help" to the same address.  Do not use quotes in your message.
  15816. > 
  15817.  
  15818. -
  15819.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15820.  with "unsubscribe usr-tc" in the body of the message.
  15821.  For information on digests or retrieving files and old messages send
  15822.  "help" to the same address.  Do not use quotes in your message.
  15823.  
  15824.  
  15825. -------------------------------------------------------------------------------
  15826.  
  15827. From: Jeff Mcadams <jeffm@iglou.com>
  15828. Subject: Re: (usr-tc) odd problem
  15829. Date: 14 Mar 1999 11:54:46 -0500 (EST)
  15830.  
  15831. CC:'ing this back to the list since hopefully there will be some
  15832. educational content here.
  15833.  
  15834. Thus spake Tatai SV Krishnan
  15835. >On Sun, 14 Mar 1999, Jeff Mcadams wrote:
  15836. >> I agree...another is MRRU if using MP, which is just as significant really.
  15837. >MRRU - rather MP adds more to it.  For example some SGI implementatioins 
  15838. >if MP will set the MRU on their side to 1505 and if no MP it will set it 
  15839. >or 1500.  This implementation changes from one OS to the other.
  15840.  
  15841. Certainly, it adds EDO and such to the negotiation as well (RFC1990),
  15842. but MRRU is the only one added that really has an impact on what was
  15843. being discussed (MTU/MRU/MRRU)
  15844.  
  15845. >> Not necessarily.  Your MTU does not *have* to be the same as the
  15846. >> remote's MRU, or even MRRU.  Meaning, if the MTU value received during
  15847. >> PAP is smaller than that negotiated during LCP, it could still be used
  15848. >> without any other changes being made.
  15849.  
  15850. >This is where I have to disagree, if you look at the PPP rfc only MRU is 
  15851. >defined.  And based on MRU the other side NAS/Client set up the MTU.  I 
  15852. >may be wrong here  but after going through the RFC this is what I 
  15853. >understand.  I have not looked into our code yet to fingure out what we 
  15854. >do, but I am sure this is what we setup to.  The NAS MTU is actually the 
  15855. >MRU for the client.  Again I may be wrong.
  15856.  
  15857. Indeed, the RFC (1661) only discusses MRU, there's no mention of MTU at
  15858. all.  There is however a comment in there regarding receiving an MRU
  15859. that's higher that the local system needs.  (let me paste the comment in
  15860. here)
  15861.  
  15862.          This option is used to indicate an implementation capability.
  15863.          The peer is not required to maximize the use of the capacity.
  15864.          For example, when a MRU is indicated which is 2048 octets, the
  15865.          peer is not required to send any packet with 2048 octets.  The
  15866.          peer need not Configure-Nak to indicate that it will only send
  15867.          smaller packets, since the implementation will always require
  15868.          support for at least 1500 octets.
  15869.  
  15870. While this doesn't explicitly mention MTU, it certainly seems to
  15871. indicate (and common interpretation I believe supports this) that one
  15872. peers MTU can be set lower than the remote peers MRU, without the remote
  15873. peer needing to be notified.
  15874.  
  15875. >> >So make sure that your client understands this.  
  15876.  
  15877. >> This isn't an issue of a single client here.
  15878.  
  15879. >Well it is - because the MTU on our side should be equal to the MRU on 
  15880. >the client side.
  15881.  
  15882. I was bringing this up as a discussion of the overall behavior of the
  15883. HiPer Arc, we don't have any specific issue with any specific clients.
  15884. Ideally (and this is what I found last night with further
  15885. experimentation that this *is* working), I want to be able to set the
  15886. MTU on our side and have that value be used.  Indeed it is, even coming
  15887. from RADIUS, apparently the HiPer Arc does unilaterally lower its MTU,
  15888. as IMO, it should.  So consider this a message with kudos in it for 3Com
  15889. getting something right.  :)  I have *not* played with setting MTU
  15890. higher in RADIUS than what's negotiated in LCP, so I don't know how it
  15891. behaves in that instance, but I suspect that will happen very rarely, so
  15892. its probably not as big of a problem.
  15893.  
  15894. >> Can I at least get away with complaining that this information isn't all
  15895. >> available in the same place?  I think earlier I only did show ppp on int
  15896. >> slot:1/mod:10, which shows local and remote MRU's (and MRRU's), but the
  15897. >> MTU isn't available there, only in show connection slot:1/mod:10.  It
  15898. >> would be nice to have all these values in one place.
  15899.  
  15900. >Sure - Thats no problem at all.  I have been complaing about this for 
  15901. >atleast a year.  I have even asked our guys to help me out to give me the 
  15902. >snmp values of the cli commands in a list so that we can write a small 
  15903. >app to get these for those people like me.
  15904.  
  15905. I may go in and do just that.  I've done some snmpwalks of what SNMP
  15906. info is available from the HiPer Arc, so I'm vaguely familiar with
  15907. what's there.  Unfortunately, I *suck* at programming, so it will be
  15908. some time before I would be able to have a tool available in any decent
  15909. shape for distribution to anyone else.  If anyone else that is halfway
  15910. decent at programming would like to help out, I'll work out the
  15911. pseudo-code of what needs to be done (and even include output examples
  15912. from the Arc of what would need to be parsed or whatever), so all that
  15913. would really need to be done is take that, and write a perl script or
  15914. whatever that actually does in and implements my pseudo-code.  :)  I
  15915. should be able to have the pseudo-code done (in between other stuff I'm
  15916. working on) by the end of the week.  If anyone wants to take a shot at
  15917. converting my pseudo-code into working code, let me know (of if anyone
  15918. else has done this already let me know so I don't have to reinvent the
  15919. wheel :).  Also, any specific requests for info that should be included
  15920. (certainly MTU, MRU, and MRRU will be included since that's the crux of
  15921. this whole discussion) is welcome.
  15922.  
  15923. >> Yeah, broken pmtud is another question entirely and not one that I'm
  15924. >> faulting 3Com for.
  15925.  
  15926. >pmtud is not completely broken It does work but not in all networks.  
  15927.  
  15928. Indeed, the HiPer Arc handles the ICMP correctly...its just stupid
  15929. network operators that filter out fragmentation needed messages that
  15930. break it.  Plenty of discussion of this has already occured.  Again, 
  15931. that's not 3Com's fault.  :) 
  15932. -- 
  15933. Jeff McAdams                            Email: jeffm@iglou.com
  15934. Head Network Administrator              Voice: (502) 966-3848
  15935. IgLou Internet Services                        (800) 436-4456
  15936.  
  15937. -
  15938.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15939.  with "unsubscribe usr-tc" in the body of the message.
  15940.  For information on digests or retrieving files and old messages send
  15941.  "help" to the same address.  Do not use quotes in your message.
  15942.  
  15943.  
  15944. -------------------------------------------------------------------------------
  15945.  
  15946. From: Charles Sprickman <spork@inch.com>
  15947. Subject: Re: (usr-tc) odd problem
  15948. Date: 14 Mar 1999 12:29:39 -0500 (EST)
  15949.  
  15950. On Sun, 14 Mar 1999, Ricky Beam wrote:
  15951.  
  15952. > I prefer to call it "fucking incompetant stupidity".  Any IP security
  15953. > professional should have enough understanding of how TCP/IP works to know damn
  15954. > well why ICMP is part of TCP/IP and exactly what the f*** it's there to do.
  15955. > There are lots of "bugs" in TCP/IP -- some are expressly unfixed (the RFC
  15956. > says, "this is a bug.  do not fix it."; ICMP ain't one of them.
  15957.  
  15958. Yessir.  The problem is laziness, there are so many sub-types, and people
  15959. just don't know which to block.  I found this post on the ipfilter mailing
  15960. list, and it has a nice list of what does what in the world of icmp.  This
  15961. should apply to other fw products as well.
  15962.  
  15963. Check out http://world.inch.com/info/icmp.html  
  15964.  
  15965. Charles
  15966.  
  15967.  
  15968. -
  15969.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  15970.  with "unsubscribe usr-tc" in the body of the message.
  15971.  For information on digests or retrieving files and old messages send
  15972.  "help" to the same address.  Do not use quotes in your message.
  15973.  
  15974.  
  15975. -------------------------------------------------------------------------------
  15976.  
  15977. From: Mark Lemmert <cto@athenet.net>
  15978. Subject: (usr-tc) Replacing Quads with DSPs
  15979. Date: 15 Mar 1999 05:43:03 -0600 (CST)
  15980.  
  15981. I have a lot of chassis that I upgraded from Netserver to HiperARC
  15982. so they have 12 quad modems in them. 
  15983.  
  15984. I am wondering if I replaced one of the quad modems in a chassis 
  15985. with a DSP if I would run into problems due to there being 46 channels
  15986. coming into the T1/PRI controller card and there being less than 46 quad 
  15987. modems for it to map to? Would the T1/PRI controller card 'busy' those
  15988. channels out in some way so that telco skipped them and placed the calls
  15989. on the next span?
  15990.  
  15991. I'm aware of the quad modem prom going on, but I'm thinking long term
  15992. if I will be able to replace the quads one at a time of it they have to
  15993. go 6 at a time.
  15994.  
  15995.  
  15996.  
  15997. -Mark Lemmert                           AthEnet Data Exchange
  15998. Chief Technical Officer                 888-919-8700
  15999.  
  16000.  
  16001.  
  16002.  
  16003. -
  16004.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16005.  with "unsubscribe usr-tc" in the body of the message.
  16006.  For information on digests or retrieving files and old messages send
  16007.  "help" to the same address.  Do not use quotes in your message.
  16008.  
  16009.  
  16010. -------------------------------------------------------------------------------
  16011.  
  16012. From: Mark Lemmert <cto@athenet.net>
  16013. Subject: (usr-tc) Multiple MPIP Servers
  16014. Date: 15 Mar 1999 05:49:09 -0600 (CST)
  16015.  
  16016. I currently have 7 chassis in one of my POPs and I am
  16017. only running 1 MPIP server. (All HiperARC running 4.1.59 -6
  16018. and 1.2.59)
  16019.  
  16020. This makes it difficult to do a code upgrade on the box
  16021. without multilink connections (over multiple chassis) 
  16022. breaking for the duration of the upgrade so I am considering 
  16023. setting up a second MPIP server.
  16024.  
  16025. I am correct that if I setup a second chassis as a server
  16026. with all 7 clients authorized and I add a second MPIP server
  16027. entry to all chassis with the priority one notch lower that
  16028. the 1st MPIP server configured will be used by default but
  16029. if that chassis goes down the clients will all work off of
  16030. the secondary MPIP server?
  16031.  
  16032. If the above occurs and the primary MPIP server comes back
  16033. online will the bundles setup on the secondary still work?
  16034.  
  16035.  
  16036.  
  16037. -Mark Lemmert                           AthEnet Data Exchange
  16038. Chief Technical Officer                 888-919-8700
  16039.  
  16040.  
  16041.  
  16042.  
  16043. -
  16044.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16045.  with "unsubscribe usr-tc" in the body of the message.
  16046.  For information on digests or retrieving files and old messages send
  16047.  "help" to the same address.  Do not use quotes in your message.
  16048.  
  16049.  
  16050. -------------------------------------------------------------------------------
  16051.  
  16052. From: Jeff Mcadams <jeffm@iglou.com>
  16053. Subject: Re: (usr-tc) Replacing Quads with DSPs
  16054. Date: 15 Mar 1999 07:22:40 -0500 (EST)
  16055.  
  16056. Thus spake Mark Lemmert
  16057. >I am wondering if I replaced one of the quad modems in a chassis 
  16058. >with a DSP if I would run into problems due to there being 46 channels
  16059. >coming into the T1/PRI controller card and there being less than 46 quad 
  16060. >modems for it to map to? Would the T1/PRI controller card 'busy' those
  16061. >channels out in some way so that telco skipped them and placed the calls
  16062. >on the next span?
  16063.  
  16064. It won't auto-busy the channels out, but if you put at least two of the
  16065. channels on the PRI's in localoutofservice, that will do what you need.
  16066. Be sure to save the pri card to nvram so if it gets rebooted, it
  16067. remembers to put those two or more channels localoutofservice.  Oh,
  16068. yeah, and this won't work for NI-2 translation since the people that
  16069. designed that were brain-dead and didn't include any method, like
  16070. service messages, for one side to inform the other to not send calls
  16071. down specific channels.
  16072.  
  16073. >I'm aware of the quad modem prom going on, but I'm thinking long term
  16074. >if I will be able to replace the quads one at a time of it they have to
  16075. >go 6 at a time.
  16076.  
  16077. Well, if you pop a DSP in the chassis and move a PRI from the dual-pri
  16078. card over to it rather than putting a new PRI on it, then you wouldn't
  16079. have to worry about busying out channels.  At that point, you could take
  16080. out 6 of your quad cards and have 5 free slots for further DSP's before
  16081. you had to remove any more quads.
  16082. -- 
  16083. Jeff McAdams                            Email: jeffm@iglou.com
  16084. Head Network Administrator              Voice: (502) 966-3848
  16085. IgLou Internet Services                        (800) 436-4456
  16086.  
  16087. -
  16088.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16089.  with "unsubscribe usr-tc" in the body of the message.
  16090.  For information on digests or retrieving files and old messages send
  16091.  "help" to the same address.  Do not use quotes in your message.
  16092.  
  16093.  
  16094. -------------------------------------------------------------------------------
  16095.  
  16096. From: Jeff Mcadams <jeffm@iglou.com>
  16097. Subject: Re: (usr-tc) Multiple MPIP Servers
  16098. Date: 15 Mar 1999 07:24:43 -0500 (EST)
  16099.  
  16100. Thus spake Mark Lemmert
  16101. >I am correct that if I setup a second chassis as a server
  16102. >with all 7 clients authorized and I add a second MPIP server
  16103. >entry to all chassis with the priority one notch lower that
  16104. >the 1st MPIP server configured will be used by default but
  16105. >if that chassis goes down the clients will all work off of
  16106. >the secondary MPIP server?
  16107.  
  16108. Yes.
  16109.  
  16110. >If the above occurs and the primary MPIP server comes back
  16111. >online will the bundles setup on the secondary still work?
  16112.  
  16113. Yes, if you have multiple MPIP servers and they have each other set up
  16114. as MPIP servers in their own setups, then they will synchronize thier
  16115. information with each other.
  16116.  
  16117. This is a mixed blessing for those of us still dealing with the phantom
  16118. MPIP bundle issue since with multiple MPIP servers, you can't just
  16119. reboot the server and clear out the phantom bundles, you would have to
  16120. reboot both at once.
  16121. -- 
  16122. Jeff McAdams                            Email: jeffm@iglou.com
  16123. Head Network Administrator              Voice: (502) 966-3848
  16124. IgLou Internet Services                        (800) 436-4456
  16125.  
  16126. -
  16127.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16128.  with "unsubscribe usr-tc" in the body of the message.
  16129.  For information on digests or retrieving files and old messages send
  16130.  "help" to the same address.  Do not use quotes in your message.
  16131.  
  16132.  
  16133. -------------------------------------------------------------------------------
  16134.  
  16135. From: Mark Lemmert <cto@athenet.net>
  16136. Subject: (usr-tc) A new Webramp problem
  16137. Date: 15 Mar 1999 09:17:08 -0600 (CST)
  16138.  
  16139. I had been seeing the 'network stall' problem with webramp customers
  16140. where after 10-15 minutes no traffic would go across the link. I put
  16141. on the 4.1.59 -6 code and it fixed it, thanks Kirsh!
  16142.  
  16143. That problem was fixed but a new one arose in it's place. Now when the
  16144. webramp connects the network portions seems to stay intact, however after
  16145. a short period of time I will loose communication on everything but ICMP.
  16146. I.e. no traffic will move across the link on port 80, 25 etc, but pings go
  16147. across just fine (the pings weren't working before I put the 4.1.59 -6 code on).
  16148.  
  16149. It occured to me that this might be a more webramp based problem however I
  16150. can have the webramp connect to a Livingston PM2 /w a BRI card and this problem
  16151. does not occur. 
  16152.  
  16153. Has anybody else seen this?
  16154.  
  16155.  
  16156. -Mark Lemmert                           AthEnet Data Exchange
  16157. Chief Technical Officer                 888-919-8700
  16158.  
  16159.  
  16160.  
  16161.  
  16162. -
  16163.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16164.  with "unsubscribe usr-tc" in the body of the message.
  16165.  For information on digests or retrieving files and old messages send
  16166.  "help" to the same address.  Do not use quotes in your message.
  16167.  
  16168.  
  16169. -------------------------------------------------------------------------------
  16170.  
  16171. From: "Christina Raeber" <Christina_Raeber@mw.3com.com>
  16172. Subject: Re: (usr-tc) Help, upgraded from netserver to hyperarc now lot's
  16173. Date: 15 Mar 1999 10:01:20 -0600
  16174.  
  16175. --0__=HZcjclJuYi4kNQ6IxlGhIr4R58tE66WJMTbbr2aHn6uMub4uWtOeSEIJ
  16176. Content-type: text/plain; charset=us-ascii
  16177. Content-Disposition: inline
  16178.  
  16179.  
  16180.  
  16181. Mike,
  16182.  
  16183. Call us at 888-373-7367 and we'll see if we can help you with this problem.
  16184.  
  16185.  
  16186.  
  16187.  
  16188.  
  16189.  
  16190. "Mike Hamrich" <mhamrich@drfast.net> on 03/09/99 08:37:12 PM
  16191.  
  16192. Please respond to usr-tc@lists.xmission.com
  16193.  
  16194. cc:    (Christina Raeber/MW/US/3Com)
  16195.       disconnects.
  16196.  
  16197.  
  16198.  
  16199.  
  16200. Hi all,
  16201.  
  16202. We just upgraded from Netserver based code relase 2.5.1 to HyperArc release
  16203. 3.3.3 And now we are getting tons of disconnects. Within 30 seconds or less of
  16204. logging on. 90% of the quickly disconnected  users show V42Disconect(42) command
  16205. while 10% show GatewayDisconnect(62) Mostly USR modems Sportsters a few Courier
  16206. and few Sportster Winmodems. ISDN clients work great.
  16207.  
  16208. We have the latest code on the Quads, they were running 5.1.7 now 5.10.9 ,NMC is
  16209. 5.5.5 with the inculded mem upgrade. and the HyperArc is the latest 4.1.59 -6,
  16210. though on chassiy inventory the -6 is missing.
  16211.  
  16212. Before we upgraded we put the PRI's out of service, onhooked offhooked the
  16213. modem's and set all the Quads to "default" then saved to NVRAM and rebooted. Any
  16214. Ideas?
  16215.  
  16216.  
  16217.  
  16218. --0__=HZcjclJuYi4kNQ6IxlGhIr4R58tE66WJMTbbr2aHn6uMub4uWtOeSEIJ
  16219. Content-type: text/html; 
  16220.     name="att1.htm"
  16221. Content-Disposition: attachment; filename="att1.htm"
  16222. Content-transfer-encoding: base64
  16223. Content-Description: Internet HTML
  16224.  
  16225. PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD4N
  16226. CjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PXRleHQvaHRtbDtjaGFyc2V0PWlzby04ODU5LTEgaHR0
  16227. cC1lcXVpdj1Db250ZW50LVR5cGU+DQo8TUVUQSBjb250ZW50PSciTVNIVE1MIDQuNzIuMjEwNi42
  16228. IicgbmFtZT1HRU5FUkFUT1I+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElW
  16229. PjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPkhpIGFsbCw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxG
  16230. T05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg
  16231. c2l6ZT0yPldlIGp1c3QgdXBncmFkZWQgZnJvbSBOZXRzZXJ2ZXIgYmFzZWQgY29kZSByZWxhc2Ug
  16232. Mi41LjEgdG8gDQpIeXBlckFyYyByZWxlYXNlIDMuMy4zIEFuZCBub3cgd2UgYXJlIGdldHRpbmcg
  16233. dG9ucyBvZiBkaXNjb25uZWN0cy4gV2l0aGluIDMwIA0Kc2Vjb25kcyBvciBsZXNzIG9mIGxvZ2dp
  16234. bmcgb24uIDkwJSBvZiB0aGUgcXVpY2tseSBkaXNjb25uZWN0ZWQmbmJzcDsgdXNlcnMgc2hvdyAN
  16235. ClY0MkRpc2NvbmVjdCg0MikgY29tbWFuZCB3aGlsZSAxMCUgc2hvdyBHYXRld2F5RGlzY29ubmVj
  16236. dCg2MikgTW9zdGx5IFVTUiBtb2RlbXMgDQpTcG9ydHN0ZXJzIGEgZmV3IENvdXJpZXIgYW5kIGZl
  16237. dyBTcG9ydHN0ZXIgV2lubW9kZW1zLiBJU0ROIGNsaWVudHMgd29yayANCmdyZWF0LjwvRk9OVD48
  16238. L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQg
  16239. c2l6ZT0yPldlIGhhdmUgdGhlIGxhdGVzdCBjb2RlIG9uIHRoZSBRdWFkcywgdGhleSB3ZXJlIHJ1
  16240. bm5pbmcgNS4xLjcgDQpub3cgNS4xMC45ICxOTUMgaXMgNS41LjUgd2l0aCB0aGUgaW5jdWxkZWQg
  16241. bWVtIHVwZ3JhZGUuIGFuZCB0aGUgSHlwZXJBcmMgaXMgdGhlIA0KbGF0ZXN0IDQuMS41OSAtNiwg
  16242. dGhvdWdoIG9uIGNoYXNzaXkgaW52ZW50b3J5IHRoZSAtNiBpcyBtaXNzaW5nLjwvRk9OVD48L0RJ
  16243. Vj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGNvbG9yPSMwMDAwMDAgc2l6ZT0yPkJl
  16244. Zm9yZSB3ZSB1cGdyYWRlZCB3ZSBwdXQgdGhlIFBSSSdzIG91dCBvZiANCnNlcnZpY2UsIG9uaG9v
  16245. a2VkIG9mZmhvb2tlZCB0aGUgbW9kZW0ncyBhbmQgc2V0IGFsbCB0aGUgUXVhZHMgdG8gDQomcXVv
  16246. dDtkZWZhdWx0JnF1b3Q7IHRoZW4gc2F2ZWQgdG8gTlZSQU0gYW5kIHJlYm9vdGVkLiBBbnkgSWRl
  16247. YXM/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDAwIHNpemU9Mj48L0ZPTlQ+
  16248. Jm5ic3A7PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvQk9EWT48L0hUTUw+DQo=
  16249.  
  16250. --0__=HZcjclJuYi4kNQ6IxlGhIr4R58tE66WJMTbbr2aHn6uMub4uWtOeSEIJ--
  16251.  
  16252.  
  16253. -
  16254.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16255.  with "unsubscribe usr-tc" in the body of the message.
  16256.  For information on digests or retrieving files and old messages send
  16257.  "help" to the same address.  Do not use quotes in your message.
  16258.  
  16259.  
  16260. -------------------------------------------------------------------------------
  16261.  
  16262. From: Chris Hanes <chris@internetcreations.com>
  16263. Subject: (usr-tc) Radius Server Recommendations??
  16264. Date: 15 Mar 1999 14:26:53 -0500
  16265.  
  16266. As has been noted here before, the USR Radius server scarcely works.
  16267. I've been looking at alternatives - in particular Cistron, Merit, and
  16268. Radiator - and am looking for advice.  What's the best bet in terms of
  16269. cost, performance, reliability, ease of maintenance, etc.?
  16270.  
  16271. Thanks,
  16272. Chris Hanes
  16273.  
  16274.  
  16275. -
  16276.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16277.  with "unsubscribe usr-tc" in the body of the message.
  16278.  For information on digests or retrieving files and old messages send
  16279.  "help" to the same address.  Do not use quotes in your message.
  16280.  
  16281.  
  16282. -------------------------------------------------------------------------------
  16283.  
  16284. From: Charles Sprickman <spork@inch.com>
  16285. Subject: (usr-tc) "unauthenticated" users + drops
  16286. Date: 15 Mar 1999 15:17:06 -0500 (EST)
  16287.  
  16288. All of a sudden we're getting many immediate disconnect requests.  The
  16289. only odd thing I noticed was that my logfile has alot (??) of
  16290. "unauthenticated" requests.
  16291.  
  16292. Does this mean anything?  Looking at this about 10% of calls fall into
  16293. this class...
  16294.  
  16295. root@util[/usr/local/etc/radius/db-analog]# cat logfile | wc -l
  16296.    18623
  16297. root@util[/usr/local/etc/radius/db-analog]# grep unauth logfile | wc -l
  16298.     1824
  16299.  
  16300. If I go back a few days, there's alot less:
  16301.  
  16302. root@util[/usr/local/etc/radius/db-analog]# zcat logfile.990311.gz | wc -l
  16303.    34528
  16304. root@util[/usr/local/etc/radius/db-analog]# zgrep unauth logfile.990311.gz
  16305. | wc -l    1620                                                   
  16306.  
  16307. Ideas?  What exactly classifies as an "unauthenticated call"?
  16308.  
  16309. Thanks,
  16310.  
  16311. Charles
  16312.  
  16313. -- 
  16314. =-----------------=                                        = 
  16315. | Charles Sprickman                       Internet Channel |
  16316. | INCH System Administration Team         (212)243-5200    |
  16317. | spork@inch.com                          access@inch.com  |
  16318. =                                         =----------------=
  16319.  
  16320.  
  16321. -
  16322.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16323.  with "unsubscribe usr-tc" in the body of the message.
  16324.  For information on digests or retrieving files and old messages send
  16325.  "help" to the same address.  Do not use quotes in your message.
  16326.  
  16327.  
  16328. -------------------------------------------------------------------------------
  16329.  
  16330. From: Ricky Beam <jfbeam@beaker.interpath.net>
  16331. Subject: Re: (usr-tc) Radius Server Recommendations??
  16332. Date: 15 Mar 1999 16:02:25 -0500 (EST)
  16333.  
  16334. On Mon, 15 Mar 1999, Chris Hanes wrote:
  16335. >As has been noted here before, the USR Radius server scarcely works.
  16336. >I've been looking at alternatives - in particular Cistron, Merit, and
  16337. >Radiator - and am looking for advice.  What's the best bet in terms of
  16338. >cost, performance, reliability, ease of maintenance, etc.?
  16339.  
  16340. Yes, people have noted that before.  The USR radius server, as it comes from
  16341. USR, is a very poor excuse for a RADIUS server.  HOWEVER, if you spend some
  16342. time working on replacing the script, the core server part of the system is
  16343. very powerful.  I look at it like buying "perl" and getting some bad "example"
  16344. code with it.
  16345.  
  16346. Chris, et. al., drop me a note directly if you are interested in seeing what
  16347. magic I've done to the script and database schema.  It doesn't take 5k per
  16348. user anymore; you can limit access for ISDN, MLPPP, X2/V.90, and
  16349. analog/digital call enforcement as well as the usual DNIS/ANI/portgroup
  16350. stuff.  As for speed... using SA4.3.11 (143Mhz sparc 10 / solaris 2.5.1) +
  16351. postgres v6.3.2 (dual PII-300 / linux), the system could handle over 30
  16352. authentication requests _per_ _second_.  (Imagine what that would be if I
  16353. were to use Oracle or even flat files.)  (BTW, SA4 will compile and run
  16354. perfectly under linux -- with one small change to the select() handling.)
  16355.  
  16356. I will say this again: The script is designed for SA4.  It can be dropped into
  16357. SA5 with minor modifications.  If will not work for SA6 with extensive
  16358. changes.  And, as hiper hardware didn't exist when I designed the script,
  16359. there is no specific handling for hiper hardware.
  16360.  
  16361. IF there is interest, I can finish work already in progress in updating the
  16362. SA4 script for SA6 (with full hiper support.)
  16363.  
  16364. If I still had access to the source code (and some access hardware), I could
  16365. do some beautiful things to that server... faster client auth checks, true
  16366. duplicate packet handling, full multithreaded processing...
  16367.  
  16368. --Ricky
  16369.  
  16370.  
  16371.  
  16372. -
  16373.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16374.  with "unsubscribe usr-tc" in the body of the message.
  16375.  For information on digests or retrieving files and old messages send
  16376.  "help" to the same address.  Do not use quotes in your message.
  16377.  
  16378.  
  16379. -------------------------------------------------------------------------------
  16380.  
  16381. From: "Randy Cosby" <dcosby@infowest.com>
  16382. Subject: (usr-tc) Switch takes lines out of service
  16383. Date: 15 Mar 1999 14:49:33 -0700
  16384.  
  16385. I have an annoying problem that doesn't seem to be related to my equipment,
  16386. but I hope someone on the list will be able to shed some light.
  16387.  
  16388. When I do anything to my TC boxes that requires me to take down a T1, the
  16389. telco switch takes some of my trunks out of service.  I have to call USWest
  16390. to get them to "release" the trunks again.  I can find no rhyme or reason as
  16391. to which lines get taken out of service.  Sometimes it's just one trunk,
  16392. sometimes a few, sometimes most of a span.
  16393.  
  16394. A few questions:
  16395.  
  16396. 1. Is there a way I can "tell" the switch (Lucent 5ESS) to restore the lines
  16397. through the HDM or T1 card?
  16398. 2. Is there a way USWest can  set up the switch to automatically "poll" our
  16399. equipment on a regular basis after an outage and auto-restore if it's there?
  16400. 3. Can anyone give me any background information on the switches to explain
  16401. why it might be taking trunks out of service?
  16402.  
  16403. No one I've talked to at USWest knows of a way to do #2.  I'm sure there are
  16404. people on this list with more switch knowledge than most of the testers
  16405. have.
  16406.  
  16407. In case this does happen to be equipment related, I am running the latest
  16408. HiperDSP, T1 and Quad releases/ER's, with HiperARCs.
  16409.  
  16410. Thanks,
  16411.  
  16412. Randy Cosby <dcosby@infowest.com>
  16413. Vice President
  16414. InfoWest Global Internet Services, Inc.
  16415. (435)674-0165   http://www.infowest.com
  16416.  
  16417.  
  16418. -
  16419.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16420.  with "unsubscribe usr-tc" in the body of the message.
  16421.  For information on digests or retrieving files and old messages send
  16422.  "help" to the same address.  Do not use quotes in your message.
  16423.  
  16424.  
  16425. -------------------------------------------------------------------------------
  16426.  
  16427. From: Pete Ashdown <pashdown@xmission.com>
  16428. Subject: Re: (usr-tc) "unauthenticated" users + drops
  16429. Date: 15 Mar 1999 14:54:24 -0700 (MST)
  16430.  
  16431. Charles Sprickman said once upon a time:
  16432.  
  16433. >Does this mean anything?  Looking at this about 10% of calls fall into
  16434. >this class...
  16435.  
  16436. No, it is noise from the ARC.
  16437.  
  16438. >Ideas?  What exactly classifies as an "unauthenticated call"?
  16439.  
  16440. Plug this into your configuration:
  16441.  
  16442. set accounting log_UNAUTHENTICATED_CALLS false
  16443.  
  16444. -
  16445.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  16446.  with "unsubscribe usr-tc" in the body of the message.
  16447.  For information on digests or retrieving files and old messages send
  16448.  "help" to the same address.  Do not use quotes in your message.
  16449.  
  16450.  
  16451. -------------------------------------------------------------------------------
  16452.  
  16453. From: MegaZone <megazone@megazone.org>
  16454. Subject: Re: (usr-tc) IEA , using it from Radius
  16455. Date: 13 Mar 1999 16:00:22 -0800 (PST)
  16456.  
  16457. Once upon a time Stephen Amadei shaped the electrons to say...
  16458. >VSA's in my dictionary file, using the complaints RADIUS had when it
  16459. >encountered an unknown attribute.  My dictionary.3com:
  16460. >
  16461. >ATTRIBUTE       Vendor-Specific        26    string
  16462. >ATTRIBUTE    Acct-Multi-Session-ID    50    string
  16463. >ATTRIBUTE    Acct-Link-Count        51    string
  16464.  
  16465. This is the current Cistron 3Com dictionary - I don't know of the OS/2 port
  16466. has the full 3Com VSA support, it was added fairly recently.
  16467.  
  16468. #
  16469. # dictionary.usr    USR Robotics dictionary.
  16470. #
  16471. #        Taken from the dictionary included with the USR RADIUS server,
  16472. #        and adjusted a bit.
  16473. #
  16474. # Version:    @(#)dictionary.usr  1.10  11-Nov-1998  miquels@cistron.nl
  16475. #
  16476.  
  16477. #
  16478. #    USR specific attributes
  16479. #
  16480. # Prompt value should be 1 for echo, 0 for no echo, default 1.
  16481. #ATTRIBUTE    Prompt            64    integer
  16482. ATTRIBUTE    Multi-Link-Flag        126    integer
  16483. ATTRIBUTE    Char-Noecho        250    integer
  16484.  
  16485. #
  16486. #    USR specific Integer Translations
  16487. #
  16488.  
  16489. VALUE        Termination-Action    Manage-Resources    2
  16490.  
  16491. VALUE        Service-Type        Authenticate-User    8
  16492. VALUE        Service-Type        Dialback-NAS-User    9
  16493.  
  16494. VALUE        Acct-Status-Type    Modem-Start        4
  16495. VALUE        Acct-Status-Type    Modem-Stop        5
  16496. VALUE        Acct-Status-Type    Cancel            6
  16497.  
  16498. VALUE        Multi-Link-Flag        True            1
  16499. VALUE        Multi-Link-Flag        False            0
  16500.  
  16501. #    USR specific Authentication Types
  16502.  
  16503. VALUE        Acct-Authentic        None            0
  16504. VALUE        Acct-Authentic        Remote            3
  16505. VALUE        Acct-Authentic        RADIUS            4
  16506. VALUE        Acct-Authentic        MNET            5
  16507. VALUE        Acct-Authentic        KCHAP            6
  16508. VALUE        Acct-Authentic        TACACS            7
  16509. VALUE        Acct-Authentic        Realm            8
  16510. VALUE        Acct-Authentic        Local            9
  16511. VALUE        Acct-Authentic        File            10
  16512. VALUE        Acct-Authentic        Local-VPN        11
  16513.  
  16514. #
  16515. #    USR Extensions: USR Vendor-Specific stuff.
  16516. #
  16517. #    For now in NMC format (whatever that stands for), though the
  16518. #    normal vendor-specific format would work just as well.
  16519. #
  16520. #
  16521.  
  16522. ATTRIB_NMC    USR-Last-Number-Dialed-Out        0x0066    string
  16523. ATTRIB_NMC    USR-Last-Number-Dialed-In-DNIS        0x00E8    string
  16524. ATTRIB_NMC    USR-Last-Callers-Number-ANI        0x00E9    string
  16525. ATTRIB_NMC    USR-Channel                0xBF38    integer 
  16526. ATTRIB_NMC    USR-Event-Id                0xBFBE    integer
  16527. ATTRIB_NMC    USR-Event-Date-Time            0xBF2F    date
  16528. ATTRIB_NMC    USR-Call-Start-Date-Time        0xBFF7    date
  16529. ATTRIB_NMC    USR-Call-End-Date-Time            0xBFF6    date
  16530. ATTRIB_NMC    USR-Default-DTE-Data-Rate        0x005E    integer
  16531. ATTRIB_NMC    USR-Initial-Rx-Link-Data-Rate        0xBF2D    integer
  16532. ATTRIB_NMC    USR-Final-Rx-Link-Data-Rate        0xBF2C    integer
  16533. ATTRIB_NMC    USR-Initial-Tx-Link-Data-Rate        0x006A    integer
  16534. ATTRIB_NMC    USR-Final-Tx-Link-Data-Rate        0x006B    integer
  16535. ATTRIB_NMC    USR-Chassis-Temperature            0xBF31    integer
  16536. ATTRIB_NMC    USR-Chassis-Temp-Threshold        0xBE84    integer
  16537. ATTRIB_NMC    USR-Actual-Voltage            0xBF32    integer
  16538. ATTRIB_NMC    USR-Expected-Voltage            0xBF33    integer
  16539. ATTRIB_NMC    USR-Power-Supply-Number            0xBF34    integer
  16540. ATTRIB_NMC    USR-Card-Type                0xBE85    integer
  16541. ATTRIB_NMC    USR-Chassis-Slot            0xBF39    integer
  16542. ATTRIB_NMC    USR-Sync-Async-Mode            0x0067    integer
  16543. ATTRIB_NMC    USR-Originate-Answer-Mode        0x0068    integer
  16544. ATTRIB_NMC    USR-Modulation-Type            0x006C    integer
  16545. ATTRIB_NMC    USR-Connect-Term-Reason            0x009B    integer
  16546. ATTRIB_NMC    USR-Failure-to-Connect-Reason        0x0069    integer
  16547. ATTRIB_NMC    USR-Equalization-Type            0x006F    integer
  16548. ATTRIB_NMC    USR-Fallback-Enabled            0x0070    integer
  16549. ATTRIB_NMC    USR-Connect-Time-Limit            0xBFE7    integer
  16550. ATTRIB_NMC    USR-Number-of-Rings-Limit        0xBFE6    integer
  16551. ATTRIB_NMC    USR-DTE-Data-Idle-Timout        0x0048    integer
  16552. ATTRIB_NMC    USR-Characters-Sent            0x0071    integer
  16553. ATTRIB_NMC    USR-Characters-Received            0x0072    integer
  16554. ATTRIB_NMC    USR-Blocks-Sent                0x0075    integer
  16555. ATTRIB_NMC    USR-Blocks-Received            0x0076    integer
  16556. ATTRIB_NMC    USR-Blocks-Resent            0x0077    integer
  16557. ATTRIB_NMC    USR-Retrains-Requested            0x0078    integer
  16558. ATTRIB_NMC    USR-Retrains-Granted            0x0079    integer
  16559. ATTRIB_NMC    USR-Line-Reversals            0x007A    integer
  16560. ATTRIB_NMC    USR-Number-Of-Characters-Lost        0x007B    integer
  16561. ATTRIB_NMC    USR-Number-of-Blers            0x007D    integer
  16562. ATTRIB_NMC    USR-Number-of-Link-Timeouts        0x007E    integer
  16563. ATTRIB_NMC    USR-Number-of-Fallbacks            0x007F    integer
  16564. ATTRIB_NMC    USR-Number-of-Upshifts            0x0080    integer
  16565. ATTRIB_NMC    USR-Number-of-Link-NAKs            0x0081    integer
  16566. ATTRIB_NMC    USR-DTR-False-Timeout            0x00BE    integer
  16567. ATTRIB_NMC    USR-Fallback-Limit            0x00BF    integer
  16568. ATTRIB_NMC    USR-Block-Error-Count-Limit        0x00C0    integer
  16569. ATTRIB_NMC    USR-DTR-True-Timeout            0x00DA    integer
  16570. ATTRIB_NMC    USR-Security-Login-Limit        0xBEDE    integer
  16571. ATTRIB_NMC    USR-Security-Resp-Limit            0xBEFA    integer
  16572. ATTRIB_NMC    USR-DTE-Ring-No-Answer-Limit        0xBF17    integer
  16573. ATTRIB_NMC    USR-Back-Channel-Data-Rate        0x007C    integer
  16574. ATTRIB_NMC    USR-Simplified-MNP-Levels        0x0099    integer
  16575. ATTRIB_NMC    USR-Simplified-V42bis-Usage        0x00C7    integer
  16576. ATTRIB_NMC    USR-Mbi_Ct_PRI_Card_Slot        0x0184    integer
  16577. ATTRIB_NMC    USR-Mbi_Ct_TDM_Time_Slot        0x0185    integer
  16578. ATTRIB_NMC    USR-Mbi_Ct_PRI_Card_Span_Line        0x0186    integer
  16579. ATTRIB_NMC    USR-Mbi_Ct_BChannel_Used        0x0187    integer
  16580. ATTRIB_NMC    USR-Physical-State            0xBE77    integer
  16581. ATTRIB_NMC    USR-Packet-Bus-Session            0xBF14    integer
  16582. ATTRIB_NMC    USR-Server-Time                0xF000    date
  16583.  
  16584. # 0xBE5D-0xBE63 sent with Event-Id 79
  16585. ATTRIB_NMC    USR-Channel-Connected-To        0xBE5D    integer
  16586. ATTRIB_NMC    USR-Slot-Connected-To            0xBE5E    integer 
  16587. ATTRIB_NMC    USR-Device-Connected-To            0xBE5F    integer
  16588. ATTRIB_NMC    USR-NFAS-ID                0xBE60    integer
  16589. ATTRIB_NMC    USR-Q931-Call-Reference-Value        0xBE61    integer
  16590. ATTRIB_NMC    USR-Call-Event-Code            0xBE62    integer
  16591. ATTRIB_NMC    USR-DS0                    0xBE63    integer
  16592. # DS0s sent with Event-Id 77,78
  16593. ATTRIB_NMC    USR-DS0s                0xBE64    string
  16594. # Gateway-IP-Address sent with Event-Id 71,72
  16595. ATTRIB_NMC    USR-Gateway-IP-Address            0xBE66    ipaddr
  16596.  
  16597.  
  16598. #
  16599. # These are CCA Radius attributes
  16600. #
  16601. ATTRIB_NMC    USR-PW_USR_IFilter_IP            0x9000    string
  16602. ATTRIB_NMC    USR-PW_USR_IFilter_IPX            0x9001    string
  16603. ATTRIB_NMC    USR-PW_USR_OFilter_IP            0x9003    string
  16604. ATTRIB_NMC    USR-PW_USR_OFilter_IPX            0x9004    string
  16605. ATTRIB_NMC    USR-PW_USR_OFilter_SAP            0x9005    string
  16606. ATTRIB_NMC    USR-PW_VPN_ID                0x9006    string
  16607. ATTRIB_NMC    USR-PW_VPN_Name                0x9007    string
  16608. ATTRIB_NMC    USR-PW_VPN_Neighbor            0x9008    string
  16609. ATTRIB_NMC    USR-PW_Framed_Routing_V2        0x9009    string
  16610. ATTRIB_NMC    USR-PW_VPN_Gateway            0x900a    string
  16611. ATTRIB_NMC    USR-PW_Tunnel_Authentication        0x900b    string
  16612. ATTRIB_NMC    USR-PW_Index                0x900c    string
  16613. ATTRIB_NMC    USR-PW_Cutoff                0x900d    string
  16614. ATTRIB_NMC    USR-PW_Packet                0x900e    string
  16615. ATTRIB_NMC    USR-Primary_DNS_Server            0x900f    ipaddr
  16616. ATTRIB_NMC    USR-Secondary_DNS_Server        0x9010    ipaddr
  16617. ATTRIB_NMC    USR-Primary_NBNS_Server            0x9011    ipaddr
  16618. ATTRIB_NMC    USR-Secondary_NBNS_Server        0x9012    ipaddr
  16619. ATTRIB_NMC    USR-Syslog-Tap                0x9013    integer
  16620. ATTRIB_NMC    USR-Chassis-Call-Slot            0x9019    integer
  16621. ATTRIB_NMC    USR-Chassis-Call-Span            0x901A    integer
  16622. ATTRIB_NMC    USR-Chassis-Call-Channel        0x901B    integer
  16623. ATTRIB_NMC    USR-Keypress-Timeout            0x901C    integer
  16624. ATTRIB_NMC    USR-Unauthenticated-Time        0x901D    integer
  16625. ATTRIB_NMC    USR-Connect-Speed            0x9023    integer
  16626. ATTRIB_NMC    USR-Framed_IP_Address_Pool_Name        0x9024    string
  16627. ATTRIB_NMC    USR-MP-EDO                0x9025    string    
  16628.  
  16629. #
  16630. # Pilgrim attributes
  16631. # 
  16632. ATTRIB_NMC    USR-Bearer-Capabilities            0x9800    integer
  16633. ATTRIB_NMC    USR-Speed-Of-Connection            0x9801    integer
  16634. ATTRIB_NMC    USR-Max-Channels            0x9802    integer
  16635. ATTRIB_NMC    USR-Channel-Expansion            0x9803    integer
  16636. ATTRIB_NMC    USR-Channel-Decrement            0x9804    integer
  16637. ATTRIB_NMC    USR-Expansion-Algorithm            0x9805    integer
  16638. ATTRIB_NMC    USR-Compression-Algorithm        0x9806    integer
  16639. ATTRIB_NMC    USR-Receive-Acc-Map            0x9807    integer
  16640. ATTRIB_NMC    USR-Transmit-Acc-Map            0x9808    integer
  16641. ATTRIB_NMC    USR-Compression-Reset-Mode        0x980a    integer
  16642. ATTRIB_NMC    USR-Min-Compression-Size        0x980b    integer
  16643. ATTRIB_NMC    USR-IP                    0x980c    integer
  16644. ATTRIB_NMC    USR-IPX                    0x980d    integer
  16645. ATTRIB_NMC    USR-Filter-Zones            0x980e    integer
  16646. ATTRIB_NMC    USR-Appletalk                0x980f    integer
  16647. ATTRIB_NMC    USR-Bridging                0x9810    integer
  16648. ATTRIB_NMC    USR-Spoofing                0x9811    integer
  16649. ATTRIB_NMC    USR-Host-Type                0x9812    integer
  16650. ATTRIB_NMC    USR-Send-Name                0x9813    string
  16651. ATTRIB_NMC    USR-Send-Password            0x9814    string
  16652. ATTRIB_NMC    USR-Start-Time                0x9815    integer
  16653. ATTRIB_NMC    USR-End-Time                0x9816    integer
  16654. ATTRIB_NMC    USR-Send-Script1            0x9817    string
  16655. ATTRIB_NMC    USR-Reply-Script1            0x9818    string
  16656. ATTRIB_NMC    USR-Send-Script2            0x9819    string
  16657. ATTRIB_NMC    USR-Reply-Script2            0x981a    string
  16658. ATTRIB_NMC    USR-Send-Script3            0x981b    string
  16659. ATTRIB_NMC    USR-Reply-Script3            0x981c    string
  16660. ATTRIB_NMC    USR-Send-Script4            0x981d    string
  16661. ATTRIB_NMC    USR-Reply-Script4            0x981e    string
  16662. ATTRIB_NMC    USR-Send-Script5            0x981f    string
  16663. ATTRIB_NMC    USR-Reply-Script5            0x9820    string
  16664. ATTRIB_NMC    USR-Send-Script6            0x9821    string
  16665. ATTRIB_NMC    USR-Reply-Script6            0x9822    string
  16666. ATTRIB_NMC    USR-Terminal-Type            0x9823    string
  16667. ATTRIB_NMC    USR-Appletalk-Network-Range        0x9824    integer
  16668. ATTRIB_NMC    USR-Local-IP-Address            0x9825    string
  16669. ATTRIB_NMC    USR-Routing-Protocol            0x9826    integer
  16670. ATTRIB_NMC    USR-Modem-Group                0x9827    integer
  16671. ATTRIB_NMC    USR-Modem-Training-Time            0x9842    integer
  16672. ATTRIB_NMC    USR-Interface-Index            0x9843    integer
  16673. ATTRIB_NMC    USR-MP-MRRU                0x982f    integer
  16674.  
  16675. #    Virtual Private Network Extensions
  16676. #
  16677. ATTRIB_NMC    USR-VPN-ID            36870        integer
  16678. ATTRIB_NMC    USR-VPN-Name            36871        string
  16679. ATTRIB_NMC    USR-VPN-Neighbor        36872        ipaddr
  16680. ATTRIB_NMC    USR-RIPV2            36873        integer
  16681. ATTRIB_NMC    USR-VPN-Gateway            36874        string
  16682. ATTRIB_NMC    USR-VPN-Auth-Vector        36875        string
  16683. ATTRIB_NMC    USR-RQ_INDEX            36876        integer
  16684. #USR_ATTRIBUTE        User-Cutoff               36877      integer
  16685. ATTRIB_NMC    USR-PACKET            36878        string
  16686. ATTRIB_NMC    USR-IP-Filter-In        36864        string
  16687. ATTRIB_NMC    USR-IPX-Filter-In        36865        string
  16688. ATTRIB_NMC    USR-SAP-Filter-In        36866        string
  16689. ATTRIB_NMC    USR-IP-Filter-Out        36867        string
  16690. ATTRIB_NMC    USR-IPX-Filter-Out        36868        string
  16691. ATTRIB_NMC    USR-SAP-Filter-Out        36869        string
  16692. ATTRIB_NMC    USR-Syslog-Tap            36883        integer
  16693. ATTRIB_NMC    USR-MIC                36884        string
  16694. ATTRIB_NMC    USR-Log-Filter-Packets        36887        string
  16695. ATTRIB_NMC    USR-Chassis-Call-Slot        36889        integer
  16696. ATTRIB_NMC    USR-Chassis-Call-Span        36890        integer
  16697. ATTRIB_NMC    USR-Chassis-Call-Channel    36891        integer
  16698. ATTRIB_NMC    USR-Keypress-Timeout        36892        integer
  16699. ATTRIB_NMC    USR-Unauthenticated-Time    36893        integer
  16700. ATTRIB_NMC    USR-VPN-Encrypter        36894        integer
  16701. ATTRIB_NMC    USR-Re-Chap-Timeout        36896        integer
  16702. ATTRIB_NMC    USR-Tunnel-Switch-Endpoint    39016        string
  16703.  
  16704. # End of VPN crap
  16705.  
  16706. #
  16707. #    Integer Translations
  16708. #
  16709.  
  16710. #VALUE        USR-Character-Echo    Echo-On            0
  16711. #VALUE        USR-Character-Echo    Echo-Off        1
  16712.  
  16713. VALUE        USR-RIPV2        Off            0
  16714. VALUE        USR-RIPV2        On            1
  16715.  
  16716. VALUE        USR-Syslog-Tap        Off            0
  16717. VALUE        USR-Syslog-Tap        On-Raw            1
  16718. VALUE        USR-Syslog-Tap        On-Framed        2
  16719. VALUE        USR-Syslog-Tap        Unknown           4294967295
  16720.  
  16721.  
  16722. #    Event Indentifiers
  16723.  
  16724. VALUE    USR-Event-Id    Module-Inserted            6
  16725. VALUE    USR-Event-Id    Module-Removed            7
  16726. VALUE    USR-Event-Id    PSU-Voltage-Alarm        8
  16727. VALUE    USR-Event-Id    PSU-Failed            9
  16728. VALUE    USR-Event-Id    HUB-Temp-Out-of-Range        10
  16729. VALUE    USR-Event-Id    Fan-Failed            11
  16730. VALUE    USR-Event-Id    Watchdog-Timeout        12
  16731. VALUE    USR-Event-Id    Mgmt-Bus-Failure        13
  16732. VALUE    USR-Event-Id    In-Connection-Est        14
  16733. VALUE    USR-Event-Id    Out-Connection-Est        15
  16734. VALUE    USR-Event-Id    In-Connection-Term        16
  16735. VALUE    USR-Event-Id    Out-Connection-Term        17
  16736. VALUE    USR-Event-Id    Connection-Failed        18
  16737. VALUE    USR-Event-Id    Connection-Timeout        19
  16738. VALUE    USR-Event-Id    DTE-Transmit-Idle        20
  16739. VALUE    USR-Event-Id    DTR-True            21
  16740. VALUE    USR-Event-Id    DTR-False            22
  16741. VALUE    USR-Event-Id    Block-Error-at-Threshold    23
  16742. VALUE    USR-Event-Id    Fallbacks-at-Threshold        24
  16743. VALUE    USR-Event-Id    No-Dial-Tone-Detected        25
  16744. VALUE    USR-Event-Id    No-Loop-Current-Detected    26
  16745. VALUE    USR-Event-Id    Yellow-Alarm            27
  16746. VALUE    USR-Event-Id    Red-Alarm            28
  16747. VALUE    USR-Event-Id    Loss-Of-Signal            29
  16748. VALUE    USR-Event-Id    Rcv-Alrm-Ind-Signal        30
  16749. VALUE    USR-Event-Id    Timing-Source-Switch        31
  16750. VALUE    USR-Event-Id    Modem-Reset-by-DTE        32
  16751. VALUE    USR-Event-Id    Modem-Ring-No-Answer        33
  16752. VALUE    USR-Event-Id    DTE-Ring-No-Answer        34
  16753. VALUE    USR-Event-Id    Pkt-Bus-Session-Active        35
  16754. VALUE    USR-Event-Id    Pkt-Bus-Session-Congestion    36
  16755. VALUE    USR-Event-Id    Pkt-Bus-Session-Lost        37
  16756. VALUE    USR-Event-Id    Pkt-Bus-Session-Inactive    38
  16757. VALUE    USR-Event-Id    User-Interface-Reset        39
  16758. VALUE    USR-Event-Id    Gateway-Port-Out-of-Service    40
  16759. VALUE    USR-Event-Id    Gateway-Port-Link-Active    41
  16760. VALUE    USR-Event-Id    Dial-Out-Login-Failure        42
  16761. VALUE    USR-Event-Id    Dial-In-Login-Failure        43
  16762. VALUE    USR-Event-Id    Dial-Out-Restricted-Number    44
  16763. VALUE    USR-Event-Id    Dial-Back-Restricted-Number    45
  16764. VALUE    USR-Event-Id    User-Blacklisted        46
  16765. VALUE    USR-Event-Id    Attempted-Login-Blacklisted    47
  16766. VALUE    USR-Event-Id    Response-Attempt-Limit-Exceeded 48
  16767. VALUE    USR-Event-Id    Login-Attempt-Limit-Exceeded    49
  16768. VALUE    USR-Event-Id    Dial-Out-Call-Duration        50
  16769. VALUE    USR-Event-Id    Dial-In-Call-Duration        51
  16770. VALUE    USR-Event-Id    Pkt-Bus-Session-Err-Status    52
  16771. VALUE    USR-Event-Id    NMC-AutoRespnse-Trap        53
  16772. VALUE    USR-Event-Id    Acct-Server-Contact-Loss    54
  16773. VALUE    USR-Event-Id    Yellow-Alarm-Clear        55
  16774. VALUE    USR-Event-Id    Red-Alarm-Clear            56
  16775. VALUE    USR-Event-Id    Loss-Of-Signal-Clear        57
  16776. VALUE    USR-Event-Id    Rcv-Alrm-Ind-Signal-Clear    58
  16777. VALUE    USR-Event-Id    Incoming-Connection-Established 59
  16778. VALUE    USR-Event-Id    Outgoing-Connection-Established 60
  16779. VALUE    USR-Event-Id    Incoming-Connection-Terminated    61
  16780. VALUE    USR-Event-Id    Outgoing-Connection-Terminated    62
  16781. VALUE    USR-Event-Id    Connection-Attempt-Failure    63
  16782. VALUE    USR-Event-Id    Continuous-CRC-Alarm        64
  16783. VALUE    USR-Event-Id    Continuous-CRC-Alarm-Clear    65
  16784. VALUE    USR-Event-Id    Physical-State-Change        66
  16785. VALUE    USR-Event-Id    Gateway-Network-Failed        71
  16786. VALUE    USR-Event-Id    Gateway-Network-Restored    72
  16787. VALUE    USR-Event-Id    Packet-Bus-Clock-Lost        73
  16788. VALUE    USR-Event-Id    Packet-Bus-Clock-Restored    74
  16789. VALUE    USR-Event-Id    D-Channel-In-Service        75
  16790. VALUE    USR-Event-Id    D-Channel-Out-of-Service    76
  16791. VALUE    USR-Event-Id    DS0s-In-Service            77
  16792. VALUE    USR-Event-Id    DS0s-Out-of-Service        78
  16793. VALUE    USR-Event-Id    T1/T1PRI/E1PRI-Call-Event    79
  16794. VALUE    USR-Event-Id    Psu-Incompatible        80
  16795.  
  16796.  
  16797. VALUE    USR-Card-Type    SlotEmpty            1
  16798. VALUE    USR-Card-Type    SlotUnknown            2
  16799. VALUE    USR-Card-Type    NetwMgtCard            3
  16800. VALUE    USR-Card-Type    DualT1NAC            4
  16801. VALUE    USR-Card-Type    DualModemNAC            5
  16802. VALUE    USR-Card-Type    QuadModemNAC            6
  16803. VALUE    USR-Card-Type    TrGatewayNAC            7
  16804. VALUE    USR-Card-Type    X25GatewayNAC            8
  16805. VALUE    USR-Card-Type    DualV34ModemNAC            9
  16806. VALUE    USR-Card-Type    QuadV32DigitalModemNAC        10
  16807. VALUE    USR-Card-Type    QuadV32AnalogModemNAC        11
  16808. VALUE    USR-Card-Type    QuadV32DigAnlModemNAC        12
  16809. VALUE    USR-Card-Type    QuadV34DigModemNAC        13
  16810. VALUE    USR-Card-Type    QuadV34AnlModemNAC        14
  16811. VALUE    USR-Card-Type    QuadV34DigAnlModemNAC        15
  16812. VALUE    USR-Card-Type    SingleT1NAC            16
  16813. VALUE    USR-Card-Type    EthernetGatewayNAC        17
  16814. VALUE    USR-Card-Type    AccessServer            18
  16815. VALUE    USR-Card-Type    486TrGatewayNAC            19
  16816. VALUE    USR-Card-Type    486EthernetGatewayNAC        20
  16817. VALUE    USR-Card-Type    DualRS232NAC            22
  16818. VALUE    USR-Card-Type    486X25GatewayNAC        23
  16819. VALUE    USR-Card-Type    ApplicationServerNAC        25
  16820. VALUE    USR-Card-Type    ISDNGatewayNAC            26
  16821. VALUE    USR-Card-Type    ISDNpriT1NAC            27
  16822. VALUE    USR-Card-Type    ClkedNetMgtCard            28
  16823. VALUE    USR-Card-Type    ModemPoolManagementNAC        29
  16824. VALUE    USR-Card-Type    ModemPoolNetserverNAC        30
  16825. VALUE    USR-Card-Type    ModemPoolV34ModemNAC        31
  16826. VALUE    USR-Card-Type    ModemPoolISDNNAC        32
  16827. VALUE    USR-Card-Type    NTServerNAC            33
  16828. VALUE    USR-Card-Type    QuadV34DigitalG2NAC        34
  16829. VALUE    USR-Card-Type    QuadV34AnalogG2NAC        35
  16830. VALUE    USR-Card-Type    QuadV34DigAnlgG2NAC        36
  16831. VALUE    USR-Card-Type    NETServerFrameRelayNAC        37
  16832. VALUE    USR-Card-Type    NETServerTokenRingNAC        38
  16833. VALUE    USR-Card-Type    X2524ChannelNAC            39
  16834. VALUE    USR-Card-Type    WirelessGatewayNac        42
  16835.  
  16836. VALUE    USR-Card-Type    EnhancedAccessServer          44
  16837. VALUE    USR-Card-Type    EnhancedISDNGatewayNAC          45
  16838.  
  16839. VALUE    USR-Card-Type    DualT1NIC            1001
  16840. VALUE    USR-Card-Type    DualAlogMdmNIC            1002
  16841. VALUE    USR-Card-Type    QuadDgtlMdmNIC            1003
  16842. VALUE    USR-Card-Type    QuadAlogDgtlMdmNIC        1004
  16843. VALUE    USR-Card-Type    TokenRingNIC            1005
  16844. VALUE    USR-Card-Type    SingleT1NIC            1006
  16845. VALUE    USR-Card-Type    EthernetNIC            1007
  16846. VALUE    USR-Card-Type    ShortHaulDualT1NIC        1008
  16847. VALUE    USR-Card-Type    DualAlogMgdIntlMdmNIC        1009
  16848. VALUE    USR-Card-Type    X25NIC                1010
  16849. VALUE    USR-Card-Type    QuadAlogNonMgdMdmNIC        1011
  16850. VALUE    USR-Card-Type    QuadAlogMgdIntlMdmNIC        1012
  16851. VALUE    USR-Card-Type    QuadAlogNonMgdIntlMdmNIC    1013
  16852. VALUE    USR-Card-Type    QuadLsdLiMgdMdmNIC        1014
  16853. VALUE    USR-Card-Type    QuadLsdLiNonMgdMdmNIC        1015
  16854. VALUE    USR-Card-Type    QuadLsdLiMgdIntlMdmNIC        1016
  16855. VALUE    USR-Card-Type    QuadLsdLiNonMgdIntlMdmNIC    1017
  16856. VALUE    USR-Card-Type    HSEthernetWithV35NIC        1018
  16857. VALUE    USR-Card-Type    HSEthernetWithoutV35NIC        1019
  16858. VALUE    USR-Card-Type    DualHighSpeedV35NIC        1020
  16859. VALUE    USR-Card-Type    QuadV35RS232LowSpeedNIC        1021
  16860. VALUE    USR-Card-Type    DualE1NIC            1022
  16861. VALUE    USR-Card-Type    ShortHaulDualE1NIC        1023
  16862. VALUE    USR-Card-Type    BellcoreLongHaulDualT1NIC    1025
  16863. VALUE    USR-Card-Type    BellcoreShrtHaulDualT1NIC    1026
  16864. VALUE    USR-Card-Type    SCSIEdgeServerNIC        1027
  16865.  
  16866.  
  16867. VALUE    USR-Default-DTE-Data-Rate          110-BPS          1
  16868. VALUE    USR-Default-DTE-Data-Rate          300-BPS          2
  16869. VALUE    USR-Default-DTE-Data-Rate          600-BPS          3
  16870. VALUE    USR-Default-DTE-Data-Rate          1200-BPS          4
  16871. VALUE    USR-Default-DTE-Data-Rate          2400-BPS          5
  16872. VALUE    USR-Default-DTE-Data-Rate          4800-BPS          6
  16873. VALUE    USR-Default-DTE-Data-Rate          7200-BPS          7
  16874. VALUE    USR-Default-DTE-Data-Rate          9600-BPS          8
  16875. VALUE    USR-Default-DTE-Data-Rate          12K-BPS          9
  16876. VALUE    USR-Default-DTE-Data-Rate          14.4K-BPS          10
  16877. VALUE    USR-Default-DTE-Data-Rate          16.8-BPS          11
  16878. VALUE    USR-Default-DTE-Data-Rate          19.2K-BPS          12
  16879. VALUE    USR-Default-DTE-Data-Rate          38.4K-BPS          13
  16880. VALUE    USR-Default-DTE-Data-Rate          75-BPS          14
  16881. VALUE    USR-Default-DTE-Data-Rate          450-BPS          15
  16882. VALUE    USR-Default-DTE-Data-Rate          UNKNOWN-BPS     16
  16883. VALUE    USR-Default-DTE-Data-Rate          57.6K-BPS          17
  16884. VALUE    USR-Default-DTE-Data-Rate          21.6K-BPS          18
  16885. VALUE    USR-Default-DTE-Data-Rate          24K-BPS          19
  16886. VALUE    USR-Default-DTE-Data-Rate          26K-BPS          20
  16887. VALUE    USR-Default-DTE-Data-Rate          28K-BPS          21
  16888. VALUE    USR-Default-DTE-Data-Rate          115K-BPS          22
  16889.  
  16890.  
  16891. VALUE    USR-Initial-Rx-Link-Data-Rate    110-BPS        1
  16892. VALUE    USR-Initial-Rx-Link-Data-Rate    300-BPS        2
  16893. VALUE    USR-Initial-Rx-Link-Data-Rate    600-BPS        3
  16894. VALUE    USR-Initial-Rx-Link-Data-Rate    1200-BPS    4
  16895. VALUE    USR-Initial-Rx-Link-Data-Rate    2400-XBPS    5
  16896. VALUE    USR-Initial-Rx-Link-Data-Rate    4800-BPS    6
  16897. VALUE    USR-Initial-Rx-Link-Data-Rate    7200-BPS    7
  16898. VALUE    USR-Initial-Rx-Link-Data-Rate    9600-BPS    8
  16899. VALUE    USR-Initial-Rx-Link-Data-Rate    12K-BPS        9
  16900. VALUE    USR-Initial-Rx-Link-Data-Rate    14.4K-BPS    10
  16901. VALUE    USR-Initial-Rx-Link-Data-Rate    16.8-BPS    11
  16902. VALUE    USR-Initial-Rx-Link-Data-Rate    19.2K-BPS    12
  16903. VALUE    USR-Initial-Rx-Link-Data-Rate    38.4K-BPS    13
  16904. VALUE    USR-Initial-Rx-Link-Data-Rate    75-BPS        14
  16905. VALUE    USR-Initial-Rx-Link-Data-Rate    450-BPS        15
  16906. VALUE    USR-Initial-Rx-Link-Data-Rate    UNKNOWN-BPS    16
  16907. VALUE    USR-Initial-Rx-Link-Data-Rate    57.6K-BPS    17
  16908. VALUE    USR-Initial-Rx-Link-Data-Rate    21.6K-BPS    18
  16909. VALUE    USR-Initial-Rx-Link-Data-Rate    24K-BPS        19
  16910. VALUE    USR-Initial-Rx-Link-Data-Rate    26K-BPS        20
  16911. VALUE    USR-Initial-Rx-Link-Data-Rate    28K-BPS        21
  16912. VALUE    USR-Initial-Rx-Link-Data-Rate    115K-BPS    22
  16913. VALUE    USR-Initial-Rx-Link-Data-Rate    31K-BPS        23
  16914. VALUE    USR-Initial-Rx-Link-Data-Rate    33K-BPS        24
  16915. VALUE    USR-Initial-Rx-Link-Data-Rate    32K-BPS        25
  16916. VALUE    USR-Initial-Rx-Link-Data-Rate    36K-BPS        26
  16917. VALUE    USR-Initial-Rx-Link-Data-Rate    40K-BPS        27
  16918. VALUE    USR-Initial-Rx-Link-Data-Rate    44K-BPS        28
  16919. VALUE    USR-Initial-Rx-Link-Data-Rate    48K-BPS        29
  16920. VALUE    USR-Initial-Rx-Link-Data-Rate    49333-BPS    30
  16921. VALUE    USR-Initial-Rx-Link-Data-Rate    50666-BPS    31
  16922. VALUE    USR-Initial-Rx-Link-Data-Rate    52K-BPS        32
  16923. VALUE    USR-Initial-Rx-Link-Data-Rate    53333-BPS    33
  16924. VALUE    USR-Initial-Rx-Link-Data-Rate    54666-BPS    34
  16925. VALUE    USR-Initial-Rx-Link-Data-Rate    56K-BPS        35
  16926. VALUE    USR-Initial-Rx-Link-Data-Rate    57333-BPS    36
  16927. VALUE    USR-Initial-Rx-Link-Data-Rate    58666-BPS    37
  16928. VALUE    USR-Initial-Rx-Link-Data-Rate    60K-BPS        38
  16929. VALUE    USR-Initial-Rx-Link-Data-Rate    61333-BPS    39
  16930. VALUE    USR-Initial-Rx-Link-Data-Rate    64K-BPS        40
  16931.  
  16932.  
  16933. VALUE    USR-Final-Rx-Link-Data-Rate        110-BPS        1
  16934. VALUE    USR-Final-Rx-Link-Data-Rate        300-BPS        2
  16935. VALUE    USR-Final-Rx-Link-Data-Rate        600-BPS        3
  16936. VALUE    USR-Final-Rx-Link-Data-Rate        1200-BPS    4
  16937. VALUE    USR-Final-Rx-Link-Data-Rate        2400-BPS    5
  16938. VALUE    USR-Final-Rx-Link-Data-Rate        4800-BPS    6
  16939. VALUE    USR-Final-Rx-Link-Data-Rate        7200-BPS    7
  16940. VALUE    USR-Final-Rx-Link-Data-Rate        9600-BPS    8
  16941. VALUE    USR-Final-Rx-Link-Data-Rate        12K-BPS        9
  16942. VALUE    USR-Final-Rx-Link-Data-Rate        14.4K-BPS    10
  16943. VALUE    USR-Final-Rx-Link-Data-Rate        16.8-BPS    11
  16944. VALUE    USR-Final-Rx-Link-Data-Rate        19.2K-BPS    12
  16945. VALUE    USR-Final-Rx-Link-Data-Rate        38.4K-BPS    13
  16946. VALUE    USR-Final-Rx-Link-Data-Rate        75-BPS        14
  16947. VALUE    USR-Final-Rx-Link-Data-Rate        450-BPS        15
  16948. VALUE    USR-Final-Rx-Link-Data-Rate        UNKNOWN-BPS    16
  16949. VALUE    USR-Final-Rx-Link-Data-Rate        57.6K-BPS    17
  16950. VALUE    USR-Final-Rx-Link-Data-Rate        21.6K-BPS    18
  16951. VALUE    USR-Final-Rx-Link-Data-Rate        24K-BPS        19
  16952. VALUE    USR-Final-Rx-Link-Data-Rate        26K-BPS        20
  16953. VALUE    USR-Final-Rx-Link-Data-Rate        28K-BPS        21
  16954. VALUE    USR-Final-Rx-Link-Data-Rate        115K-BPS    22
  16955. VALUE    USR-Final-Rx-Link-Data-Rate        31K-BPS        23
  16956. VALUE    USR-Final-Rx-Link-Data-Rate        33K-BPS        24
  16957. VALUE    USR-Final-Rx-Link-Data-Rate        32K-BPS        25
  16958. VALUE    USR-Final-Rx-Link-Data-Rate        36K-BPS        26
  16959. VALUE    USR-Final-Rx-Link-Data-Rate        40K-BPS        27
  16960. VALUE    USR-Final-Rx-Link-Data-Rate        44K-BPS        28
  16961. VALUE    USR-Final-Rx-Link-Data-Rate        48K-BPS        29
  16962. VALUE    USR-Final-Rx-Link-Data-Rate        49333-BPS    30
  16963. VALUE    USR-Final-Rx-Link-Data-Rate        50666-BPS    31
  16964. VALUE    USR-Final-Rx-Link-Data-Rate        52K-BPS        32
  16965. VALUE    USR-Final-Rx-Link-Data-Rate        53333-BPS    33
  16966. VALUE    USR-Final-Rx-Link-Data-Rate        54666-BPS    34
  16967. VALUE    USR-Final-Rx-Link-Data-Rate        56K-BPS        35
  16968. VALUE    USR-Final-Rx-Link-Data-Rate        57333-BPS    36
  16969. VALUE    USR-Final-Rx-Link-Data-Rate        58666-BPS    37
  16970. VALUE    USR-Final-Rx-Link-Data-Rate        60K-BPS        38
  16971. VALUE    USR-Final-Rx-Link-Data-Rate        61333-BPS    39
  16972. VALUE    USR-Final-Rx-Link-Data-Rate        64K-BPS        40
  16973.  
  16974.  
  16975. VALUE    USR-Initial-Tx-Link-Data-Rate    110-BPS        1
  16976. VALUE    USR-Initial-Tx-Link-Data-Rate    300-BPS        2
  16977. VALUE    USR-Initial-Tx-Link-Data-Rate    600-BPS        3
  16978. VALUE    USR-Initial-Tx-Link-Data-Rate    1200-BPS    4
  16979. VALUE    USR-Initial-Tx-Link-Data-Rate    2400-BPS    5
  16980. VALUE    USR-Initial-Tx-Link-Data-Rate    4800-BPS    6
  16981. VALUE    USR-Initial-Tx-Link-Data-Rate    7200-BPS    7
  16982. VALUE    USR-Initial-Tx-Link-Data-Rate    9600-BPS    8
  16983. VALUE    USR-Initial-Tx-Link-Data-Rate    12K-BPS        9
  16984. VALUE    USR-Initial-Tx-Link-Data-Rate    14.4K-BPS    10
  16985. VALUE    USR-Initial-Tx-Link-Data-Rate    16.8-BPS    11
  16986. VALUE    USR-Initial-Tx-Link-Data-Rate    19.2K-BPS    12
  16987. VALUE    USR-Initial-Tx-Link-Data-Rate    38.4K-BPS    13
  16988. VALUE    USR-Initial-Tx-Link-Data-Rate    75-BPS        14
  16989. VALUE    USR-Initial-Tx-Link-Data-Rate    450-BPS        15
  16990. VALUE    USR-Initial-Tx-Link-Data-Rate    UNKNOWN-BPS    16
  16991. VALUE    USR-Initial-Tx-Link-Data-Rate    57.6K-BPS    17
  16992. VALUE    USR-Initial-Tx-Link-Data-Rate    21.6K-BPS    18
  16993. VALUE    USR-Initial-Tx-Link-Data-Rate    24K-BPS        19
  16994. VALUE    USR-Initial-Tx-Link-Data-Rate    26K-BPS        20
  16995. VALUE    USR-Initial-Tx-Link-Data-Rate    28K-BPS        21
  16996. VALUE    USR-Initial-Tx-Link-Data-Rate    115K-BPS    22
  16997. VALUE    USR-Initial-Tx-Link-Data-Rate    31K-BPS        23    
  16998. VALUE    USR-Initial-Tx-Link-Data-Rate    33K-BPS        24
  16999. VALUE    USR-Initial-Tx-Link-Data-Rate    32K-BPS        25
  17000. VALUE    USR-Initial-Tx-Link-Data-Rate    36K-BPS        26
  17001. VALUE    USR-Initial-Tx-Link-Data-Rate    40K-BPS        27
  17002. VALUE    USR-Initial-Tx-Link-Data-Rate    44K-BPS        28
  17003. VALUE    USR-Initial-Tx-Link-Data-Rate    48K-BPS        29
  17004. VALUE    USR-Initial-Tx-Link-Data-Rate    49333-BPS    30
  17005. VALUE    USR-Initial-Tx-Link-Data-Rate    50666-BPS    31
  17006. VALUE    USR-Initial-Tx-Link-Data-Rate    52K-BPS        32
  17007. VALUE    USR-Initial-Tx-Link-Data-Rate    53333-BPS    33
  17008. VALUE    USR-Initial-Tx-Link-Data-Rate    54666-BPS    34
  17009. VALUE    USR-Initial-Tx-Link-Data-Rate    56K-BPS        35
  17010. VALUE    USR-Initial-Tx-Link-Data-Rate    57333-BPS    36
  17011. VALUE    USR-Initial-Tx-Link-Data-Rate    58666-BPS    37
  17012. VALUE    USR-Initial-Tx-Link-Data-Rate    60K-BPS        38
  17013. VALUE    USR-Initial-Tx-Link-Data-Rate    61333-BPS    39
  17014. VALUE    USR-Initial-Tx-Link-Data-Rate    64K-BPS        40
  17015.  
  17016.  
  17017. VALUE    USR-Final-Tx-Link-Data-Rate        110-BPS        1
  17018. VALUE    USR-Final-Tx-Link-Data-Rate        300-BPS        2
  17019. VALUE    USR-Final-Tx-Link-Data-Rate        600-BPS        3
  17020. VALUE    USR-Final-Tx-Link-Data-Rate        1200-BPS    4
  17021. VALUE    USR-Final-Tx-Link-Data-Rate        2400-BPS    5
  17022. VALUE    USR-Final-Tx-Link-Data-Rate        4800-BPS    6
  17023. VALUE    USR-Final-Tx-Link-Data-Rate        7200-BPS    7
  17024. VALUE    USR-Final-Tx-Link-Data-Rate        9600-BPS    8
  17025. VALUE    USR-Final-Tx-Link-Data-Rate        12K-BPS        9
  17026. VALUE    USR-Final-Tx-Link-Data-Rate        14.4K-BPS    10
  17027. VALUE    USR-Final-Tx-Link-Data-Rate        16.8-BPS    11
  17028. VALUE    USR-Final-Tx-Link-Data-Rate        19.2K-BPS    12
  17029. VALUE    USR-Final-Tx-Link-Data-Rate        38.4K-BPS    13
  17030. VALUE    USR-Final-Tx-Link-Data-Rate        75-BPS        14
  17031. VALUE    USR-Final-Tx-Link-Data-Rate        450-BPS        15
  17032. VALUE    USR-Final-Tx-Link-Data-Rate        UNKNOWN-BPS    16
  17033. VALUE    USR-Final-Tx-Link-Data-Rate        57.6K-BPS    17
  17034. VALUE    USR-Final-Tx-Link-Data-Rate        21.6K-BPS    18
  17035. VALUE    USR-Final-Tx-Link-Data-Rate        24K-BPS        19
  17036. VALUE    USR-Final-Tx-Link-Data-Rate        26K-BPS        20
  17037. VALUE    USR-Final-Tx-Link-Data-Rate        28K-BPS        21
  17038. VALUE    USR-Final-Tx-Link-Data-Rate        115K-BPS    22
  17039. VALUE    USR-Final-Tx-Link-Data-Rate        31K-BPS        23
  17040. VALUE    USR-Final-Tx-Link-Data-Rate        33K-BPS        24
  17041. VALUE    USR-Final-Tx-Link-Data-Rate        32K-BPS        25
  17042. VALUE    USR-Final-Tx-Link-Data-Rate        36K-BPS        26
  17043. VALUE    USR-Final-Tx-Link-Data-Rate        40K-BPS        27
  17044. VALUE    USR-Final-Tx-Link-Data-Rate        44K-BPS        28
  17045. VALUE    USR-Final-Tx-Link-Data-Rate        48K-BPS        29
  17046. VALUE    USR-Final-Tx-Link-Data-Rate        49333-BPS    30
  17047. VALUE    USR-Final-Tx-Link-Data-Rate        50666-BPS    31
  17048. VALUE    USR-Final-Tx-Link-Data-Rate        52K-BPS        32
  17049. VALUE    USR-Final-Tx-Link-Data-Rate        53333-BPS    33
  17050. VALUE    USR-Final-Tx-Link-Data-Rate        54666-BPS    34
  17051. VALUE    USR-Final-Tx-Link-Data-Rate        56K-BPS        35
  17052. VALUE    USR-Final-Tx-Link-Data-Rate        57333-BPS    36
  17053. VALUE    USR-Final-Tx-Link-Data-Rate        58666-BPS    37
  17054. VALUE    USR-Final-Tx-Link-Data-Rate        60K-BPS        38
  17055. VALUE    USR-Final-Tx-Link-Data-Rate        61333-BPS    39
  17056. VALUE    USR-Final-Tx-Link-Data-Rate        64K-BPS        40
  17057.  
  17058. # Value Connect Speed  /* Added by Krish */
  17059.  
  17060. VALUE    USR-Connect-Speed  NONE        0 
  17061. VALUE    USR-Connect-Speed  300_BPS        1 
  17062. VALUE    USR-Connect-Speed  1200_BPS         2 
  17063. VALUE    USR-Connect-Speed  2400_BPS         3 
  17064. VALUE    USR-Connect-Speed  4800_BPS         4 
  17065. VALUE    USR-Connect-Speed  7200_BPS         5 
  17066. VALUE    USR-Connect-Speed  9600_BPS         6 
  17067. VALUE    USR-Connect-Speed  12000_BPS      7 
  17068. VALUE    USR-Connect-Speed  14400_BPS      8 
  17069. VALUE    USR-Connect-Speed  16800_BPS      9
  17070. VALUE    USR-Connect-Speed  19200_BPS     10 
  17071. VALUE    USR-Connect-Speed  21600_BPS     11 
  17072. VALUE    USR-Connect-Speed  28800_BPS     12 
  17073. VALUE    USR-Connect-Speed  38400_BPS     13 
  17074. VALUE    USR-Connect-Speed  57600_BPS     14 
  17075. VALUE    USR-Connect-Speed  44000_BPS     27 
  17076. VALUE    USR-Connect-Speed  45333_BPS     28 
  17077. VALUE    USR-Connect-Speed  46666_BPS     29 
  17078. VALUE    USR-Connect-Speed  48000_BPS     30 
  17079. VALUE    USR-Connect-Speed  49333_BPS     31 
  17080. VALUE    USR-Connect-Speed  50666_BPS     32 
  17081. VALUE    USR-Connect-Speed  52000_BPS     33 
  17082. VALUE    USR-Connect-Speed  53333_BPS     34 
  17083. VALUE    USR-Connect-Speed  54666_BPS     35 
  17084. VALUE    USR-Connect-Speed  56000_BPS     36 
  17085. VALUE    USR-Connect-Speed  57333_BPS     37 
  17086. VALUE    USR-Connect-Speed  64000_BPS     38 
  17087. VALUE    USR-Connect-Speed  25333_BPS     39 
  17088. VALUE    USR-Connect-Speed  26666_BPS      40
  17089. VALUE    USR-Connect-Speed  28000_BPS      41 
  17090. VALUE    USR-Connect-Speed  115200_BPS     15 
  17091. VALUE    USR-Connect-Speed  288000_BPS      16
  17092. VALUE    USR-Connect-Speed  75_1200_BPS    17 
  17093. VALUE    USR-Connect-Speed  1200_75_BPS    18
  17094. VALUE    USR-Connect-Speed  24000_BPS      19
  17095. VALUE    USR-Connect-Speed  26400_BPS      20
  17096. VALUE    USR-Connect-Speed  31200_BPS      21
  17097. VALUE    USR-Connect-Speed  33600_BPS      22
  17098. VALUE    USR-Connect-Speed  33333_BPS      23
  17099. VALUE    USR-Connect-Speed  37333_BPS      24
  17100. VALUE    USR-Connect-Speed  41333_BPS      25
  17101. VALUE    USR-Connect-Speed  42666_BPS      26
  17102. VALUE    USR-Connect-Speed  29333_BPS      42 
  17103. VALUE    USR-Connect-Speed  30666_BPS      43
  17104. VALUE    USR-Connect-Speed  32000_BPS      44 
  17105. VALUE    USR-Connect-Speed  34666_BPS      45 
  17106. VALUE    USR-Connect-Speed  36000_BPS      46 
  17107. VALUE    USR-Connect-Speed  38666_BPS      47 
  17108. VALUE    USR-Connect-Speed  40000_BPS      48 
  17109. VALUE    USR-Connect-Speed  58666_BPS      49 
  17110. VALUE    USR-Connect-Speed  60000_BPS      50 
  17111. VALUE    USR-Connect-Speed  61333_BPS      51 
  17112. VALUE    USR-Connect-Speed  62666_BPS      52 
  17113.  
  17114. # End of Connect-Speed / * Added by Krish */
  17115.  
  17116. #
  17117.  
  17118. VALUE    USR-Sync-Async-Mode        Asynchronous            1
  17119. VALUE    USR-Sync-Async-Mode        Synchronous            2
  17120.  
  17121. VALUE    USR-Originate-Answer-Mode    Originate_in_Originate_Mode    1
  17122. VALUE    USR-Originate-Answer-Mode    Originate_in_Answer_Mode    2
  17123. VALUE    USR-Originate-Answer-Mode    Answer_in_Originate_Mode    3
  17124. VALUE    USR-Originate-Answer-Mode    Answer_in_Answer_Mode        4
  17125.  
  17126. VALUE    USR-Modulation-Type        usRoboticsHST            1
  17127. VALUE    USR-Modulation-Type        ccittV32            2
  17128. VALUE    USR-Modulation-Type        ccittV22bis            3
  17129. VALUE    USR-Modulation-Type        bell103                4
  17130. VALUE    USR-Modulation-Type        ccittV21            5
  17131. VALUE    USR-Modulation-Type        bell212                6
  17132. VALUE    USR-Modulation-Type        ccittV32bis            7
  17133. VALUE    USR-Modulation-Type        ccittV23            8
  17134. VALUE    USR-Modulation-Type        negotiationFailed        9
  17135. VALUE    USR-Modulation-Type        bell208b            10
  17136. VALUE    USR-Modulation-Type        v21FaxClass1            11
  17137. VALUE    USR-Modulation-Type        v27FaxClass1            12
  17138. VALUE    USR-Modulation-Type        v29FaxClass1            13
  17139. VALUE    USR-Modulation-Type        v17FaxClass1            14
  17140. VALUE    USR-Modulation-Type        v21FaxClass2            15
  17141. VALUE    USR-Modulation-Type        v27FaxClass2            16
  17142. VALUE    USR-Modulation-Type        v29FaxClass2            17
  17143. VALUE    USR-Modulation-Type        v17FaxClass2            18
  17144. VALUE    USR-Modulation-Type        v32Terbo            19
  17145. VALUE    USR-Modulation-Type        v34                20
  17146. VALUE    USR-Modulation-Type        vFC                21
  17147. VALUE    USR-Modulation-Type        v34plus                22
  17148.  
  17149. VALUE    USR-Connect-Term-Reason    dtrDrop                1
  17150. VALUE    USR-Connect-Term-Reason    escapeSequence            2
  17151. VALUE    USR-Connect-Term-Reason    athCommand            3
  17152. VALUE    USR-Connect-Term-Reason    carrierLoss            4
  17153. VALUE    USR-Connect-Term-Reason    inactivityTimout        5
  17154. VALUE    USR-Connect-Term-Reason    mnpIncompatible            6
  17155. VALUE    USR-Connect-Term-Reason    undefined            7
  17156. VALUE    USR-Connect-Term-Reason    remotePassword            8
  17157. VALUE    USR-Connect-Term-Reason    linkPassword            9
  17158. VALUE    USR-Connect-Term-Reason    retransmitLimit            10
  17159. VALUE    USR-Connect-Term-Reason    linkDisconnectMsgReceived    11
  17160. VALUE    USR-Connect-Term-Reason    noLoopCurrent            12
  17161. VALUE    USR-Connect-Term-Reason    invalidSpeed            13
  17162. VALUE    USR-Connect-Term-Reason    unableToRetrain            14
  17163. VALUE    USR-Connect-Term-Reason    managementCommand        15
  17164. VALUE    USR-Connect-Term-Reason    noDialTone            16
  17165. VALUE    USR-Connect-Term-Reason    keyAbort            17
  17166. VALUE    USR-Connect-Term-Reason    lineBusy            18
  17167. VALUE    USR-Connect-Term-Reason    noAnswer            19
  17168. VALUE    USR-Connect-Term-Reason    voice                20
  17169. VALUE    USR-Connect-Term-Reason    noAnswerTone            21
  17170. VALUE    USR-Connect-Term-Reason    noCarrier            22
  17171. VALUE    USR-Connect-Term-Reason    undetermined            23
  17172. VALUE    USR-Connect-Term-Reason    v42SabmeTimeout            24
  17173. VALUE    USR-Connect-Term-Reason    v42BreakTimeout            25
  17174. VALUE    USR-Connect-Term-Reason    v42DisconnectCmd        26
  17175. VALUE    USR-Connect-Term-Reason    v42IdExchangeFail        27
  17176. VALUE    USR-Connect-Term-Reason    v42BadSetup            28
  17177. VALUE    USR-Connect-Term-Reason    v42InvalidCodeWord        29
  17178. VALUE    USR-Connect-Term-Reason    v42StringToLong            30
  17179. VALUE    USR-Connect-Term-Reason    v42InvalidCommand        31
  17180. VALUE    USR-Connect-Term-Reason    none                32    
  17181. VALUE    USR-Connect-Term-Reason    v32Cleardown            33
  17182. VALUE    USR-Connect-Term-Reason    dialSecurity            34
  17183. VALUE    USR-Connect-Term-Reason    remoteAccessDenied        35
  17184. VALUE    USR-Connect-Term-Reason    loopLoss            36
  17185. VALUE    USR-Connect-Term-Reason    ds0Teardown            37
  17186. VALUE    USR-Connect-Term-Reason    promptNotEnabled        38
  17187. VALUE    USR-Connect-Term-Reason    noPromptingInSync        39
  17188. VALUE    USR-Connect-Term-Reason    nonArqMode            40
  17189. VALUE    USR-Connect-Term-Reason    modeIncompatible        41
  17190. VALUE    USR-Connect-Term-Reason    noPromptInNonARQ        42
  17191. VALUE    USR-Connect-Term-Reason    dialBackLink            43
  17192. VALUE    USR-Connect-Term-Reason    linkAbort            44
  17193. VALUE    USR-Connect-Term-Reason    autopassFailed            45
  17194. VALUE    USR-Connect-Term-Reason    pbGenericError            46
  17195. VALUE    USR-Connect-Term-Reason    pbLinkErrTxPreAck        47
  17196. VALUE    USR-Connect-Term-Reason    pbLinkErrTxTardyACK        48
  17197. VALUE    USR-Connect-Term-Reason    pbTransmitBusTimeout        49
  17198. VALUE    USR-Connect-Term-Reason    pbReceiveBusTimeout        50
  17199. VALUE    USR-Connect-Term-Reason    pbLinkErrTxTAL            51
  17200. VALUE    USR-Connect-Term-Reason    pbLinkErrRxTAL            52
  17201. VALUE    USR-Connect-Term-Reason    pbTransmitMasterTimeout        53
  17202. VALUE    USR-Connect-Term-Reason    pbClockMissing            54
  17203. VALUE    USR-Connect-Term-Reason    pbReceivedLsWhileLinkUp        55
  17204. VALUE    USR-Connect-Term-Reason    pbOutOfSequenceFrame        56
  17205. VALUE    USR-Connect-Term-Reason    pbBadFrame            57
  17206. VALUE    USR-Connect-Term-Reason    pbAckWaitTimeout        58
  17207. VALUE    USR-Connect-Term-Reason    pbReceivedAckSeqErr        59
  17208. VALUE    USR-Connect-Term-Reason    pbReceiveOvrflwRNRFail        60
  17209. VALUE    USR-Connect-Term-Reason    pbReceiveMsgBufOvrflw        61
  17210. VALUE    USR-Connect-Term-Reason    rcvdGatewayDiscCmd        62
  17211. VALUE    USR-Connect-Term-Reason    tokenPassingTimeout        63
  17212. VALUE    USR-Connect-Term-Reason    dspInterruptTimeout        64
  17213. VALUE    USR-Connect-Term-Reason    mnpProtocolViolation        65
  17214. VALUE    USR-Connect-Term-Reason    class2FaxHangupCmd        66
  17215. VALUE    USR-Connect-Term-Reason    hstSpeedSwitchTimeout        67
  17216.  
  17217. VALUE    USR-Failure-to-Connect-Reason    dtrDrop            1
  17218. VALUE    USR-Failure-to-Connect-Reason    escapeSequence        2
  17219. VALUE    USR-Failure-to-Connect-Reason    athCommand        3
  17220. VALUE    USR-Failure-to-Connect-Reason    carrierLoss        4
  17221. VALUE    USR-Failure-to-Connect-Reason    inactivityTimout    5
  17222. VALUE    USR-Failure-to-Connect-Reason    mnpIncompatible        6
  17223. VALUE    USR-Failure-to-Connect-Reason    undefined        7
  17224. VALUE    USR-Failure-to-Connect-Reason    remotePassword        8
  17225. VALUE    USR-Failure-to-Connect-Reason    linkPassword        9
  17226. VALUE    USR-Failure-to-Connect-Reason    retransmitLimit        10
  17227. VALUE    USR-Failure-to-Connect-Reason    linkDisconnectMsgRec    11
  17228. VALUE    USR-Failure-to-Connect-Reason    noLoopCurrent        12
  17229. VALUE    USR-Failure-to-Connect-Reason    invalidSpeed        13
  17230. VALUE    USR-Failure-to-Connect-Reason    unableToRetrain        14
  17231. VALUE    USR-Failure-to-Connect-Reason    managementCommand    15
  17232. VALUE    USR-Failure-to-Connect-Reason    noDialTone        16
  17233. VALUE    USR-Failure-to-Connect-Reason    keyAbort        17
  17234. VALUE    USR-Failure-to-Connect-Reason    lineBusy        18
  17235. VALUE    USR-Failure-to-Connect-Reason    noAnswer        19
  17236. VALUE    USR-Failure-to-Connect-Reason    voice            20
  17237. VALUE    USR-Failure-to-Connect-Reason    noAnswerTone        21
  17238. VALUE    USR-Failure-to-Connect-Reason    noCarrier        22
  17239. VALUE    USR-Failure-to-Connect-Reason    undetermined        23
  17240. VALUE    USR-Failure-to-Connect-Reason    v42SabmeTimeout        24
  17241. VALUE    USR-Failure-to-Connect-Reason    v42BreakTimeout        25
  17242. VALUE    USR-Failure-to-Connect-Reason    v42DisconnectCmd    26
  17243. VALUE    USR-Failure-to-Connect-Reason    v42IdExchangeFail    27
  17244. VALUE    USR-Failure-to-Connect-Reason    v42BadSetup        28
  17245. VALUE    USR-Failure-to-Connect-Reason    v42InvalidCodeWord    29
  17246. VALUE    USR-Failure-to-Connect-Reason    v42StringToLong        30
  17247. VALUE    USR-Failure-to-Connect-Reason    v42InvalidCommand    31
  17248. VALUE    USR-Failure-to-Connect-Reason    none            32    
  17249. VALUE    USR-Failure-to-Connect-Reason    v32Cleardown        33
  17250. VALUE    USR-Failure-to-Connect-Reason    dialSecurity        34
  17251. VALUE    USR-Failure-to-Connect-Reason    remoteAccessDenied    35
  17252. VALUE    USR-Failure-to-Connect-Reason    loopLoss        36
  17253. VALUE    USR-Failure-to-Connect-Reason    ds0Teardown        37
  17254. VALUE    USR-Failure-to-Connect-Reason    promptNotEnabled    38
  17255. VALUE    USR-Failure-to-Connect-Reason    noPromptingInSync    39
  17256. VALUE    USR-Failure-to-Connect-Reason    nonArqMode        40
  17257. VALUE    USR-Failure-to-Connect-Reason    modeIncompatible    41
  17258. VALUE    USR-Failure-to-Connect-Reason    noPromptInNonARQ    42
  17259. VALUE    USR-Failure-to-Connect-Reason    dialBackLink        43
  17260. VALUE    USR-Failure-to-Connect-Reason    linkAbort        44
  17261. VALUE    USR-Failure-to-Connect-Reason    autopassFailed        45
  17262. VALUE    USR-Failure-to-Connect-Reason    pbGenericError        46
  17263. VALUE    USR-Failure-to-Connect-Reason    pbLinkErrTxPreAck    47
  17264. VALUE    USR-Failure-to-Connect-Reason    pbLinkErrTxTardyACK    48
  17265. VALUE    USR-Failure-to-Connect-Reason    pbTransmitBusTimeout    49
  17266. VALUE    USR-Failure-to-Connect-Reason    pbReceiveBusTimeout    50
  17267. VALUE    USR-Failure-to-Connect-Reason    pbLinkErrTxTAL        51
  17268. VALUE    USR-Failure-to-Connect-Reason    pbLinkErrRxTAL        52
  17269. VALUE    USR-Failure-to-Connect-Reason    pbTransmitMasterTimeout 53
  17270. VALUE    USR-Failure-to-Connect-Reason    pbClockMissing        54
  17271. VALUE    USR-Failure-to-Connect-Reason    pbReceivedLsWhileLinkUp 55
  17272. VALUE    USR-Failure-to-Connect-Reason    pbOutOfSequenceFrame    56
  17273. VALUE    USR-Failure-to-Connect-Reason    pbBadFrame        57
  17274. VALUE    USR-Failure-to-Connect-Reason    pbAckWaitTimeout    58
  17275. VALUE    USR-Failure-to-Connect-Reason    pbReceivedAckSeqErr    59
  17276. VALUE    USR-Failure-to-Connect-Reason    pbReceiveOvrflwRNRFail    60
  17277. VALUE    USR-Failure-to-Connect-Reason    pbReceiveMsgBufOvrflw    61
  17278. VALUE    USR-Failure-to-Connect-Reason    rcvdGatewayDiscCmd    62
  17279. VALUE    USR-Failure-to-Connect-Reason    tokenPassingTimeout    63
  17280. VALUE    USR-Failure-to-Connect-Reason    dspInterruptTimeout    64
  17281. VALUE    USR-Failure-to-Connect-Reason    mnpProtocolViolation    65
  17282. VALUE    USR-Failure-to-Connect-Reason    class2FaxHangupCmd    66
  17283. VALUE    USR-Failure-to-Connect-Reason    hstSpeedSwitchTimeout    67
  17284.  
  17285. VALUE    USR-Simplified-MNP-Levels        none            1
  17286. VALUE    USR-Simplified-MNP-Levels        mnpLevel3        2
  17287. VALUE    USR-Simplified-MNP-Levels        mnpLevel4        3
  17288. VALUE    USR-Simplified-MNP-Levels        ccittV42        4
  17289. VALUE    USR-Simplified-MNP-Levels        usRoboticsHST        5
  17290. VALUE    USR-Simplified-MNP-Levels        synchronousNone        6
  17291. VALUE    USR-Simplified-MNP-Levels        mnpLevel2        7
  17292. VALUE    USR-Simplified-MNP-Levels        mnp10            8
  17293. VALUE    USR-Simplified-MNP-Levels        v42Etc            9
  17294.  
  17295. VALUE    USR-Simplified-V42bis-Usage        none            1
  17296. VALUE    USR-Simplified-V42bis-Usage        ccittV42bis        2
  17297. VALUE    USR-Simplified-V42bis-Usage        mnpLevel5        3
  17298.  
  17299. VALUE    USR-Equalization-Type        Long        1
  17300. VALUE    USR-Equalization-Type        Short        2
  17301.  
  17302.  
  17303. VALUE    USR-Fallback-Enabled        Disabled    1
  17304. VALUE    USR-Fallback-Enabled        Enabled        2
  17305.  
  17306.  
  17307. VALUE    USR-Back-Channel-Data-Rate        450BPS        1
  17308. VALUE    USR-Back-Channel-Data-Rate        300BPS        2
  17309. VALUE    USR-Back-Channel-Data-Rate        None        3
  17310.  
  17311. VALUE    USR-Device-Connected-To        None        1
  17312. VALUE    USR-Device-Connected-To        isdnGateway    2
  17313. VALUE    USR-Device-Connected-To        quadModem    3
  17314.  
  17315. VALUE    USR-Call-Event-Code            notSupported          1
  17316. VALUE    USR-Call-Event-Code            setup              2
  17317. VALUE    USR-Call-Event-Code            usrSetup          3
  17318. VALUE    USR-Call-Event-Code            telcoDisconnect          4
  17319. VALUE    USR-Call-Event-Code            usrDisconnect          5
  17320. VALUE    USR-Call-Event-Code            noFreeModem          6
  17321. VALUE    USR-Call-Event-Code            modemsNotAllowed      7
  17322. VALUE    USR-Call-Event-Code            modemsRejectCall      8
  17323. VALUE    USR-Call-Event-Code            modemSetupTimeout     9
  17324. VALUE    USR-Call-Event-Code            noFreeIGW          10
  17325. VALUE    USR-Call-Event-Code            igwRejectCall          11
  17326. VALUE    USR-Call-Event-Code            igwSetupTimeout          12
  17327. VALUE    USR-Call-Event-Code            noFreeTdmts          13
  17328. VALUE    USR-Call-Event-Code            bcReject          14
  17329. VALUE    USR-Call-Event-Code            ieReject          15
  17330. VALUE    USR-Call-Event-Code            chidReject          16
  17331. VALUE    USR-Call-Event-Code            progReject          17
  17332. VALUE    USR-Call-Event-Code            callingPartyReject    18
  17333. VALUE    USR-Call-Event-Code            calledPartyReject     19
  17334. VALUE    USR-Call-Event-Code            blocked              20
  17335. VALUE    USR-Call-Event-Code            analogBlocked          21
  17336. VALUE    USR-Call-Event-Code            digitalBlocked          22
  17337. VALUE    USR-Call-Event-Code            outOfService          23
  17338. VALUE    USR-Call-Event-Code            busy              24
  17339. VALUE    USR-Call-Event-Code            congestion          25
  17340. VALUE    USR-Call-Event-Code            protocolError          26 
  17341. VALUE    USR-Call-Event-Code            noFreeBchannel          27
  17342. VALUE    USR-Call-Event-Code            inOutCallCollision    28
  17343.  
  17344. -
  17345.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17346.  with "unsubscribe usr-tc" in the body of the message.
  17347.  For information on digests or retrieving files and old messages send
  17348.  "help" to the same address.  Do not use quotes in your message.
  17349.  
  17350.  
  17351. -------------------------------------------------------------------------------
  17352.  
  17353. From: K Mitchell <mitch@keyconn.net>
  17354. Subject: (usr-tc) random busies
  17355. Date: 15 Mar 1999 17:04:40 -0500
  17356.  
  17357.   Recently I've been getting sporadic complaints of busy signals from
  17358. customers during times when our modem usage is signaficantly lower than
  17359. 100%. This is also not normally following a period in which most or all
  17360. modems were in use. After talking in depth with some of these customers,
  17361. the bsuies seem to be normally generated busy signals, not fast busies. I
  17362. have PRIs coming into HiPer DSP 1.2.60, ARC 4.1.72, NMC 5.5.5. Is this a
  17363. DSP/SRC issue, or possibly telco? Any suggestions/ideas appreciated.
  17364.  
  17365. Kirk
  17366.  
  17367.  
  17368.  
  17369. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  17370. Keystone Connect                http://www.keyconn.net
  17371. Altoona, PA   814-941-5000         We Unlock the World
  17372.  
  17373.  
  17374. -
  17375.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17376.  with "unsubscribe usr-tc" in the body of the message.
  17377.  For information on digests or retrieving files and old messages send
  17378.  "help" to the same address.  Do not use quotes in your message.
  17379.  
  17380.  
  17381. -------------------------------------------------------------------------------
  17382.  
  17383. From: <sagarwal@crash.ae.usr.com>
  17384. Subject: Re: (usr-tc) "unauthenticated" users + drops
  17385. Date: 15 Mar 1999 16:09:48 -0600 (CST)
  17386.  
  17387. Charles,
  17388.  
  17389. Logs for Unauthenticated calls means that Hiper Arc logs the calls which
  17390. failed prior to authentication. You can disable this by 
  17391.  
  17392. set accounting log_unauthenticated_calls false.
  17393.  
  17394. Regards
  17395.  
  17396. Sanjay
  17397.  
  17398. On Mon, 15 Mar 1999, Charles Sprickman wrote:
  17399.  
  17400. > All of a sudden we're getting many immediate disconnect requests.  The
  17401. > only odd thing I noticed was that my logfile has alot (??) of
  17402. > "unauthenticated" requests.
  17403. > 
  17404. > Does this mean anything?  Looking at this about 10% of calls fall into
  17405. > this class...
  17406. > 
  17407. > root@util[/usr/local/etc/radius/db-analog]# cat logfile | wc -l
  17408. >    18623
  17409. > root@util[/usr/local/etc/radius/db-analog]# grep unauth logfile | wc -l
  17410. >     1824
  17411. > 
  17412. > If I go back a few days, there's alot less:
  17413. > 
  17414. > root@util[/usr/local/etc/radius/db-analog]# zcat logfile.990311.gz | wc -l
  17415. >    34528
  17416. > root@util[/usr/local/etc/radius/db-analog]# zgrep unauth logfile.990311.gz
  17417. > | wc -l    1620                                                   
  17418. > 
  17419. > Ideas?  What exactly classifies as an "unauthenticated call"?
  17420. > 
  17421. > Thanks,
  17422. > 
  17423. > Charles
  17424. > 
  17425. > -- 
  17426. > =-----------------=                                        = 
  17427. > | Charles Sprickman                       Internet Channel |
  17428. > | INCH System Administration Team         (212)243-5200    |
  17429. > | spork@inch.com                          access@inch.com  |
  17430. > =                                         =----------------=
  17431. > 
  17432. > 
  17433. > -
  17434. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17435. >  with "unsubscribe usr-tc" in the body of the message.
  17436. >  For information on digests or retrieving files and old messages send
  17437. >  "help" to the same address.  Do not use quotes in your message.
  17438. > 
  17439.  
  17440.  
  17441. -
  17442.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17443.  with "unsubscribe usr-tc" in the body of the message.
  17444.  For information on digests or retrieving files and old messages send
  17445.  "help" to the same address.  Do not use quotes in your message.
  17446.  
  17447.  
  17448. -------------------------------------------------------------------------------
  17449.  
  17450. From: "Robert J. Adams" <radams@siscom.net>
  17451. Subject: (usr-tc) Num users on
  17452. Date: 15 Mar 1999 17:11:50 -0500
  17453.  
  17454. Hello,
  17455.  
  17456. A while back someone posted a URL to perl scripts (used with MRTG) to chart
  17457. the number of users on.. anyone have that URL handy?
  17458.  
  17459. -Jason
  17460. ---
  17461. Robert J. Adams radams@siscom.net http://www.siscom.net
  17462. Looking to outsource news? http://www.newshosting.com
  17463. SISCOM Network Administration - President, SISCOM Inc.
  17464. Phone: 937-222-8150 FAX: 937-222-8153
  17465.  
  17466.  
  17467. -
  17468.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17469.  with "unsubscribe usr-tc" in the body of the message.
  17470.  For information on digests or retrieving files and old messages send
  17471.  "help" to the same address.  Do not use quotes in your message.
  17472.  
  17473.  
  17474. -------------------------------------------------------------------------------
  17475.  
  17476. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  17477. Subject: RE: (usr-tc) "unauthenticated" users + drops
  17478. Date: 15 Mar 1999 16:12:19 -0600
  17479.  
  17480.  
  17481.  
  17482. |-----Original Message-----
  17483. |From: owner-usr-tc@lists.xmission.com
  17484. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Pete Ashdown
  17485. |Sent: Monday, March 15, 1999 3:54 PM
  17486. |To: usr-tc@lists.xmission.com
  17487. |Subject: Re: (usr-tc) "unauthenticated" users + drops
  17488. |
  17489. |
  17490. |Charles Sprickman said once upon a time:
  17491. |
  17492. |>Does this mean anything?  Looking at this about 10% of calls fall into
  17493. |>this class...
  17494. |
  17495. |No, it is noise from the ARC.
  17496.  
  17497. More of a din than a noise. It is usefull for some.
  17498.  
  17499. |>Ideas?  What exactly classifies as an "unauthenticated call"?
  17500. |
  17501.  
  17502. Any call that did not progress past authentication phase gets logged this way.
  17503. Either call drop or incorrect passwords.
  17504.  
  17505. -M
  17506.  
  17507.  
  17508. -
  17509.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17510.  with "unsubscribe usr-tc" in the body of the message.
  17511.  For information on digests or retrieving files and old messages send
  17512.  "help" to the same address.  Do not use quotes in your message.
  17513.  
  17514.  
  17515. -------------------------------------------------------------------------------
  17516.  
  17517. From: "Eric Billeter" <ebilleter@cableone.net>
  17518. Subject: RE: (usr-tc) Num users on
  17519. Date: 15 Mar 1999 15:19:38 -0700
  17520.  
  17521. http://www.cableone.net/ebilleter/hiperdsp.pl
  17522.  
  17523.  
  17524. or
  17525.  
  17526. the scripts are included in the contrib directory
  17527. with mrtg now.
  17528.  
  17529. Thanks
  17530.  
  17531. Eric T. Billeter                   Cable One
  17532. Internet Engineer                  1314 North 3rd Street
  17533. ebilleter@cableone.net             Phoenix, AZ 85004           
  17534.  
  17535. -----Original Message-----
  17536. [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Robert J. Adams
  17537. Sent: Monday, March 15, 1999 3:12 PM
  17538.  
  17539.  
  17540. Hello,
  17541.  
  17542. A while back someone posted a URL to perl scripts (used with MRTG) to chart
  17543. the number of users on.. anyone have that URL handy?
  17544.  
  17545. -Jason
  17546. ---
  17547. Robert J. Adams radams@siscom.net http://www.siscom.net
  17548. Looking to outsource news? http://www.newshosting.com
  17549. SISCOM Network Administration - President, SISCOM Inc.
  17550. Phone: 937-222-8150 FAX: 937-222-8153
  17551.  
  17552.  
  17553. -
  17554.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17555.  with "unsubscribe usr-tc" in the body of the message.
  17556.  For information on digests or retrieving files and old messages send
  17557.  "help" to the same address.  Do not use quotes in your message.
  17558.  
  17559.  
  17560.  
  17561.  
  17562. -
  17563.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17564.  with "unsubscribe usr-tc" in the body of the message.
  17565.  For information on digests or retrieving files and old messages send
  17566.  "help" to the same address.  Do not use quotes in your message.
  17567.  
  17568.  
  17569. -------------------------------------------------------------------------------
  17570.  
  17571. From: Stephen Amadei <amadei@dandy.net>
  17572. Subject: Re: (usr-tc) IEA , using it from Radius
  17573. Date: 15 Mar 1999 17:46:55 -0500 (EST)
  17574.  
  17575. On Sat, 13 Mar 1999, MegaZone wrote:
  17576.  
  17577. > This is the current Cistron 3Com dictionary - I don't know of the OS/2 port
  17578. > has the full 3Com VSA support, it was added fairly recently.
  17579.  
  17580. Thanx, MegaZone.  I'll give this a try.  The Cistron I ported was current 
  17581. about two/three months ago... I think a minor version has been released
  17582. since.  If worse comes to worse, I'll just report and newest version
  17583. again... it only took me a day or so to port it, and a week to catch one
  17584. nasty bug.  Works great now... after I ported last, sort and sac, too...
  17585. Gotta love those EMX libraries...
  17586.  
  17587.                     ----Steve
  17588. Stephen Amadei
  17589. Director of MIS
  17590. Dandy Connections, Inc.
  17591. Atlantic City, NJ
  17592.  
  17593.  
  17594. -
  17595.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17596.  with "unsubscribe usr-tc" in the body of the message.
  17597.  For information on digests or retrieving files and old messages send
  17598.  "help" to the same address.  Do not use quotes in your message.
  17599.  
  17600.  
  17601. -------------------------------------------------------------------------------
  17602.  
  17603. From: Stephen Amadei <amadei@dandy.net>
  17604. Subject: Re: (usr-tc) Num users on
  17605. Date: 15 Mar 1999 17:57:38 -0500 (EST)
  17606.  
  17607. On Mon, 15 Mar 1999, Robert J. Adams wrote:
  17608.  
  17609. > Hello,
  17610. > 
  17611. > A while back someone posted a URL to perl scripts (used with MRTG) to chart
  17612. > the number of users on.. anyone have that URL handy?
  17613.  
  17614. I don't have a URL handy, but I can share the script and cfg I use below.
  17615.  
  17616. This was seriously hacked up from the Portmaster scripts, so you'll
  17617. see a lot of references to 'portmaster'... just pretend they say 'total
  17618. control'... ;-)
  17619.  
  17620. The first file is tcmgather... the script which actually checks the TC's
  17621. for users and writes the data files.  You'll notice I have three physical
  17622. boxes in this script... two are full 12 Quad systems... one is a Hiper
  17623. chassis with 3 DSP cards in slots 13,14,15.
  17624.  
  17625. The second file is the config file MRTG needs to run with.  Basically it
  17626. tells MRTG where the data files are and how you want the graphs to look.
  17627.  
  17628. Have fun...
  17629.  
  17630.                     ----Steve
  17631. Stephen Amadei
  17632. Director of MIS
  17633. Dandy Connections, Inc.
  17634. Atlantic City, NJ
  17635.  
  17636.  
  17637. #!/bin/csh
  17638.  
  17639. # tcmgather  
  17640.  
  17641. # run this script ever 5 minutes via cron with a crontab something like:
  17642. # 1,6,11,16,21,26,31,36,41,46,51,56 * * * * /home/admin/pmgraph/bin/getstats
  17643. # note that this script calls MRTG
  17644.  
  17645. # set the names or IP's of your Portmasters
  17646. set TC1="moo.nmc.xxx.net"
  17647. set TC2="acy.nmc.xxx.net"
  17648. set TC3="pvl.nmc.xxx.net"
  17649.  
  17650. # set the SNMP read community of your Portmasters
  17651. set TC1comm="public"
  17652. set TC2comm="public"
  17653. set TC3comm="public" 
  17654.  
  17655. # Grab a user count for each Portmaster via the snmpwalk command
  17656. # You may need to use "snmpwalk -v 1" depending on your version of snmpwalk
  17657. # You may also need to grep for something other than "23"
  17658. set OID=".1.3.6.1.4.1.429.1.6.9.1.1.2"
  17659. set MLID="429.1.6.9.1.1.2.13"
  17660. set OCID1="429.1.6.9.1.1.2.15"
  17661. set OCID2="429.1.6.9.1.1.2.14"
  17662.  
  17663. set OCY1=`snmpwalk $TC1 $TC1comm $OID | grep ': 8' | grep $OCID1 | wc -l`
  17664. set OCY2=`snmpwalk $TC1 $TC1comm $OID | grep ': 8' | grep $OCID2 | wc -l`
  17665. set MIL=`snmpwalk $TC1 $TC1comm $OID | grep ': 8' | grep $MLID | wc -l`
  17666. set ACY=`snmpwalk $TC2 $TC2comm $OID | grep ': 8' | wc -l`
  17667. set PVL=`snmpwalk $TC3 $TC3comm $OID | grep ': 8' | wc -l`
  17668.  
  17669. # Get a grand total of users online 
  17670.  
  17671. set TOTAL=`expr  ${PVL} + ${OCY1} + ${OCY2} + ${MIL} + ${ACY}`
  17672. set OCYT=`expr $OCY1 + $OCY2` 
  17673.  
  17674. # MRTG needs 4 lines of input to be happy, we're only interested in the 2nd 
  17675. # line and possibly the first so we fill the others with junk
  17676.  
  17677. # write out the various logs
  17678. # grand total of all your Portmasters
  17679.         echo $TOTAL >  /var/lib/httpd/htdocs/dandynet/statistics/allports
  17680.         echo $TOTAL >> /var/lib/httpd/htdocs/dandynet/statistics/allports
  17681.         echo "ever" >> /var/lib/httpd/htdocs/dandynet/statistics/allports
  17682.         echo "everything" >> /var/lib/httpd/htdocs/dandynet/statistics/allports
  17683.  
  17684. # Portmaster #1
  17685.         echo $PVL   >  /var/lib/httpd/htdocs/dandynet/statistics/pville
  17686.         echo $PVL   >> /var/lib/httpd/htdocs/dandynet/statistics/pville
  17687.         echo "time" >> /var/lib/httpd/htdocs/dandynet/statistics/pville
  17688.         echo "PVL"  >> /var/lib/httpd/htdocs/dandynet/statistics/pville
  17689.  
  17690. # Portmaster #2
  17691.         echo $OCYT  >  /var/lib/httpd/htdocs/dandynet/statistics/ocy
  17692.         echo $OCYT  >> /var/lib/httpd/htdocs/dandynet/statistics/ocy
  17693.         echo "time" >> /var/lib/httpd/htdocs/dandynet/statistics/ocy
  17694.         echo "OCY"  >> /var/lib/httpd/htdocs/dandynet/statistics/ocy
  17695.  
  17696. # Portmaster #3
  17697.         echo $MIL   >  /var/lib/httpd/htdocs/dandynet/statistics/milmay
  17698.         echo $MIL   >> /var/lib/httpd/htdocs/dandynet/statistics/milmay
  17699.         echo "time" >> /var/lib/httpd/htdocs/dandynet/statistics/milmay
  17700.         echo "MIL"  >> /var/lib/httpd/htdocs/dandynet/statistics/milmay
  17701.  
  17702. # Portmaster #4
  17703.         echo $ACY   >  /var/lib/httpd/htdocs/dandynet/statistics/acy
  17704.         echo $ACY   >> /var/lib/httpd/htdocs/dandynet/statistics/acy
  17705.         echo "time" >> /var/lib/httpd/htdocs/dandynet/statistics/acy
  17706.         echo "ACY"  >> /var/lib/httpd/htdocs/dandynet/statistics/acy
  17707.  
  17708. # and finally, run MRTG specifying our customized .cfg file
  17709. eval `/usr/bin/mrtg/mrtg /usr/bin/mrtg/tcs.cfg`
  17710.  
  17711.  
  17712. WorkDir: /var/lib/httpd/htdocs/dandynet/statistics
  17713. Refresh: 600
  17714.  
  17715. Target[allports]: `cat /var/lib/httpd/htdocs/dandynet/statistics/allports`
  17716. Title[allports]: Modem Traffic for Smart Online Solutions
  17717. PageTop[allports]: <center><H1>Modem Traffic for Smart Online Solutions</H1></center>
  17718.     This page shows the total modem use at Smart Online Solutions.  
  17719.     Our four dial-ups are USR TotalControl PRIs that each
  17720.     control 24 modems, of which 23 are usable at a time, giving us a grand
  17721.     total of 161 dial-in lines. We also graph each TotalControl out separately,
  17722.     See:<UL>
  17723.         <LI><FONT Size=+2></FONT><A HREF="./pville.html">TotalControl Pleasantville</A><BR>
  17724.         <LI><FONT Size=+2></FONT><A HREF="./ocy.html">TotalControl Ocean City</A><BR>
  17725.         <LI><FONT Size=+2></FONT><A HREF="./milmay.html">TotalControl Milmay</A>
  17726.         <LI><FONT Size=+2></FONT><A HREF="./acy.html">TotalControl Atlantic City</A>
  17727.         </UL>
  17728. MaxBytes[allports]: 161
  17729. AbsMax[allports]: 161
  17730. Options[allports]: absolute, gauge
  17731. Ylegend[allports]: Total lines in use
  17732. RouterUptime[allports]:
  17733. ShortLegend[allports]: Modems Online
  17734. Unscaled[allports]: mwy
  17735. LegendI[allports]: Total
  17736. LegendO[allports]: Total
  17737. Legend2[allports]: <FONT Size=+2></FONT>Total count of all modems online at <A HREF="http://www.dandy.net">Smart Online Solutions</A>
  17738.  
  17739. Target[pville]: `cat /var/lib/httpd/htdocs/dandynet/statistics/pville`
  17740. PageTop[pville]: <center><H1>Modem Traffic on TotalControl PRI Pleasantville</H1></center>
  17741. MaxBytes[pville]: 46
  17742. AbsMax[pville]: 46
  17743. Options[pville]: absolute, gauge
  17744. Title[pville]: Modem Traffic on TotalControl PRI Pleasantville
  17745. Ylegend[pville]: Lines in use
  17746. RouterUptime[pville]:them@pvl.nmc.dandy.net
  17747. ShortLegend[pville]: Modems Online
  17748. Unscaled[pville]: dmwy
  17749. LegendI[pville]: Total
  17750. LegendO[pville]: Total
  17751. Legend2[pville]: Total count of modems used on TotalControl PRI Pleasantville
  17752.  
  17753. Target[ocy]: `cat /var/lib/httpd/htdocs/dandynet/statistics/ocy`
  17754. PageTop[ocy]: <center><H1>Modem Traffic on TotalControl PRI Ocean City</H1></center>
  17755. MaxBytes[ocy]: 46
  17756. AbsMax[ocy]: 46
  17757. Options[ocy]: absolute, gauge
  17758. Title[ocy]: Modem Traffic on TotalControl PRI Ocean City
  17759. Ylegend[ocy]: Lines in use
  17760. RouterUptime[ocy]:them@moo.nmc.dandy.net
  17761. ShortLegend[ocy]: Modems Online
  17762. Unscaled[ocy]: dmwy
  17763. LegendI[ocy]: Total
  17764. LegendO[ocy]: Total
  17765. Legend2[ocy]: Total count of modems used on TotalControl PRI Ocean City
  17766.  
  17767. Target[milmay]: `cat /var/lib/httpd/htdocs/dandynet/statistics/milmay`
  17768. PageTop[milmay]: <center><H1>Modem Traffic on TotalControl PRI Milmay</H1></center>
  17769. MaxBytes[milmay]: 23
  17770. AbsMax[milmay]: 23
  17771. Options[milmay]: absolute, gauge
  17772. Title[milmay]: Modem Traffic on TotalControl PRI Milmay
  17773. Ylegend[milmay]: Lines in use
  17774. RouterUptime[milmay]:them@moo.nmc.dandy.net
  17775. ShortLegend[milmay]: Modems Online
  17776. Unscaled[milmay]: dmwy
  17777. LegendI[milmay]: Total
  17778. LegendO[milmay]: Total
  17779. Legend2[milmay]: Total count of modems used on TotalControl PRI Milmay
  17780.  
  17781. Target[acy]: `cat /var/lib/httpd/htdocs/dandynet/statistics/acy`
  17782. PageTop[acy]: <center><H1>Modem Traffic on TotalControl PRI Atlantic City</H1></center>
  17783. MaxBytes[acy]: 46
  17784. AbsMax[acy]: 46
  17785. Options[acy]: absolute, gauge
  17786. Title[acy]: Modem Traffic on TotalControl PRI Atlantic City
  17787. Ylegend[acy]: Lines in use
  17788. RouterUptime[acy]: them@acy.nmc.dandy.net
  17789. ShortLegend[acy]: Modems Online
  17790. Unscaled[acy]: dmwy
  17791. LegendI[acy]: Total
  17792. LegendO[acy]: Total
  17793. Legend2[acy]: Total count of modems used on TotalControl PRI Atlantic City
  17794.  
  17795.  
  17796.  
  17797.  
  17798. -
  17799.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17800.  with "unsubscribe usr-tc" in the body of the message.
  17801.  For information on digests or retrieving files and old messages send
  17802.  "help" to the same address.  Do not use quotes in your message.
  17803.  
  17804.  
  17805. -------------------------------------------------------------------------------
  17806.  
  17807. From: Brett Murphy <sysadmin@alphalink.com.au>
  17808. Subject: (usr-tc) Filtering on HyperARC
  17809. Date: 16 Mar 1999 10:46:03 +1100
  17810.  
  17811. Hi All,
  17812. Has anyone got some sample filters or FAQ's for filtering on
  17813. the HyperARC?
  17814. For example, blocking the BO port on 31337 etc
  17815.  
  17816. --
  17817.  
  17818. All the best,
  17819. Brett Murphy
  17820. System Administrator, Alphalink (Australia) PTY LTD
  17821. ph: +61 3 9486-8844 fax: +61 3 9486-6822
  17822. email: sysadmin@alphalink.com.au
  17823.  
  17824. The contents of this message may not be quoted,
  17825. copied, reproduced or published in part or in whole,
  17826. without the written authorization of Brett Murphy,
  17827. Director, Alphalink (Australia) Pty Ltd.
  17828.  
  17829.  
  17830.  
  17831. -
  17832.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17833.  with "unsubscribe usr-tc" in the body of the message.
  17834.  For information on digests or retrieving files and old messages send
  17835.  "help" to the same address.  Do not use quotes in your message.
  17836.  
  17837.  
  17838. -------------------------------------------------------------------------------
  17839.  
  17840. From: Brett Murphy <sysadmin@alphalink.com.au>
  17841. Subject: (usr-tc) HyperARC needs a regular reboot?
  17842. Date: 16 Mar 1999 10:57:19 +1100
  17843.  
  17844. Hi All,
  17845. Far too regularly I am finding that when I telnet to my HyperARC
  17846. it drops the connection immediately. The problem remains until I
  17847. powercycle the chassis. Has anyone seen this before?
  17848.  
  17849. --
  17850.  
  17851. All the best,
  17852. Brett Murphy
  17853. System Administrator, Alphalink (Australia) PTY LTD
  17854. ph: +61 3 9486-8844 fax: +61 3 9486-6822
  17855. email: sysadmin@alphalink.com.au
  17856.  
  17857. The contents of this message may not be quoted,
  17858. copied, reproduced or published in part or in whole,
  17859. without the written authorization of Brett Murphy,
  17860. Director, Alphalink (Australia) Pty Ltd.
  17861.  
  17862.  
  17863.  
  17864. -
  17865.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17866.  with "unsubscribe usr-tc" in the body of the message.
  17867.  For information on digests or retrieving files and old messages send
  17868.  "help" to the same address.  Do not use quotes in your message.
  17869.  
  17870.  
  17871. -------------------------------------------------------------------------------
  17872.  
  17873. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  17874. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  17875. Date: 15 Mar 1999 18:33:44 -0600 (CST)
  17876.  
  17877. On Tue, 16 Mar 1999, Brett Murphy wrote:
  17878.  
  17879. > Hi All,
  17880. > Far too regularly I am finding that when I telnet to my HyperARC
  17881. > it drops the connection immediately. The problem remains until I
  17882. > powercycle the chassis. Has anyone seen this before?
  17883.  
  17884.  
  17885. Need to know the version of code you are using - some version of 4.0 and 
  17886. some versions of 4.1 did have some memory problems.  4.1.59 -6 - the 
  17887. latest one in the  web site http://totalservice.usr.com 
  17888. does fix a lot of issues.
  17889.  
  17890. If you are seeing this problem with 4.1.59 -6 then we need more info - 
  17891. like syslogs 
  17892.  
  17893. krish
  17894.  
  17895. > 
  17896. > --
  17897. > 
  17898. > All the best,
  17899. > Brett Murphy
  17900. > System Administrator, Alphalink (Australia) PTY LTD
  17901. > ph: +61 3 9486-8844 fax: +61 3 9486-6822
  17902. > email: sysadmin@alphalink.com.au
  17903. > 
  17904. > The contents of this message may not be quoted,
  17905. > copied, reproduced or published in part or in whole,
  17906. > without the written authorization of Brett Murphy,
  17907. > Director, Alphalink (Australia) Pty Ltd.
  17908. > 
  17909. > 
  17910. > 
  17911. > -
  17912. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17913. >  with "unsubscribe usr-tc" in the body of the message.
  17914. >  For information on digests or retrieving files and old messages send
  17915. >  "help" to the same address.  Do not use quotes in your message.
  17916. > 
  17917.  
  17918. -
  17919.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17920.  with "unsubscribe usr-tc" in the body of the message.
  17921.  For information on digests or retrieving files and old messages send
  17922.  "help" to the same address.  Do not use quotes in your message.
  17923.  
  17924.  
  17925. -------------------------------------------------------------------------------
  17926.  
  17927. From: Douglas Rabe <darabe@ans.net>
  17928. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  17929. Date: 15 Mar 1999 19:28:07 -0500 (EST)
  17930.  
  17931. > 
  17932. > On Tue, 16 Mar 1999, Brett Murphy wrote:
  17933. > 
  17934. > > Hi All,
  17935. > > Far too regularly I am finding that when I telnet to my HyperARC
  17936. > > it drops the connection immediately. The problem remains until I
  17937. > > powercycle the chassis. Has anyone seen this before?
  17938. > 
  17939. > 
  17940. > Need to know the version of code you are using - some version of 4.0 and 
  17941. > some versions of 4.1 did have some memory problems.  4.1.59 -6 - the 
  17942. > latest one in the  web site http://totalservice.usr.com 
  17943. > does fix a lot of issues.
  17944. > 
  17945. > If you are seeing this problem with 4.1.59 -6 then we need more info - 
  17946. > like syslogs 
  17947. > 
  17948. > krish
  17949.  
  17950. I have seen it on 4.1.59-0 and 4.1.67-*.  But only on hubs used for
  17951. DIALOUT.  When I get on the console I see out of memory errors.  All
  17952. I can do is reboot.  Again, I only see this on a hub used for DIALOUT,
  17953. never seen it on hiperarcs used for dialin.
  17954.  
  17955. -- 
  17956. Douglas Rabe                UUnet Technologies, Inc.            darabe@ans.net
  17957.  
  17958. -
  17959.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17960.  with "unsubscribe usr-tc" in the body of the message.
  17961.  For information on digests or retrieving files and old messages send
  17962.  "help" to the same address.  Do not use quotes in your message.
  17963.  
  17964.  
  17965. -------------------------------------------------------------------------------
  17966.  
  17967. From: Brett Murphy <sysadmin@alphalink.com.au>
  17968. Subject: Re: (usr-tc) random busies
  17969. Date: 16 Mar 1999 11:46:16 +1100
  17970.  
  17971. We have had these problems occasionally, using E1 in Australia.
  17972. Definitely a Telco problem in our case.
  17973.  
  17974. K Mitchell wrote:
  17975.  
  17976. >   Recently I've been getting sporadic complaints of busy signals from
  17977. > customers during times when our modem usage is signaficantly lower than
  17978. > 100%. This is also not normally following a period in which most or all
  17979. > modems were in use. After talking in depth with some of these customers,
  17980. > the bsuies seem to be normally generated busy signals, not fast busies. I
  17981. > have PRIs coming into HiPer DSP 1.2.60, ARC 4.1.72, NMC 5.5.5. Is this a
  17982. > DSP/SRC issue, or possibly telco? Any suggestions/ideas appreciated.
  17983. >
  17984. > Kirk
  17985. >
  17986. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  17987. > Keystone Connect                http://www.keyconn.net
  17988. > Altoona, PA   814-941-5000         We Unlock the World
  17989. >
  17990. > -
  17991. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  17992. >  with "unsubscribe usr-tc" in the body of the message.
  17993. >  For information on digests or retrieving files and old messages send
  17994. >  "help" to the same address.  Do not use quotes in your message.
  17995.  
  17996. --
  17997.  
  17998. All the best,
  17999. Brett Murphy
  18000. System Administrator, Alphalink (Australia) PTY LTD
  18001. ph: +61 3 9486-8844 fax: +61 3 9486-6822
  18002. email: sysadmin@alphalink.com.au
  18003.  
  18004. The contents of this message may not be quoted,
  18005. copied, reproduced or published in part or in whole,
  18006. without the written authorization of Brett Murphy,
  18007. Director, Alphalink (Australia) Pty Ltd.
  18008.  
  18009.  
  18010.  
  18011. -
  18012.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18013.  with "unsubscribe usr-tc" in the body of the message.
  18014.  For information on digests or retrieving files and old messages send
  18015.  "help" to the same address.  Do not use quotes in your message.
  18016.  
  18017.  
  18018. -------------------------------------------------------------------------------
  18019.  
  18020. From: Brett Murphy <sysadmin@alphalink.com.au>
  18021. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  18022. Date: 16 Mar 1999 11:48:06 +1100
  18023.  
  18024. How emarrasing!
  18025. I am using 4.1.11
  18026. I'll install the latest one asap.
  18027.  
  18028. Tatai SV Krishnan wrote:
  18029.  
  18030. > On Tue, 16 Mar 1999, Brett Murphy wrote:
  18031. >
  18032. > > Hi All,
  18033. > > Far too regularly I am finding that when I telnet to my HyperARC
  18034. > > it drops the connection immediately. The problem remains until I
  18035. > > powercycle the chassis. Has anyone seen this before?
  18036. >
  18037. > Need to know the version of code you are using - some version of 4.0 and
  18038. > some versions of 4.1 did have some memory problems.  4.1.59 -6 - the
  18039. > latest one in the  web site http://totalservice.usr.com
  18040. > does fix a lot of issues.
  18041. >
  18042. > If you are seeing this problem with 4.1.59 -6 then we need more info -
  18043. > like syslogs
  18044. >
  18045. > krish
  18046. >
  18047. > >
  18048. > > --
  18049. > >
  18050. > > All the best,
  18051. > > Brett Murphy
  18052. > > System Administrator, Alphalink (Australia) PTY LTD
  18053. > > ph: +61 3 9486-8844 fax: +61 3 9486-6822
  18054. > > email: sysadmin@alphalink.com.au
  18055. > >
  18056. > > The contents of this message may not be quoted,
  18057. > > copied, reproduced or published in part or in whole,
  18058. > > without the written authorization of Brett Murphy,
  18059. > > Director, Alphalink (Australia) Pty Ltd.
  18060. > >
  18061. > >
  18062. > >
  18063. > > -
  18064. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18065. > >  with "unsubscribe usr-tc" in the body of the message.
  18066. > >  For information on digests or retrieving files and old messages send
  18067. > >  "help" to the same address.  Do not use quotes in your message.
  18068. > >
  18069.  
  18070. --
  18071.  
  18072. All the best,
  18073. Brett Murphy
  18074. System Administrator, Alphalink (Australia) PTY LTD
  18075. ph: +61 3 9486-8844 fax: +61 3 9486-6822
  18076. email: sysadmin@alphalink.com.au
  18077.  
  18078. The contents of this message may not be quoted,
  18079. copied, reproduced or published in part or in whole,
  18080. without the written authorization of Brett Murphy,
  18081. Director, Alphalink (Australia) Pty Ltd.
  18082.  
  18083.  
  18084.  
  18085. -
  18086.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18087.  with "unsubscribe usr-tc" in the body of the message.
  18088.  For information on digests or retrieving files and old messages send
  18089.  "help" to the same address.  Do not use quotes in your message.
  18090.  
  18091.  
  18092. -------------------------------------------------------------------------------
  18093.  
  18094. From: K Mitchell <mitch@keyconn.net>
  18095. Subject: Re: (usr-tc) random busies
  18096. Date: 15 Mar 1999 20:05:39 -0500
  18097.  
  18098. At 11:46 AM 3/16/99 +1100, Brett Murphy <sysadmin@alphalink.com.au> wrote:
  18099. >We have had these problems occasionally, using E1 in Australia.
  18100. >Definitely a Telco problem in our case.
  18101.  
  18102. That's my first guess as well, but I need to;
  18103. a) Be able to conclusively determine that it is, and
  18104. b) Let them know what the problem is and what might need fixing.
  18105.  
  18106. I'm dealing with Bell Atlantic here and the clue level is highly
  18107. inconsistant at best.
  18108.  
  18109. Thanks,
  18110. Kirk
  18111.  
  18112.  
  18113.  
  18114. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  18115. Keystone Connect                http://www.keyconn.net
  18116. Altoona, PA   814-941-5000         We Unlock the World
  18117.  
  18118.  
  18119. -
  18120.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18121.  with "unsubscribe usr-tc" in the body of the message.
  18122.  For information on digests or retrieving files and old messages send
  18123.  "help" to the same address.  Do not use quotes in your message.
  18124.  
  18125.  
  18126. -------------------------------------------------------------------------------
  18127.  
  18128. From: "Jamie Orzechowski" <mhz@ripnet.com>
  18129. Subject: (usr-tc) ARC Problems?
  18130. Date: 15 Mar 1999 20:26:35 -0500
  18131.  
  18132. I seem to be having ALOT of PPP authentication problems! ... I am running
  18133. that latest ARC code ... 4.1.59-6 .. anyone have any ideas how to fix
  18134. this????
  18135.  
  18136. People will connect and get dropped right away.  When I dial in with a term
  18137. program I will dial and immediatly I will get a authentication failure text
  18138. come up before I have even typed anything ...
  18139.  
  18140. here is a cut & paste
  18141.  
  18142. atdtXXX-XXXX
  18143. CONNECT 115200
  18144.  
  18145. Welcome to 3Com Total Control HiPer ARC (TM)
  18146. Networks That Go The Distance (TM)
  18147. UserName: Authentication failure
  18148.  
  18149. UserName:
  18150.  
  18151.  
  18152.  
  18153. Sometimes PPP starts at the same prompt before I type anything ...
  18154.  
  18155. here is a message an advanced linux user of our system has sent me.
  18156.  
  18157. --start
  18158.  
  18159. hi... it's me again. i've been doing some more playing around trying to
  18160. figure out why the linux 2.2.x series won't allow me to connect.  i
  18161. booted into 2.0.36 yesterday, and i ran minicom (you know, the unix term
  18162. app?)  anyway...  i found that after i dialed, the first prompt for
  18163. authentication would automatically fail, even though i hadn't typed in
  18164. anything yet... on other times (specifically if i got connected at
  18165. 44000) it would start sending PPP garbage like ?~?~?~?~?~... etc... at
  18166. the authentication prompt um... i have a GVC 56k X2 modem... and as far
  18167. as i know it still uses the v.42 protocol.  (upgrade to v.90 requires a
  18168. chip replacement)... does that bring anything to mind as to why maybe i
  18169. can't get connected? i think it at least shows why i've been getting the
  18170. "unsupported protocol" errors from pppd.... thanks.
  18171.  
  18172. --stop
  18173.  
  18174.  
  18175.  
  18176. Have a Great Day!
  18177.  
  18178. Jamie Orzechowski
  18179. RipNET System Admin
  18180.  
  18181. Tel.: 613-342-3946 ext 293
  18182. Tel.: 800-267-4434 ext 293
  18183. Page.: 613-341-0883
  18184. EMail.: mhz@ripnet.com
  18185. Web.: http://www.ripnet.com
  18186. Personal.: http://www.moonchilli.com
  18187.  
  18188.  
  18189.  
  18190.  
  18191. -
  18192.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18193.  with "unsubscribe usr-tc" in the body of the message.
  18194.  For information on digests or retrieving files and old messages send
  18195.  "help" to the same address.  Do not use quotes in your message.
  18196.  
  18197.  
  18198. -------------------------------------------------------------------------------
  18199.  
  18200. From: <vanhalen@coredcs.com>
  18201. Subject: Re: (usr-tc) Switch takes lines out of service
  18202. Date: 15 Mar 1999 21:07:52 -0600 (CST)
  18203.  
  18204. We deal with Ameritech here but have had the same problem.  I'll try to
  18205. answer your questions based upon my experience and their responses to the
  18206. questions.
  18207.  
  18208. Steve
  18209.  
  18210. On Mon, 15 Mar 1999, Randy Cosby wrote:
  18211. > 
  18212. > A few questions:
  18213. > 
  18214. > 1. Is there a way I can "tell" the switch (Lucent 5ESS) to restore the lines
  18215. > through the HDM or T1 card?
  18216.  
  18217. Not with the Ameritech switch(I think Northern Telecom).
  18218.  
  18219. > 2. Is there a way USWest can  set up the switch to automatically "poll" our
  18220. > equipment on a regular basis after an outage and auto-restore if it's there?
  18221.  
  18222. Not with Ameritech, it's a real person that has to restore it to service.
  18223.  
  18224. > 3. Can anyone give me any background information on the switches to explain
  18225. > why it might be taking trunks out of service?
  18226. > 
  18227.  
  18228. From what I understand, when we work on something that has to take a T1
  18229. out of service, an alarm will go on at Ameritech.  After 1 hour with that
  18230. alarm on, someone will switch it to out of service.  We then have to call
  18231. to get them turned back on, much like yourself.
  18232.  
  18233. To get around it we have a small workaround that works for us.  We have an
  18234. incoming channelized DS3 so I go into the mux and Unequip the
  18235. channels(T1's) that I'm going to be working on.  The Equipped/Unequipped
  18236. status doesn't actually turn the service on or off but rather turns off
  18237. the alarm status(it doesn't send the alarm if it's unequipped).  Again
  18238. that's what worked for us, but it is a special situation.
  18239.  
  18240. Steve
  18241.  
  18242.  
  18243. -
  18244.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18245.  with "unsubscribe usr-tc" in the body of the message.
  18246.  For information on digests or retrieving files and old messages send
  18247.  "help" to the same address.  Do not use quotes in your message.
  18248.  
  18249.  
  18250. -------------------------------------------------------------------------------
  18251.  
  18252. From: "Stainforth, Matthew (Sys Mgr - BrunNet)"
  18253. Subject: RE: (usr-tc) Switch takes lines out of service
  18254. Date: 16 Mar 1999 04:35:53 -0400
  18255.  
  18256.  
  18257. I've seen this occasionally when a trunk group has been down for quite a
  18258. while.  According to our telco guys it automatically takes the trunks out of
  18259. service after a period of time.
  18260.  
  18261. However, I think what the original poster was talking about seeing some
  18262. ds0's in an "out of service" state after a chassis power cycle or a NAC
  18263. reset.  I've seen that lots too and sometimes putting the channels "local
  18264. out of service" and then "in service" will bring them back up.  Other times
  18265. I have to get the telco to post the trunks from the switch.  Other than
  18266. that, I don't know..
  18267.  
  18268. -----Original Message-----
  18269. Sent: 3/15/99 11:07 PM
  18270.  
  18271.  
  18272. From what I understand, when we work on something that has to take a T1
  18273. out of service, an alarm will go on at Ameritech.  After 1 hour with
  18274. that
  18275. alarm on, someone will switch it to out of service.  We then have to
  18276. call
  18277. to get them turned back on, much like yourself.
  18278.  
  18279.  
  18280. -
  18281.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18282.  with "unsubscribe usr-tc" in the body of the message.
  18283.  For information on digests or retrieving files and old messages send
  18284.  "help" to the same address.  Do not use quotes in your message.
  18285.  
  18286. -
  18287.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18288.  with "unsubscribe usr-tc" in the body of the message.
  18289.  For information on digests or retrieving files and old messages send
  18290.  "help" to the same address.  Do not use quotes in your message.
  18291.  
  18292.  
  18293. -------------------------------------------------------------------------------
  18294.  
  18295. From: "Ray Bellis" <rpb@community.net.uk>
  18296. Subject: RE: (usr-tc) Radius Server Recommendations??
  18297. Date: 16 Mar 1999 09:16:50 -0000
  18298.  
  18299. This is a multi-part message in MIME format.
  18300.  
  18301. ------=_NextPart_000_0007_01BE6F8D.B9354320
  18302. Content-Type: text/plain;
  18303.     charset="iso-8859-1"
  18304. Content-Transfer-Encoding: 7bit
  18305.  
  18306. > As has been noted here before, the USR Radius server scarcely works.
  18307. > I've been looking at alternatives - in particular Cistron, Merit, and
  18308. > Radiator - and am looking for advice.  What's the best bet in terms of
  18309. > cost, performance, reliability, ease of maintenance, etc.?
  18310.  
  18311. Blowing my own trumpet, I'm afraid, but you might be interested to
  18312. know that we're thinking of launching an extensible RADIUS server
  18313. that we've recently written for in house use as a commercial product.
  18314.  
  18315. The core server would be supplied as Java compiled code which can be
  18316. run on any system capable of running a Java 1.1.x runtime, but the
  18317. special feature is a Java API which system managers can use to write
  18318. simple pluggable extensions which can be chained together to provide
  18319. sophisticated authentication and accounting mechanisms.
  18320.  
  18321. I've already used the API to implement
  18322.  
  18323. o  Access control based on DNIS and JDBC
  18324. o  GRIC roaming proxy
  18325. o  Unix password authentication (uses JNI to access getpwnam)
  18326. o  JDBC password authentication
  18327. o  JDBC attribute setting
  18328. o  JDBC accounting
  18329.  
  18330. I'd be interested in getting feedback from other RADIUS users on
  18331. whether an easily extensible RADIUS server would have any demand
  18332. (commercial or otherwise).
  18333.  
  18334. thanks,
  18335.  
  18336. Ray.
  18337.  
  18338. --
  18339. Ray Bellis, MA(Oxon) - Technical Director - Oxford CommUnity Internet plc
  18340. Windsor House, 12 High Street, Kidlington, OXFORD OX5 2PJ   UK
  18341.       Telephone: +44-1865-856000  Fax: +44-1865-856001
  18342. Email: ray.bellis@community.net.uk   URL: http://www.community.co.uk/ 
  18343. ------=_NextPart_000_0007_01BE6F8D.B9354320
  18344. Content-Type: text/x-vcard;
  18345.     name="Ray Bellis.vcf"
  18346. Content-Transfer-Encoding: quoted-printable
  18347. Content-Disposition: attachment;
  18348.     filename="Ray Bellis.vcf"
  18349.  
  18350. BEGIN:VCARD
  18351. VERSION:2.1
  18352. N:Bellis;Ray;;
  18353. FN:Ray Bellis
  18354. ORG:Oxford CommUnity Internet plc;
  18355. TITLE:Technical Director
  18356. TEL;WORK;VOICE:+44 (1865) 856000
  18357. TEL;WORK;FAX:+44 (1865) 856001
  18358. ADR;WORK;ENCODING=3DQUOTED-PRINTABLE:;;Windsor House=3D0D=3D0A12 High =
  18359. Street;Kidlington;Oxfordshire;OX5 2PJ;United Ki=3D
  18360. ngdom
  18361. LABEL;WORK;ENCODING=3DQUOTED-PRINTABLE:Windsor House=3D0D=3D0A12 High =
  18362. Street=3D0D=3D0AKidlington, Oxfordshire OX5 2PJ=3D0D=3D
  18363. =3D0AUnited Kingdom
  18364. URL:
  18365. URL:http://www.community.co.uk/
  18366. EMAIL;PREF;INTERNET:rpb@community.net.uk
  18367. EMAIL;INTERNET:rpb@community.net.uk
  18368. EMAIL;INTERNET:rpb@community.co.uk
  18369. REV:19990205T105103Z
  18370. END:VCARD
  18371.  
  18372. ------=_NextPart_000_0007_01BE6F8D.B9354320--
  18373.  
  18374.  
  18375. -
  18376.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18377.  with "unsubscribe usr-tc" in the body of the message.
  18378.  For information on digests or retrieving files and old messages send
  18379.  "help" to the same address.  Do not use quotes in your message.
  18380.  
  18381.  
  18382. -------------------------------------------------------------------------------
  18383.  
  18384. From: Stephen Amadei <amadei@dandy.net>
  18385. Subject: (usr-tc) My latest toy TC script...
  18386. Date: 16 Mar 1999 05:47:22 -0500 (EST)
  18387.  
  18388.  
  18389. A couple of days ago, I was inquiring about the LED status on the USR's...
  18390. I'd like to thank everyone who responded, and as I promised, I am sharing
  18391. the fruits of my labor...
  18392.  
  18393. Someone else has probably already done this, but since I couldn't find any
  18394. code like it, I wrote my own...
  18395.  
  18396. A "Total Control Virtual Display Program"  What this does is create
  18397. Gif files that represent your TC units.  This is an early edition... I
  18398. plan on prettying it up later, but it's mostly functional now, but I need
  18399. to write a few other useless toys for my company.  ;-)
  18400.  
  18401. Some limitations:
  18402.  
  18403.  - It creates FOUR gif files for each of your Total Controls.  This is in
  18404.    order to create an animated Gif file in the future, to provide for
  18405.    blinking LEDs.  Disregard the extra GIFs.
  18406.  - It does not support the NetServer... I didn't have one handy when I
  18407.    built this... if someone gives me readonly access to a NetServer
  18408.    equipped TC, I will add it.
  18409.  - It does support the T1 card, Digital Quads, Analog Quads, D-A Quads,
  18410.    Hiper DSP, Hiper ARC, NMC and NMC with clock.  For added cards, see 
  18411.    note above about NetServer.
  18412.  - Requires CMU-SNMP, SNMPWALK, the GD library, GD perl library things and
  18413.    parts of MRTG.
  18414.  - It's absolutely not guarenteed to work anywhere... ;-)
  18415.  
  18416. If you are feeling lucky, you can get the script at
  18417. http://www.dandy.net/~amadei/tcview 
  18418. and see a live demo at
  18419. http://www.dandy.net/statistics/tc.html
  18420.  
  18421. Let me know what you think, and any suggestions.
  18422.  
  18423.                     ----Steve
  18424. Stephen Amadei
  18425. Director of MIS
  18426. Dandy Connections, Inc.
  18427. Atlantic City, NJ
  18428.  
  18429.  
  18430. -
  18431.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18432.  with "unsubscribe usr-tc" in the body of the message.
  18433.  For information on digests or retrieving files and old messages send
  18434.  "help" to the same address.  Do not use quotes in your message.
  18435.  
  18436.  
  18437. -------------------------------------------------------------------------------
  18438.  
  18439. From: "Sam Lowe" <slowe@universalcom.net>
  18440. Subject: (usr-tc) Missing attribute codes
  18441. Date: 16 Mar 1999 06:51:41 -0600
  18442.  
  18443. This is a multi-part message in MIME format.
  18444.  
  18445. ------=_NextPart_000_0534_01BE6F79.72872CE0
  18446. Content-Type: text/plain;
  18447.     charset="iso-8859-1"
  18448. Content-Transfer-Encoding: quoted-printable
  18449.  
  18450.  
  18451. Do any of you fine list members know what the attribute codes 38978 & =
  18452. 38979 refer to.  I suspect they have something to do with the HIPER =
  18453. cards, but can't find this info anywhere.
  18454.  
  18455. TIA.
  18456.  
  18457.  
  18458. Samuel S. Lowe
  18459. Director, Data Network Services
  18460. UniversalCom, Inc.
  18461. slowe@universalcom.net
  18462.  
  18463.  
  18464.  
  18465. ------=_NextPart_000_0534_01BE6F79.72872CE0
  18466. Content-Type: text/html;
  18467.     charset="iso-8859-1"
  18468. Content-Transfer-Encoding: quoted-printable
  18469.  
  18470. <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
  18471. <HTML><HEAD>
  18472. <META content=3Dtext/html;charset=3Diso-8859-1 =
  18473. http-equiv=3DContent-Type>
  18474. <STYLE></STYLE>
  18475.  
  18476. <META content=3D'"MSHTML 5.00.0910.1309"' name=3DGENERATOR></HEAD>
  18477. <BODY bgColor=3D#ffffff>
  18478. <DIV> </DIV>
  18479. <DIV><FONT size=3D2>Do any of you fine list members know what the =
  18480. attribute codes=20
  18481. 38978 & 38979 refer to.  I suspect they have something to do =
  18482. with the=20
  18483. HIPER cards, but can't find this info anywhere.</FONT></DIV>
  18484. <DIV><FONT size=3D2></FONT> </DIV>
  18485. <DIV><FONT size=3D2>TIA.</FONT></DIV>
  18486. <DIV><FONT size=3D2></FONT> </DIV>
  18487. <DIV><FONT size=3D2><BR>Samuel S. Lowe<BR>Director, Data Network=20
  18488. Services<BR>UniversalCom,=20
  18489. Inc.<BR>slowe@universalcom.net<BR><BR></FONT></DIV></BODY></HTML>
  18490.  
  18491. ------=_NextPart_000_0534_01BE6F79.72872CE0--
  18492.  
  18493.  
  18494. -
  18495.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18496.  with "unsubscribe usr-tc" in the body of the message.
  18497.  For information on digests or retrieving files and old messages send
  18498.  "help" to the same address.  Do not use quotes in your message.
  18499.  
  18500.  
  18501. -------------------------------------------------------------------------------
  18502.  
  18503. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  18504. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  18505. Date: 16 Mar 1999 07:16:08 -0600 (CST)
  18506.  
  18507. On Mon, 15 Mar 1999, Douglas Rabe wrote:
  18508.  
  18509. > I have seen it on 4.1.59-0 and 4.1.67-*.  But only on hubs used for
  18510. > DIALOUT.  When I get on the console I see out of memory errors.  All
  18511. > I can do is reboot.  Again, I only see this on a hub used for DIALOUT,
  18512. > never seen it on hiperarcs used for dialin.
  18513.  
  18514.  
  18515. 4.1.59 - 0 - Ans - You need to contact Bill or Mathew.  Please refer to 
  18516. my other email
  18517.  
  18518. krish
  18519.  
  18520. > 
  18521. > -- 
  18522. > Douglas Rabe                UUnet Technologies, Inc.            darabe@ans.net
  18523. > 
  18524. > -
  18525. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18526. >  with "unsubscribe usr-tc" in the body of the message.
  18527. >  For information on digests or retrieving files and old messages send
  18528. >  "help" to the same address.  Do not use quotes in your message.
  18529. > 
  18530.  
  18531. -
  18532.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18533.  with "unsubscribe usr-tc" in the body of the message.
  18534.  For information on digests or retrieving files and old messages send
  18535.  "help" to the same address.  Do not use quotes in your message.
  18536.  
  18537.  
  18538. -------------------------------------------------------------------------------
  18539.  
  18540. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  18541. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  18542. Date: 16 Mar 1999 07:20:33 -0600 (CST)
  18543.  
  18544.  
  18545. On Tue, 16 Mar 1999, Brett Murphy wrote:
  18546.  
  18547. > How emarrasing!
  18548. > I am using 4.1.11
  18549. > I'll install the latest one asap.
  18550.  
  18551. Install the latest - that does have some good fixes.  What I did say was 
  18552. that 4.1.x - certain version has some memory issues.  So that does not 
  18553. means that every version of 4.1.x has problems.
  18554.  
  18555. regards
  18556.  
  18557. krish
  18558.  
  18559. > 
  18560. > Tatai SV Krishnan wrote:
  18561. > 
  18562. > > On Tue, 16 Mar 1999, Brett Murphy wrote:
  18563. > >
  18564. > > > Hi All,
  18565. > > > Far too regularly I am finding that when I telnet to my HyperARC
  18566. > > > it drops the connection immediately. The problem remains until I
  18567. > > > powercycle the chassis. Has anyone seen this before?
  18568. > >
  18569. > > Need to know the version of code you are using - some version of 4.0 and
  18570. > > some versions of 4.1 did have some memory problems.  4.1.59 -6 - the
  18571. > > latest one in the  web site http://totalservice.usr.com
  18572. > > does fix a lot of issues.
  18573. > >
  18574. > > If you are seeing this problem with 4.1.59 -6 then we need more info -
  18575. > > like syslogs
  18576. > >
  18577. > > krish
  18578. > >
  18579. > > >
  18580. > > > --
  18581. > > >
  18582. > > > All the best,
  18583. > > > Brett Murphy
  18584. > > > System Administrator, Alphalink (Australia) PTY LTD
  18585. > > > ph: +61 3 9486-8844 fax: +61 3 9486-6822
  18586. > > > email: sysadmin@alphalink.com.au
  18587. > > >
  18588. > > > The contents of this message may not be quoted,
  18589. > > > copied, reproduced or published in part or in whole,
  18590. > > > without the written authorization of Brett Murphy,
  18591. > > > Director, Alphalink (Australia) Pty Ltd.
  18592. > > >
  18593. > > >
  18594. > > >
  18595. > > > -
  18596. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18597. > > >  with "unsubscribe usr-tc" in the body of the message.
  18598. > > >  For information on digests or retrieving files and old messages send
  18599. > > >  "help" to the same address.  Do not use quotes in your message.
  18600. > > >
  18601. > 
  18602. > --
  18603. > 
  18604. > All the best,
  18605. > Brett Murphy
  18606. > System Administrator, Alphalink (Australia) PTY LTD
  18607. > ph: +61 3 9486-8844 fax: +61 3 9486-6822
  18608. > email: sysadmin@alphalink.com.au
  18609. > 
  18610. > The contents of this message may not be quoted,
  18611. > copied, reproduced or published in part or in whole,
  18612. > without the written authorization of Brett Murphy,
  18613. > Director, Alphalink (Australia) Pty Ltd.
  18614. > 
  18615. > 
  18616. > 
  18617. > -
  18618. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18619. >  with "unsubscribe usr-tc" in the body of the message.
  18620. >  For information on digests or retrieving files and old messages send
  18621. >  "help" to the same address.  Do not use quotes in your message.
  18622. > 
  18623.  
  18624. -
  18625.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18626.  with "unsubscribe usr-tc" in the body of the message.
  18627.  For information on digests or retrieving files and old messages send
  18628.  "help" to the same address.  Do not use quotes in your message.
  18629.  
  18630.  
  18631. -------------------------------------------------------------------------------
  18632.  
  18633. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  18634. Subject: Re: (usr-tc) ARC Problems?
  18635. Date: 16 Mar 1999 07:28:42 -0600 (CST)
  18636.  
  18637. On Mon, 15 Mar 1999, Jamie Orzechowski wrote:
  18638.  
  18639. > I seem to be having ALOT of PPP authentication problems! ... I am running
  18640. > that latest ARC code ... 4.1.59-6 .. anyone have any ideas how to fix
  18641. > this????
  18642.  
  18643. Do please refer to the release notes and make sure that 
  18644.  
  18645. ppp offloading is enabled
  18646. disable ppp receive accm
  18647.  
  18648. > 
  18649. > People will connect and get dropped right away.  When I dial in with a term
  18650. > program I will dial and immediatly I will get a authentication failure text
  18651. > come up before I have even typed anything ...
  18652. > 
  18653. > here is a cut & paste
  18654. > 
  18655. > atdtXXX-XXXX
  18656. > CONNECT 115200
  18657. > 
  18658. > Welcome to 3Com Total Control HiPer ARC (TM)
  18659. > Networks That Go The Distance (TM)
  18660. > UserName: Authentication failure
  18661. > 
  18662. > UserName:
  18663. > 
  18664. > 
  18665.  
  18666. This is something wrong here - I would suspect config.  Either the client 
  18667. or the modem_group is configured wrong.
  18668.  
  18669. you can do a tap on the port and find out what is happening.
  18670.  
  18671. krish
  18672.  
  18673.  
  18674. > 
  18675. > Sometimes PPP starts at the same prompt before I type anything ...
  18676. > 
  18677. > here is a message an advanced linux user of our system has sent me.
  18678. > 
  18679. > --start
  18680. > 
  18681. > hi... it's me again. i've been doing some more playing around trying to
  18682. > figure out why the linux 2.2.x series won't allow me to connect.  i
  18683. > booted into 2.0.36 yesterday, and i ran minicom (you know, the unix term
  18684. > app?)  anyway...  i found that after i dialed, the first prompt for
  18685. > authentication would automatically fail, even though i hadn't typed in
  18686. > anything yet... on other times (specifically if i got connected at
  18687. > 44000) it would start sending PPP garbage like ?~?~?~?~?~... etc... at
  18688. > the authentication prompt um... i have a GVC 56k X2 modem... and as far
  18689. > as i know it still uses the v.42 protocol.  (upgrade to v.90 requires a
  18690. > chip replacement)... does that bring anything to mind as to why maybe i
  18691. > can't get connected? i think it at least shows why i've been getting the
  18692. > "unsupported protocol" errors from pppd.... thanks.
  18693. > 
  18694. > --stop
  18695. > 
  18696. > 
  18697. > 
  18698. > ---------------------------------------------------
  18699. > Have a Great Day!
  18700. > 
  18701. > Jamie Orzechowski
  18702. > RipNET System Admin
  18703. > 
  18704. > Tel.: 613-342-3946 ext 293
  18705. > Tel.: 800-267-4434 ext 293
  18706. > Page.: 613-341-0883
  18707. > EMail.: mhz@ripnet.com
  18708. > Web.: http://www.ripnet.com
  18709. > Personal.: http://www.moonchilli.com
  18710. > ---------------------------------------------------
  18711. > 
  18712. > 
  18713. > 
  18714. > 
  18715. > -
  18716. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18717. >  with "unsubscribe usr-tc" in the body of the message.
  18718. >  For information on digests or retrieving files and old messages send
  18719. >  "help" to the same address.  Do not use quotes in your message.
  18720. > 
  18721.  
  18722. -
  18723.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18724.  with "unsubscribe usr-tc" in the body of the message.
  18725.  For information on digests or retrieving files and old messages send
  18726.  "help" to the same address.  Do not use quotes in your message.
  18727.  
  18728.  
  18729. -------------------------------------------------------------------------------
  18730.  
  18731. From: david@carolnet.com (David Swearingin)
  18732. Subject: (usr-tc)How to turn off @anything.com
  18733. Date: 16 Mar 1999 08:44:43 -0600
  18734.  
  18735. Is there a way to stop S&A manager from authenticating a user who adds
  18736. @domain.com or @anything.com to their correct user name from being
  18737. authenticated?  Some users get confused and instead using just their user
  18738. name they use their email address, or something that looks like it.  As
  18739. long as the name in front of the @ is a valid user name, they get
  18740. authenticated.  The problem is that an entry is made in the CALLS table for
  18741. each unique name they enter and their actual usage is spread out over all
  18742. the names they have used.
  18743.  
  18744. Thanks.
  18745.  
  18746. David
  18747. __________________________________________________
  18748. David Swearingin (david@carolnet.com)
  18749. CARROLLTON INTERNET SERVICE (www.carolnet.com)
  18750. First Financial Group, Inc.
  18751. 11 N. Folger, Carrollton, MO  64633
  18752. 816-542-3002   Fax 816-542-3003
  18753.  
  18754. -
  18755.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18756.  with "unsubscribe usr-tc" in the body of the message.
  18757.  For information on digests or retrieving files and old messages send
  18758.  "help" to the same address.  Do not use quotes in your message.
  18759.  
  18760.  
  18761. -------------------------------------------------------------------------------
  18762.  
  18763. From: Pete Ashdown <pashdown@xmission.com>
  18764. Subject: Re: (usr-tc)How to turn off @anything.com
  18765. Date: 16 Mar 1999 09:05:32 -0700 (MST)
  18766.  
  18767. David Swearingin said once upon a time:
  18768. >
  18769. >Is there a way to stop S&A manager from authenticating a user who adds
  18770. >@domain.com or @anything.com to their correct user name from being
  18771. >authenticated?  Some users get confused and instead using just their user
  18772. >name they use their email address, or something that looks like it.  As
  18773. >long as the name in front of the @ is a valid user name, they get
  18774. >authenticated.  The problem is that an entry is made in the CALLS table for
  18775. >each unique name they enter and their actual usage is spread out over all
  18776. >the names they have used.
  18777.  
  18778. Get a RADIUS with the source code.  It wouldn't take much to modify it to
  18779. do this.
  18780.  
  18781. -
  18782.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18783.  with "unsubscribe usr-tc" in the body of the message.
  18784.  For information on digests or retrieving files and old messages send
  18785.  "help" to the same address.  Do not use quotes in your message.
  18786.  
  18787.  
  18788. -------------------------------------------------------------------------------
  18789.  
  18790. From: Jeff Mcadams <jeffm@iglou.com>
  18791. Subject: (usr-tc) IP Pool aggregation on Arc
  18792. Date: 16 Mar 1999 11:12:46 -0500 (EST)
  18793.  
  18794. OK folks...
  18795.  
  18796. latest question.
  18797.  
  18798. If I want to set up my IP Pools on arcs to aggregate, does the
  18799. initial_pool_address need to be the network address of the aggregate
  18800. route?  or does it need to be the initial host address in the "subnet"?
  18801.  
  18802. ie, let's say I want a pool with approximately 30 addresses in it...I'd
  18803. like it advertised as a single /27, do I do:
  18804. add ip pool dialup initial_pool_address x.y.z.32 size 32 state public 
  18805.     route aggregate
  18806. or:
  18807. add ip pool dialup initial_pool_address x.y.z.33 size 30 state public
  18808.     route aggregate
  18809.  
  18810. Which of those would result in the correct behavior?  I'm hoping the
  18811. first since that would result in fewer wasted IP addresses, but so far I
  18812. can't seem to get that to aggregate and I'm not sure what I'm missing.
  18813. -- 
  18814. Jeff McAdams                            Email: jeffm@iglou.com
  18815. Head Network Administrator              Voice: (502) 966-3848
  18816. IgLou Internet Services                        (800) 436-4456
  18817.  
  18818. -
  18819.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18820.  with "unsubscribe usr-tc" in the body of the message.
  18821.  For information on digests or retrieving files and old messages send
  18822.  "help" to the same address.  Do not use quotes in your message.
  18823.  
  18824.  
  18825. -------------------------------------------------------------------------------
  18826.  
  18827. From: Pete Ashdown <pashdown@xmission.com>
  18828. Subject: Re: (usr-tc) Filtering on HyperARC
  18829. Date: 16 Mar 1999 09:18:25 -0700 (MST)
  18830.  
  18831. Brett Murphy said once upon a time:
  18832. >
  18833. >Hi All,
  18834. >Has anyone got some sample filters or FAQ's for filtering on
  18835. >the HyperARC?
  18836. >For example, blocking the BO port on 31337 etc
  18837.  
  18838. Here's what I use for email-only dialup.  It also allows them to access our
  18839. web server.  I'd be curious as to anyone coming up with a "default" filter
  18840. for dialup that does block things like BackOrifice.
  18841.  
  18842.  
  18843. mail.in:
  18844.  
  18845. #filter
  18846. IP:
  18847. 010 AND dst-addr = 198.060.022.022/32;
  18848. 020 ACCEPT tcp-dst-port = 106;
  18849. 030 AND dst-addr = 198.060.022.022/32;
  18850. 040 ACCEPT tcp-dst-port = 109;
  18851. 050 AND dst-addr = 198.060.022.022/32;
  18852. 060 ACCEPT tcp-dst-port = 110;
  18853. 070 AND dst-addr = 198.060.022.022/32;
  18854. 080 ACCEPT tcp-dst-port = 143;
  18855. 090 AND dst-addr = 198.060.022.022/32;
  18856. 100 ACCEPT tcp-dst-port = 25;
  18857. 110 AND dst-addr = 198.060.022.022/32;
  18858. 120 ACCEPT udp-dst-port = 53;
  18859. 130 AND dst-addr = 198.060.022.002/32;
  18860. 140 ACCEPT udp-dst-port = 53;
  18861. 150 AND dst-addr = 198.060.022.000/26;
  18862. 160 ACCEPT tcp-dst-port = 80;
  18863. 170 AND dst-addr = 198.060.022.000/26;
  18864. 180 ACCEPT tcp-dst-port = 8000;
  18865. 190 AND dst-addr = 198.060.022.000/26;
  18866. 200 ACCEPT tcp-dst-port = 443;
  18867. 210 ACCEPT protocol = icmp;
  18868. 220 DENY;
  18869.  
  18870.  
  18871. mail.out:
  18872. #filter
  18873. IP:
  18874. 010 AND src-addr = 198.060.022.0/26;
  18875. 020 ACCEPT protocol = tcp;
  18876. 030 AND src-addr = 198.060.022.002/32;
  18877. 040 ACCEPT udp-src-port = 53;
  18878. 050 AND src-addr = 198.060.022.022/32;
  18879. 060 ACCEPT udp-src-port = 53;
  18880. 070 ACCEPT protocol = icmp;
  18881. 080 DENY;
  18882.  
  18883. -
  18884.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18885.  with "unsubscribe usr-tc" in the body of the message.
  18886.  For information on digests or retrieving files and old messages send
  18887.  "help" to the same address.  Do not use quotes in your message.
  18888.  
  18889.  
  18890. -------------------------------------------------------------------------------
  18891.  
  18892. From: Erick_Mancera@3com.com
  18893. Subject: (usr-tc) Ascend Attributes
  18894. Date: 16 Mar 1999 10:23:07 -0600
  18895.  
  18896.  
  18897.  
  18898. If I set the Radius Attributes to Ascend, what are the attributes that change??
  18899.  
  18900. Specifically, I'm trying to generate the next accounting attributes:
  18901.  
  18902. 190 Ascend-Pre-Input-Octects
  18903. 191 Ascend-Pre-Output-Octects
  18904. 192 Ascend-Pre-Input-Packets
  18905. 193 Ascend-Pre-Output-Packets
  18906. 195 Ascend-Disconnect-Cause
  18907. 196 Ascend-Connect-Progress
  18908. 197 Ascend-Data-Rate
  18909. 198 Ascend-PreSession-Time
  18910.  
  18911. Thank you in advance,
  18912. Best Regards,
  18913. Erick Mancera
  18914.  
  18915.  
  18916.  
  18917. -
  18918.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18919.  with "unsubscribe usr-tc" in the body of the message.
  18920.  For information on digests or retrieving files and old messages send
  18921.  "help" to the same address.  Do not use quotes in your message.
  18922.  
  18923.  
  18924. -------------------------------------------------------------------------------
  18925.  
  18926. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  18927. Subject: RE: (usr-tc)How to turn off @anything.com
  18928. Date: 16 Mar 1999 10:22:39 -0600
  18929.  
  18930. S&A uses a scripting language. You can edit the script to crop off the domain
  18931. information for all logins..
  18932.  
  18933. -M
  18934.  
  18935.  
  18936. |-----Original Message-----
  18937. |From: owner-usr-tc@lists.xmission.com
  18938. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Swearingin
  18939. |Sent: Tuesday, March 16, 1999 8:45 AM
  18940. |To: usr-tc@lists.xmission.com
  18941. |Subject: (usr-tc)How to turn off @anything.com
  18942. |
  18943. |
  18944. |Is there a way to stop S&A manager from authenticating a user who adds
  18945. |@domain.com or @anything.com to their correct user name from being
  18946. |authenticated?  Some users get confused and instead using just their user
  18947. |name they use their email address, or something that looks like it.  As
  18948. |long as the name in front of the @ is a valid user name, they get
  18949. |authenticated.  The problem is that an entry is made in the CALLS table for
  18950. |each unique name they enter and their actual usage is spread out over all
  18951. |the names they have used.
  18952. |
  18953. |Thanks.
  18954. |
  18955. |David
  18956. |__________________________________________________
  18957. |David Swearingin (david@carolnet.com)
  18958. |CARROLLTON INTERNET SERVICE (www.carolnet.com)
  18959. |First Financial Group, Inc.
  18960. |11 N. Folger, Carrollton, MO  64633
  18961. |816-542-3002   Fax 816-542-3003
  18962. |
  18963. |-
  18964. | To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18965. | with "unsubscribe usr-tc" in the body of the message.
  18966. | For information on digests or retrieving files and old messages send
  18967. | "help" to the same address.  Do not use quotes in your message.
  18968. |
  18969.  
  18970.  
  18971. -
  18972.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  18973.  with "unsubscribe usr-tc" in the body of the message.
  18974.  For information on digests or retrieving files and old messages send
  18975.  "help" to the same address.  Do not use quotes in your message.
  18976.  
  18977.  
  18978. -------------------------------------------------------------------------------
  18979.  
  18980. From: Pete Ashdown <pashdown@xmission.com>
  18981. Subject: Re: (usr-tc) random busies
  18982. Date: 16 Mar 1999 09:27:29 -0700 (MST)
  18983.  
  18984. K Mitchell said once upon a time:
  18985. >
  18986. >  Recently I've been getting sporadic complaints of busy signals from
  18987. >customers during times when our modem usage is signaficantly lower than
  18988. >100%. This is also not normally following a period in which most or all
  18989. >modems were in use. After talking in depth with some of these customers,
  18990. >the bsuies seem to be normally generated busy signals, not fast busies. I
  18991. >have PRIs coming into HiPer DSP 1.2.60, ARC 4.1.72, NMC 5.5.5. Is this a
  18992. >DSP/SRC issue, or possibly telco? Any suggestions/ideas appreciated.
  18993.  
  18994. We have this problem, and it is mainly due to the fact that our current
  18995. PRIs (soon to change) are in a sequential hunt.  That is, it fills up
  18996. bottom to top, rather than using the more desired "least-used channel"
  18997. algorithm.
  18998.  
  18999. What will periodically happen is that a channel on a DSP will get stuck in
  19000. a weird state, and it won't allow calls to go past it.  The callers will
  19001. then receive "out-of-order" or fast busies.  Thankfully, in this situation,
  19002. the "calls failed" will still increment for each busy signal generated.  My
  19003. solution has been to use a script that will run the "calls failed" vs. the
  19004. "calls connected" stat and busy out the PRI when it reaches a certain
  19005. threshold.  Then it waits for the calls to disconnect and it hardware
  19006. resets the card.
  19007.  
  19008. Keeping the DSP's happy is like spinning plates.  Once they all get into
  19009. the right mindset, this doesn't happen very often.  However, if power gets
  19010. cut to your rack, you have to start all over again.
  19011.  
  19012.  
  19013. -
  19014.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19015.  with "unsubscribe usr-tc" in the body of the message.
  19016.  For information on digests or retrieving files and old messages send
  19017.  "help" to the same address.  Do not use quotes in your message.
  19018.  
  19019.  
  19020. -------------------------------------------------------------------------------
  19021.  
  19022. From: Pete Ashdown <pashdown@xmission.com>
  19023. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  19024. Date: 16 Mar 1999 09:32:25 -0700 (MST)
  19025.  
  19026. >ie, let's say I want a pool with approximately 30 addresses in it...I'd
  19027. >like it advertised as a single /27, do I do:
  19028. >add ip pool dialup initial_pool_address x.y.z.32 size 32 state public 
  19029. >    route aggregate
  19030. >or:
  19031. >add ip pool dialup initial_pool_address x.y.z.33 size 30 state public
  19032. >    route aggregate
  19033. >
  19034. >Which of those would result in the correct behavior?  I'm hoping the
  19035. >first since that would result in fewer wasted IP addresses, but so far I
  19036. >can't seem to get that to aggregate and I'm not sure what I'm missing.
  19037.  
  19038. Theoretically, this should work, since your router sees it as a subnet and
  19039. your ARC sees them as host-routes.  However, it is still illegal to have a
  19040. device on the subnet number.  I suspect that the ARC is simply trying to
  19041. keep you out of trouble.  It would definitely be bad for the person
  19042. connecting up with the broadcast address.
  19043.  
  19044. -
  19045.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19046.  with "unsubscribe usr-tc" in the body of the message.
  19047.  For information on digests or retrieving files and old messages send
  19048.  "help" to the same address.  Do not use quotes in your message.
  19049.  
  19050.  
  19051. -------------------------------------------------------------------------------
  19052.  
  19053. From: "Jamie Orzechowski" <mhz@recorder.ca>
  19054. Subject: (usr-tc) Radius Probs
  19055. Date: 16 Mar 1999 11:34:44 -0500
  19056.  
  19057. anyone know how to fix this?
  19058.  
  19059. when a user dials into the system via a tem program and they type their
  19060. userID and password they will ALWAYS get a authenticaton faliure.  Their
  19061. username is stored in /etc/passwd and radius is told that the DEFAULT user
  19062. is Unix-PW.
  19063.  
  19064. They can login fine with PAP ....
  19065.  
  19066.  
  19067. now if the user has an entry in the radius users file and the type in their
  19068. name and password via hyperterm they will get the PPP session start.
  19069.  
  19070. What I would like to know is how can I make it so that ALL users will get a
  19071. PPP session start even if they are stored in /etc/passwd ... I believe this
  19072. is a radius problem .. any ideas??
  19073.  
  19074. here is my DEFAULT radius user
  19075.  
  19076. DEFAULT         Authentication-Type= Unix-PW, Framed-Protocol= PPP,
  19077. Simultaneous-use= 2
  19078.  
  19079.  
  19080.  
  19081. -
  19082.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19083.  with "unsubscribe usr-tc" in the body of the message.
  19084.  For information on digests or retrieving files and old messages send
  19085.  "help" to the same address.  Do not use quotes in your message.
  19086.  
  19087.  
  19088. -------------------------------------------------------------------------------
  19089.  
  19090. From: Ralph Helfenberger <rhelfenberger@comlight.ch>
  19091. Subject: (usr-tc) Securing Access for Netserver Port
  19092. Date: 16 Mar 1999 17:47:14 +0100
  19093.  
  19094. I have a question concerning Netserver. How do you secure the 
  19095. access to the Ethernet port from intruders? Do you use add snmp host
  19096. writer <ip> command (wich doesn't seem to do anything in my
  19097. environment? How do you secure Telnet access?
  19098.  
  19099. Thanks for the input
  19100.  
  19101. Ralph
  19102.  
  19103. -
  19104.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19105.  with "unsubscribe usr-tc" in the body of the message.
  19106.  For information on digests or retrieving files and old messages send
  19107.  "help" to the same address.  Do not use quotes in your message.
  19108.  
  19109.  
  19110. -------------------------------------------------------------------------------
  19111.  
  19112. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  19113. Subject: Re: (usr-tc) Radius Probs
  19114. Date: 16 Mar 1999 10:59:14 -0600 (CST)
  19115.  
  19116. On Tue, 16 Mar 1999, Jamie Orzechowski wrote:
  19117.  
  19118. > anyone know how to fix this?
  19119. > 
  19120. > when a user dials into the system via a tem program and they type their
  19121. > userID and password they will ALWAYS get a authenticaton faliure.  Their
  19122. > username is stored in /etc/passwd and radius is told that the DEFAULT user
  19123. > is Unix-PW.
  19124. > 
  19125. > They can login fine with PAP ....
  19126. > 
  19127. If you are using /etc/passwd for users - then you will get authenticated 
  19128. only using PAP.  
  19129.  
  19130. you have to set the hiper arc to have the authentication preference as PAP
  19131.  
  19132. krish
  19133.  
  19134.  
  19135. > 
  19136. > now if the user has an entry in the radius users file and the type in their
  19137. > name and password via hyperterm they will get the PPP session start.
  19138. > 
  19139. > What I would like to know is how can I make it so that ALL users will get a
  19140. > PPP session start even if they are stored in /etc/passwd ... I believe this
  19141. > is a radius problem .. any ideas??
  19142. > 
  19143. > here is my DEFAULT radius user
  19144. > 
  19145. > DEFAULT         Authentication-Type= Unix-PW, Framed-Protocol= PPP,
  19146. > Simultaneous-use= 2
  19147. > 
  19148. > 
  19149. > 
  19150. > -
  19151. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19152. >  with "unsubscribe usr-tc" in the body of the message.
  19153. >  For information on digests or retrieving files and old messages send
  19154. >  "help" to the same address.  Do not use quotes in your message.
  19155. > 
  19156.  
  19157. -
  19158.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19159.  with "unsubscribe usr-tc" in the body of the message.
  19160.  For information on digests or retrieving files and old messages send
  19161.  "help" to the same address.  Do not use quotes in your message.
  19162.  
  19163.  
  19164. -------------------------------------------------------------------------------
  19165.  
  19166. From: "Matt Harper" <Matt_Harper@mw.3com.com>
  19167. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  19168. Date: 16 Mar 1999 10:53:33 -0600
  19169.  
  19170.  
  19171.  
  19172.  
  19173. Pete's assessment of the ARC behavior is correct.  The ARC does not allow the
  19174. lowest and
  19175. highest address of a subnet to be used for the user as these are not legal
  19176. addresses on the subset
  19177. defined by the pool.  It enforces these rules so that users don't end up with
  19178. bizzare behavior.
  19179.  
  19180. -- Matt
  19181.  
  19182.  
  19183.  
  19184.  
  19185.  
  19186.  
  19187.  
  19188.  
  19189. Pete Ashdown <pashdown@xmission.com> on 03/16/99 10:32:25 AM
  19190.  
  19191. Please respond to usr-tc@lists.xmission.com
  19192.  
  19193. cc:    (Matt Harper/MW/US/3Com)
  19194.  
  19195.  
  19196.  
  19197.  
  19198. >ie, let's say I want a pool with approximately 30 addresses in it...I'd
  19199. >like it advertised as a single /27, do I do:
  19200. >add ip pool dialup initial_pool_address x.y.z.32 size 32 state public
  19201. >    route aggregate
  19202. >or:
  19203. >add ip pool dialup initial_pool_address x.y.z.33 size 30 state public
  19204. >    route aggregate
  19205. >
  19206. >Which of those would result in the correct behavior?  I'm hoping the
  19207. >first since that would result in fewer wasted IP addresses, but so far I
  19208. >can't seem to get that to aggregate and I'm not sure what I'm missing.
  19209.  
  19210. Theoretically, this should work, since your router sees it as a subnet and
  19211. your ARC sees them as host-routes.  However, it is still illegal to have a
  19212. device on the subnet number.  I suspect that the ARC is simply trying to
  19213. keep you out of trouble.  It would definitely be bad for the person
  19214. connecting up with the broadcast address.
  19215.  
  19216. -
  19217.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19218.  with "unsubscribe usr-tc" in the body of the message.
  19219.  For information on digests or retrieving files and old messages send
  19220.  "help" to the same address.  Do not use quotes in your message.
  19221.  
  19222.  
  19223.  
  19224.  
  19225.  
  19226.  
  19227.  
  19228.  
  19229. -
  19230.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19231.  with "unsubscribe usr-tc" in the body of the message.
  19232.  For information on digests or retrieving files and old messages send
  19233.  "help" to the same address.  Do not use quotes in your message.
  19234.  
  19235.  
  19236. -------------------------------------------------------------------------------
  19237.  
  19238. From: "Matt Harper" <Matt_Harper@mw.3com.com>
  19239. Subject: Re: (usr-tc) Missing attribute codes
  19240. Date: 16 Mar 1999 11:00:56 -0600
  19241.  
  19242. --0__=CGI2djvzSJsm5vPsT8wsqqG2xN3bVMRZql0pOrx5P9doHoi8tqwbPvxU
  19243. Content-type: text/plain; charset=us-ascii
  19244. Content-Disposition: inline
  19245.  
  19246.  
  19247.  
  19248.  
  19249.  
  19250. RAD_MODEM_TRAINING_TIME       0x9842   - Modem training time
  19251.  RAD_IF_INDEX                                           0x9843   - SNMP MIB-II
  19252. interface # (not RADIUS port #)
  19253.  
  19254. -- Matt
  19255.  
  19256.  
  19257.  
  19258.  
  19259.  
  19260. "Sam Lowe" <slowe@universalcom.net> on 03/16/99 06:51:41 AM
  19261.  
  19262. Please respond to usr-tc@lists.xmission.com
  19263.  
  19264. cc:    (Matt Harper/MW/US/3Com)
  19265.  
  19266.  
  19267.  
  19268.  
  19269.  
  19270. Do any of you fine list members know what the attribute codes 38978 & 38979
  19271. refer to.  I suspect they have something to do with the HIPER cards, but can't
  19272. find this info anywhere.
  19273.  
  19274. TIA.
  19275.  
  19276.  
  19277. Samuel S. Lowe
  19278. Director, Data Network Services
  19279. UniversalCom, Inc.
  19280. slowe@universalcom.net
  19281.  
  19282.  
  19283.  
  19284. --0__=CGI2djvzSJsm5vPsT8wsqqG2xN3bVMRZql0pOrx5P9doHoi8tqwbPvxU
  19285. Content-type: text/html; 
  19286.     name="att1.htm"
  19287. Content-Disposition: attachment; filename="att1.htm"
  19288. Content-transfer-encoding: base64
  19289. Content-Description: Internet HTML
  19290.  
  19291. PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBXMyBIVE1MLy9FTiI+DQo8SFRNTD48
  19292. SEVBRD4NCjxNRVRBIGNvbnRlbnQ9dGV4dC9odG1sO2NoYXJzZXQ9aXNvLTg4NTktMSBodHRwLWVx
  19293. dWl2PUNvbnRlbnQtVHlwZT4NCjxTVFlMRT48L1NUWUxFPg0KDQo8TUVUQSBjb250ZW50PSciTVNI
  19294. VE1MIDUuMDAuMDkxMC4xMzA5IicgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgYmdDb2xv
  19295. cj0jZmZmZmZmPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkRvIGFueSBv
  19296. ZiB5b3UgZmluZSBsaXN0IG1lbWJlcnMga25vdyB3aGF0IHRoZSBhdHRyaWJ1dGUgY29kZXMgDQoz
  19297. ODk3OCAmYW1wOyAzODk3OSByZWZlciB0by4mbmJzcDsgSSBzdXNwZWN0IHRoZXkgaGF2ZSBzb21l
  19298. dGhpbmcgdG8gZG8gd2l0aCB0aGUgDQpISVBFUiBjYXJkcywgYnV0IGNhbid0IGZpbmQgdGhpcyBp
  19299. bmZvIGFueXdoZXJlLjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJz
  19300. cDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPlRJQS48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05U
  19301. IHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48QlI+U2FtdWVs
  19302. IFMuIExvd2U8QlI+RGlyZWN0b3IsIERhdGEgTmV0d29yayANClNlcnZpY2VzPEJSPlVuaXZlcnNh
  19303. bENvbSwgDQpJbmMuPEJSPnNsb3dlQHVuaXZlcnNhbGNvbS5uZXQ8QlI+PEJSPjwvRk9OVD48L0RJ
  19304. Vj48L0JPRFk+PC9IVE1MPg0K
  19305.  
  19306. --0__=CGI2djvzSJsm5vPsT8wsqqG2xN3bVMRZql0pOrx5P9doHoi8tqwbPvxU--
  19307.  
  19308.  
  19309. -
  19310.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19311.  with "unsubscribe usr-tc" in the body of the message.
  19312.  For information on digests or retrieving files and old messages send
  19313.  "help" to the same address.  Do not use quotes in your message.
  19314.  
  19315.  
  19316. -------------------------------------------------------------------------------
  19317.  
  19318. From: Jeff Mcadams <jeffm@iglou.com>
  19319. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  19320. Date: 16 Mar 1999 12:05:18 -0500 (EST)
  19321.  
  19322. Thus spake Pete Ashdown
  19323. >>ie, let's say I want a pool with approximately 30 addresses in it...I'd
  19324. >>like it advertised as a single /27, do I do:
  19325. >>add ip pool dialup initial_pool_address x.y.z.32 size 32 state public 
  19326. >>    route aggregate
  19327. >>or:
  19328. >>add ip pool dialup initial_pool_address x.y.z.33 size 30 state public
  19329. >>    route aggregate
  19330. >>
  19331. >>Which of those would result in the correct behavior?  I'm hoping the
  19332. >>first since that would result in fewer wasted IP addresses, but so far I
  19333. >>can't seem to get that to aggregate and I'm not sure what I'm missing.
  19334.  
  19335. >Theoretically, this should work, since your router sees it as a subnet and
  19336. >your ARC sees them as host-routes.  However, it is still illegal to have a
  19337. >device on the subnet number.  I suspect that the ARC is simply trying to
  19338. >keep you out of trouble.  It would definitely be bad for the person
  19339. >connecting up with the broadcast address.
  19340.  
  19341. We're on point-to-point links routed as /32's though, there's no concept 
  19342. of broadcast address.
  19343.  
  19344. Here's the scenario.
  19345.  
  19346. eth:1 on the arc is x.y.z.3/24
  19347. eth 1/1/2 on the cisco is x.y.z.1/24
  19348. with the ip pool as above, none of the addresses in the pool are on the
  19349. network or broadcast address of the ethernet, so no problem.  The Cisco
  19350. would see the route as x.y.z.32/27 with a next hop of x.y.z.3.  The
  19351. Cisco handles this with no problem.  Then internally, the arc sees the
  19352. addresses in the pool as /32's.
  19353.  
  19354. Long and short of it is that there's nothing illegal about this setup.
  19355. The Cisco doesn't know what the ultimate subnet'ing of the end networks
  19356. are like, so if forwards to the next hop of the route even the all zeros
  19357. address.  This is confirmed BTW.  The Cisco has to assume that the
  19358. ultimate addresses might be "subnetted" down to /32 possibly (in this
  19359. case they are) so it forwards even all-zeros and all-ones for the routes
  19360. it has.
  19361. -- 
  19362. Jeff McAdams                            Email: jeffm@iglou.com
  19363. Head Network Administrator              Voice: (502) 966-3848
  19364. IgLou Internet Services                        (800) 436-4456
  19365.  
  19366. -
  19367.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19368.  with "unsubscribe usr-tc" in the body of the message.
  19369.  For information on digests or retrieving files and old messages send
  19370.  "help" to the same address.  Do not use quotes in your message.
  19371.  
  19372.  
  19373. -------------------------------------------------------------------------------
  19374.  
  19375. From: Jeff Mcadams <jeffm@iglou.com>
  19376. Subject: Re: (usr-tc) Radius Probs
  19377. Date: 16 Mar 1999 12:07:49 -0500 (EST)
  19378.  
  19379. Thus spake Jamie Orzechowski
  19380. >DEFAULT         Authentication-Type= Unix-PW, Framed-Protocol= PPP,
  19381. >Simultaneous-use= 2                           ^^^^^^^^^^^^^^^^^^^^
  19382.  
  19383. There's your problem...you're saying, only allow them to log in if they
  19384. have a Framed-Protocol of PPP.  At the time that they're typing in their
  19385. userid and password to the login prompt, they *aren't* running PPP, so
  19386. it rightly denies them.
  19387. -- 
  19388. Jeff McAdams                            Email: jeffm@iglou.com
  19389. Head Network Administrator              Voice: (502) 966-3848
  19390. IgLou Internet Services                        (800) 436-4456
  19391.  
  19392. -
  19393.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19394.  with "unsubscribe usr-tc" in the body of the message.
  19395.  For information on digests or retrieving files and old messages send
  19396.  "help" to the same address.  Do not use quotes in your message.
  19397.  
  19398.  
  19399. -------------------------------------------------------------------------------
  19400.  
  19401. From: Jeff Mcadams <jeffm@iglou.com>
  19402. Subject: Re: (usr-tc) Radius Probs
  19403. Date: 16 Mar 1999 12:09:42 -0500 (EST)
  19404.  
  19405. Thus spake Tatai SV Krishnan
  19406. >On Tue, 16 Mar 1999, Jamie Orzechowski wrote:
  19407. >> anyone know how to fix this?
  19408. >> 
  19409. >> when a user dials into the system via a tem program and they type their
  19410. >> userID and password they will ALWAYS get a authenticaton faliure.  Their
  19411. >> username is stored in /etc/passwd and radius is told that the DEFAULT user
  19412. >> is Unix-PW.
  19413. >> 
  19414. >> They can login fine with PAP ....
  19415. >> 
  19416. >If you are using /etc/passwd for users - then you will get authenticated 
  19417. >only using PAP.  
  19418.  
  19419. A bit of a misstatement...you can't use CHAP because CHAP requires
  19420. clear-text password storage...which /etc/passwd doesn't have.  You
  19421. *can* login from a clear-text login prompt which I believe is what Jamie
  19422. was asking.
  19423. -- 
  19424. Jeff McAdams                            Email: jeffm@iglou.com
  19425. Head Network Administrator              Voice: (502) 966-3848
  19426. IgLou Internet Services                        (800) 436-4456
  19427.  
  19428. -
  19429.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19430.  with "unsubscribe usr-tc" in the body of the message.
  19431.  For information on digests or retrieving files and old messages send
  19432.  "help" to the same address.  Do not use quotes in your message.
  19433.  
  19434.  
  19435. -------------------------------------------------------------------------------
  19436.  
  19437. From: Jeff Mcadams <jeffm@iglou.com>
  19438. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  19439. Date: 16 Mar 1999 12:13:55 -0500 (EST)
  19440.  
  19441. Thus spake Matt Harper
  19442. >Pete's assessment of the ARC behavior is correct.  The ARC does not allow the
  19443. >lowest and
  19444. >highest address of a subnet to be used for the user as these are not legal
  19445. >addresses on the subset
  19446. >defined by the pool.  
  19447.  
  19448. Not true, since the Arc, once the users are logged in on PPP
  19449. connections, is going to see them as /32's where there is no concept of
  19450. network address, broadcast address, all ones address and all zeros
  19451. address.  The Cisco handles this correctly, if it has a route to:
  19452. x.y.z.32/27 with a next hop of x.y.z.3, (which is what I want my
  19453. situation to be) and it gets a packet with a dest address of x.y.z.32,
  19454. it correctly forwards the packet on to x.y.z.3.  Again, this is because
  19455. the Cisco doesn't know what the ultimate network mask is for the user,
  19456. if its /32, the address *is* legal, so it forwards it on.
  19457.  
  19458. >It enforces these rules so that users don't end up with
  19459. >bizzare behavior.
  19460.  
  19461. And ends up making people eat up more IP addresses if they want to
  19462. aggregate their IP pools.  For me to set up this chassis then (a
  19463. double-up chassis basically, 12 quads, 2 dsp's and an arc) I'm gonna
  19464. have to eat up another 10 or so IP addresses, just to end up with a
  19465. useable pool of 92 addresses if I want to aggregate (PRI's, only 92
  19466. B-channels, not 96).  So much for the benefits of classless addressing.
  19467. -- 
  19468. Jeff McAdams                            Email: jeffm@iglou.com
  19469. Head Network Administrator              Voice: (502) 966-3848
  19470. IgLou Internet Services                        (800) 436-4456
  19471.  
  19472. -
  19473.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19474.  with "unsubscribe usr-tc" in the body of the message.
  19475.  For information on digests or retrieving files and old messages send
  19476.  "help" to the same address.  Do not use quotes in your message.
  19477.  
  19478.  
  19479. -------------------------------------------------------------------------------
  19480.  
  19481. From: "Matt Harper" <Matt_Harper@mw.3com.com>
  19482. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  19483. Date: 16 Mar 1999 11:32:27 -0600
  19484.  
  19485.  
  19486.  
  19487. Hi Jeff,
  19488.  
  19489. Perhaps you could/should use proxy arp instead - that will allow you to use all
  19490. 32 addresses from the calass C
  19491. in the scenareo you list below.  Simply add a pool on the ARC for the range you
  19492. want and then you don't have
  19493. to use an aggrigate route enabled for the pool.
  19494.  
  19495. -- Matt
  19496.  
  19497.  
  19498.  
  19499.  
  19500.  
  19501.  
  19502. Jeff Mcadams <jeffm@iglou.com> on 03/16/99 11:05:18 AM
  19503.  
  19504. Please respond to usr-tc@lists.xmission.com
  19505.  
  19506. cc:    (Matt Harper/MW/US/3Com)
  19507.  
  19508.  
  19509.  
  19510.  
  19511. Thus spake Pete Ashdown
  19512. >>ie, let's say I want a pool with approximately 30 addresses in it...I'd
  19513. >>like it advertised as a single /27, do I do:
  19514. >>add ip pool dialup initial_pool_address x.y.z.32 size 32 state public
  19515. >>   route aggregate
  19516. >>or:
  19517. >>add ip pool dialup initial_pool_address x.y.z.33 size 30 state public
  19518. >>   route aggregate
  19519. >>
  19520. >>Which of those would result in the correct behavior?  I'm hoping the
  19521. >>first since that would result in fewer wasted IP addresses, but so far I
  19522. >>can't seem to get that to aggregate and I'm not sure what I'm missing.
  19523.  
  19524. >Theoretically, this should work, since your router sees it as a subnet and
  19525. >your ARC sees them as host-routes.  However, it is still illegal to have a
  19526. >device on the subnet number.  I suspect that the ARC is simply trying to
  19527. >keep you out of trouble.  It would definitely be bad for the person
  19528. >connecting up with the broadcast address.
  19529.  
  19530. We're on point-to-point links routed as /32's though, there's no concept
  19531. of broadcast address.
  19532.  
  19533. Here's the scenario.
  19534.  
  19535. eth:1 on the arc is x.y.z.3/24
  19536. eth 1/1/2 on the cisco is x.y.z.1/24
  19537. with the ip pool as above, none of the addresses in the pool are on the
  19538. network or broadcast address of the ethernet, so no problem.  The Cisco
  19539. would see the route as x.y.z.32/27 with a next hop of x.y.z.3.  The
  19540. Cisco handles this with no problem.  Then internally, the arc sees the
  19541. addresses in the pool as /32's.
  19542.  
  19543. Long and short of it is that there's nothing illegal about this setup.
  19544. The Cisco doesn't know what the ultimate subnet'ing of the end networks
  19545. are like, so if forwards to the next hop of the route even the all zeros
  19546. address.  This is confirmed BTW.  The Cisco has to assume that the
  19547. ultimate addresses might be "subnetted" down to /32 possibly (in this
  19548. case they are) so it forwards even all-zeros and all-ones for the routes
  19549. it has.
  19550. --
  19551. Jeff McAdams                            Email: jeffm@iglou.com
  19552. Head Network Administrator              Voice: (502) 966-3848
  19553. IgLou Internet Services                        (800) 436-4456
  19554.  
  19555. -
  19556.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19557.  with "unsubscribe usr-tc" in the body of the message.
  19558.  For information on digests or retrieving files and old messages send
  19559.  "help" to the same address.  Do not use quotes in your message.
  19560.  
  19561.  
  19562.  
  19563.  
  19564.  
  19565.  
  19566.  
  19567.  
  19568. -
  19569.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19570.  with "unsubscribe usr-tc" in the body of the message.
  19571.  For information on digests or retrieving files and old messages send
  19572.  "help" to the same address.  Do not use quotes in your message.
  19573.  
  19574.  
  19575. -------------------------------------------------------------------------------
  19576.  
  19577. From: david@carolnet.com (David Swearingin)
  19578. Subject: RE: (usr-tc)How to turn off @anything.com
  19579. Date: 16 Mar 1999 11:32:34 -0600
  19580.  
  19581. At 10:22 AM 3/16/99 -0600, you wrote:
  19582. >S&A uses a scripting language. You can edit the script to crop off the domain
  19583. >information for all logins..
  19584. >
  19585. >-M
  19586.  
  19587. Sounds easy enough.  Do you know the name of the script file?  Has anyone
  19588. else already done this?
  19589.  
  19590. Thanks. David
  19591. >
  19592. >
  19593. >|-----Original Message-----
  19594. >|From: owner-usr-tc@lists.xmission.com
  19595. >|[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of David Swearingin
  19596. >|Sent: Tuesday, March 16, 1999 8:45 AM
  19597. >|To: usr-tc@lists.xmission.com
  19598. >|Subject: (usr-tc)How to turn off @anything.com
  19599. >|
  19600. >|
  19601. >|Is there a way to stop S&A manager from authenticating a user who adds
  19602. >|@domain.com or @anything.com to their correct user name from being
  19603. >|authenticated?  Some users get confused and instead using just their user
  19604. >|name they use their email address, or something that looks like it.  As
  19605. >|long as the name in front of the @ is a valid user name, they get
  19606. >|authenticated.  The problem is that an entry is made in the CALLS table for
  19607. >|each unique name they enter and their actual usage is spread out over all
  19608. >|the names they have used.
  19609. >|
  19610. >|Thanks.
  19611. >|
  19612. >|David
  19613. >|__________________________________________________
  19614. >|David Swearingin (david@carolnet.com)
  19615. >|CARROLLTON INTERNET SERVICE (www.carolnet.com)
  19616. >|First Financial Group, Inc.
  19617. >|11 N. Folger, Carrollton, MO  64633
  19618. >|816-542-3002   Fax 816-542-3003
  19619. >|
  19620. >|-
  19621. >| To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19622. >| with "unsubscribe usr-tc" in the body of the message.
  19623. >| For information on digests or retrieving files and old messages send
  19624. >| "help" to the same address.  Do not use quotes in your message.
  19625. >|
  19626. >
  19627. >
  19628. >-
  19629. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19630. > with "unsubscribe usr-tc" in the body of the message.
  19631. > For information on digests or retrieving files and old messages send
  19632. > "help" to the same address.  Do not use quotes in your message.
  19633. >
  19634. __________________________________________________
  19635. David Swearingin (david@carolnet.com)
  19636. CARROLLTON INTERNET SERVICE (www.carolnet.com)
  19637. First Financial Group, Inc.
  19638. 11 N. Folger, Carrollton, MO  64633
  19639. 816-542-3002   Fax 816-542-3003
  19640.  
  19641. -
  19642.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19643.  with "unsubscribe usr-tc" in the body of the message.
  19644.  For information on digests or retrieving files and old messages send
  19645.  "help" to the same address.  Do not use quotes in your message.
  19646.  
  19647.  
  19648. -------------------------------------------------------------------------------
  19649.  
  19650. From: Jeff Mcadams <jeffm@iglou.com>
  19651. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  19652. Date: 16 Mar 1999 12:41:26 -0500 (EST)
  19653.  
  19654. Thus spake Matt Harper
  19655. >Perhaps you could/should use proxy arp instead - that will allow you to use all
  19656. >32 addresses from the calass C
  19657. >in the scenareo you list below.  Simply add a pool on the ARC for the range you
  19658. >want and then you don't have
  19659. >to use an aggrigate route enabled for the pool.
  19660.  
  19661. I can do that, but that only works if I'm pulling addresses out of the
  19662. same class C that eth:1 is on...which limits scaleability, and also
  19663. wastes IP addresses.  Besides, that doesn't address the issue that the
  19664. "all-zeros" address of the route advertisement is (at least potentially)
  19665. a valid IP address for use, regardless of whether its in the same /24 as
  19666. eth:1 or not.
  19667.  
  19668. Might I suggest that 3Com make it so that the configuration of route 
  19669. aggregation is seperate from the configuration of the IP Pools in the 
  19670. HiPer Arc.
  19671.  
  19672. Personally, the way its behaving now, I consider it at least borderline
  19673. broken.
  19674.  
  19675. If you really think about the concepts, aggregation of routes is a
  19676. seperate (related, but seperate) concept from defining dialin pools.
  19677.  
  19678. Particularly when you start getting multiple routing protocols (OSPF is
  19679. coming, BGP is eventually coming I believe, as well as others), and
  19680. start redistributing between them, more precise control of aggregation
  19681. and summarization is going to be needed.
  19682.  
  19683. Aggregation really shouldn't be tied to the definition of ip
  19684. pools...that's very limiting.  Essentially, that makes the Arc limited
  19685. to being an access server, and a limiting one at that, instead of really 
  19686. being a full router, which seems to be how 3Com wants to place it (and
  19687. understandably so), with full control over routing advertisements.
  19688.  
  19689. As it is, its really not feasible for me to do route aggregation because
  19690. of the extra IP addresses that it chews up.
  19691.  
  19692. File this under the category "short-sighted designs".
  19693.  
  19694. >Thus spake Pete Ashdown
  19695. >>>ie, let's say I want a pool with approximately 30 addresses in it...I'd
  19696. >>>like it advertised as a single /27, do I do:
  19697. >>>add ip pool dialup initial_pool_address x.y.z.32 size 32 state public
  19698. >>>   route aggregate
  19699. >>>or:
  19700. >>>add ip pool dialup initial_pool_address x.y.z.33 size 30 state public
  19701. >>>   route aggregate
  19702. >>>
  19703. >>>Which of those would result in the correct behavior?  I'm hoping the
  19704. >>>first since that would result in fewer wasted IP addresses, but so far I
  19705. >>>can't seem to get that to aggregate and I'm not sure what I'm missing.
  19706.  
  19707. >>Theoretically, this should work, since your router sees it as a subnet and
  19708. >>your ARC sees them as host-routes.  However, it is still illegal to have a
  19709. >>device on the subnet number.  I suspect that the ARC is simply trying to
  19710. >>keep you out of trouble.  It would definitely be bad for the person
  19711. >>connecting up with the broadcast address.
  19712.  
  19713. >We're on point-to-point links routed as /32's though, there's no concept
  19714. >of broadcast address.
  19715.  
  19716. >Here's the scenario.
  19717.  
  19718. >eth:1 on the arc is x.y.z.3/24
  19719. >eth 1/1/2 on the cisco is x.y.z.1/24
  19720. >with the ip pool as above, none of the addresses in the pool are on the
  19721. >network or broadcast address of the ethernet, so no problem.  The Cisco
  19722. >would see the route as x.y.z.32/27 with a next hop of x.y.z.3.  The
  19723. >Cisco handles this with no problem.  Then internally, the arc sees the
  19724. >addresses in the pool as /32's.
  19725.  
  19726. >Long and short of it is that there's nothing illegal about this setup.
  19727. >The Cisco doesn't know what the ultimate subnet'ing of the end networks
  19728. >are like, so if forwards to the next hop of the route even the all zeros
  19729. >address.  This is confirmed BTW.  The Cisco has to assume that the
  19730. >ultimate addresses might be "subnetted" down to /32 possibly (in this
  19731. >case they are) so it forwards even all-zeros and all-ones for the routes
  19732. >it has.
  19733. >--
  19734. >Jeff McAdams                            Email: jeffm@iglou.com
  19735. >Head Network Administrator              Voice: (502) 966-3848
  19736. >IgLou Internet Services                        (800) 436-4456
  19737.  
  19738. >-
  19739. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19740. > with "unsubscribe usr-tc" in the body of the message.
  19741. > For information on digests or retrieving files and old messages send
  19742. > "help" to the same address.  Do not use quotes in your message.
  19743.  
  19744. >-
  19745. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19746. > with "unsubscribe usr-tc" in the body of the message.
  19747. > For information on digests or retrieving files and old messages send
  19748. > "help" to the same address.  Do not use quotes in your message.
  19749.  
  19750. -- 
  19751. Jeff McAdams                            Email: jeffm@iglou.com
  19752. Head Network Administrator              Voice: (502) 966-3848
  19753. IgLou Internet Services                        (800) 436-4456
  19754.  
  19755. -
  19756.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19757.  with "unsubscribe usr-tc" in the body of the message.
  19758.  For information on digests or retrieving files and old messages send
  19759.  "help" to the same address.  Do not use quotes in your message.
  19760.  
  19761.  
  19762. -------------------------------------------------------------------------------
  19763.  
  19764. From: Pete Ashdown <pashdown@xmission.com>
  19765. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  19766. Date: 16 Mar 1999 10:47:10 -0700 (MST)
  19767.  
  19768. Jeff Mcadams said once upon a time:
  19769.  
  19770. >We're on point-to-point links routed as /32's though, there's no concept 
  19771. >of broadcast address.
  19772.  
  19773. However, when you go to anything larger than /32 with an aggregate, the
  19774. devices in the same subnet you are routing to will recognize the top and
  19775. bottom as broadcast/subnet.  There is no exception.  Your ARC is trying to
  19776. follow the rules, and in this case you're asking to have your cake and eat
  19777. it too.  If you want to use all 32 addresses, you can't use an aggregate.
  19778.  
  19779. -
  19780.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19781.  with "unsubscribe usr-tc" in the body of the message.
  19782.  For information on digests or retrieving files and old messages send
  19783.  "help" to the same address.  Do not use quotes in your message.
  19784.  
  19785.  
  19786. -------------------------------------------------------------------------------
  19787.  
  19788. From: "Terry Kennedy" <terry@olypen.com>
  19789. Subject: Re: (usr-tc) ARC Problems?
  19790. Date: 16 Mar 1999 09:47:16 -0800
  19791.  
  19792. Are there different flavors of the DSP and Hiper Code
  19793. in the 4.1.59 release and the  1.2.59 release.
  19794. If there are how do you tell? TCM only reports 1.2.59
  19795. not 1.2.59-6
  19796. -----Original Message-----
  19797. Cc: usr-tc@lists.xmission.com <usr-tc@lists.xmission.com>
  19798.  
  19799.  
  19800. >On Mon, 15 Mar 1999, Jamie Orzechowski wrote:
  19801. >
  19802. >> I seem to be having ALOT of PPP authentication problems! ... I am running
  19803. >> that latest ARC code ... 4.1.59-6 .. anyone have any ideas how to fix
  19804. >> this????
  19805. >
  19806. >Do please refer to the release notes and make sure that
  19807. >
  19808. >ppp offloading is enabled
  19809. >disable ppp receive accm
  19810. >
  19811. >>
  19812. >> People will connect and get dropped right away.  When I dial in with a
  19813. term
  19814. >> program I will dial and immediatly I will get a authentication failure
  19815. text
  19816. >> come up before I have even typed anything ...
  19817. >>
  19818. >> here is a cut & paste
  19819. >>
  19820. >> atdtXXX-XXXX
  19821. >> CONNECT 115200
  19822. >>
  19823. >> Welcome to 3Com Total Control HiPer ARC (TM)
  19824. >> Networks That Go The Distance (TM)
  19825. >> UserName: Authentication failure
  19826. >>
  19827. >> UserName:
  19828. >>
  19829. >>
  19830. >
  19831. >This is something wrong here - I would suspect config.  Either the client
  19832. >or the modem_group is configured wrong.
  19833. >
  19834. >you can do a tap on the port and find out what is happening.
  19835. >
  19836. >krish
  19837. >
  19838. >
  19839. >>
  19840. >> Sometimes PPP starts at the same prompt before I type anything ...
  19841. >>
  19842. >> here is a message an advanced linux user of our system has sent me.
  19843. >>
  19844. >> --start
  19845. >>
  19846. >> hi... it's me again. i've been doing some more playing around trying to
  19847. >> figure out why the linux 2.2.x series won't allow me to connect.  i
  19848. >> booted into 2.0.36 yesterday, and i ran minicom (you know, the unix term
  19849. >> app?)  anyway...  i found that after i dialed, the first prompt for
  19850. >> authentication would automatically fail, even though i hadn't typed in
  19851. >> anything yet... on other times (specifically if i got connected at
  19852. >> 44000) it would start sending PPP garbage like ?~?~?~?~?~... etc... at
  19853. >> the authentication prompt um... i have a GVC 56k X2 modem... and as far
  19854. >> as i know it still uses the v.42 protocol.  (upgrade to v.90 requires a
  19855. >> chip replacement)... does that bring anything to mind as to why maybe i
  19856. >> can't get connected? i think it at least shows why i've been getting the
  19857. >> "unsupported protocol" errors from pppd.... thanks.
  19858. >>
  19859. >> --stop
  19860. >>
  19861. >>
  19862. >>
  19863. >> ---------------------------------------------------
  19864. >> Have a Great Day!
  19865. >>
  19866. >> Jamie Orzechowski
  19867. >> RipNET System Admin
  19868. >>
  19869. >> Tel.: 613-342-3946 ext 293
  19870. >> Tel.: 800-267-4434 ext 293
  19871. >> Page.: 613-341-0883
  19872. >> EMail.: mhz@ripnet.com
  19873. >> Web.: http://www.ripnet.com
  19874. >> Personal.: http://www.moonchilli.com
  19875. >> ---------------------------------------------------
  19876. >>
  19877. >>
  19878. >>
  19879. >>
  19880. >> -
  19881. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19882. >>  with "unsubscribe usr-tc" in the body of the message.
  19883. >>  For information on digests or retrieving files and old messages send
  19884. >>  "help" to the same address.  Do not use quotes in your message.
  19885. >>
  19886. >
  19887. >-
  19888. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19889. > with "unsubscribe usr-tc" in the body of the message.
  19890. > For information on digests or retrieving files and old messages send
  19891. > "help" to the same address.  Do not use quotes in your message.
  19892. >
  19893.  
  19894.  
  19895. -
  19896.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19897.  with "unsubscribe usr-tc" in the body of the message.
  19898.  For information on digests or retrieving files and old messages send
  19899.  "help" to the same address.  Do not use quotes in your message.
  19900.  
  19901.  
  19902. -------------------------------------------------------------------------------
  19903.  
  19904. From: Jeff Mcadams <jeffm@iglou.com>
  19905. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  19906. Date: 16 Mar 1999 13:03:25 -0500 (EST)
  19907.  
  19908. Thus spake Pete Ashdown
  19909. >Jeff Mcadams said once upon a time:
  19910. >>We're on point-to-point links routed as /32's though, there's no concept 
  19911. >>of broadcast address.
  19912.  
  19913. >However, when you go to anything larger than /32 with an aggregate, the
  19914. >devices in the same subnet you are routing to will recognize the top and
  19915. >bottom as broadcast/subnet.  There is no exception.  Your ARC is trying to
  19916. >follow the rules, and in this case you're asking to have your cake and eat
  19917. >it too.  If you want to use all 32 addresses, you can't use an aggregate.
  19918.  
  19919. Not true...
  19920.  
  19921. For example...this from our cisco router:
  19922. O E2    204.255.234.192/27 
  19923.            [110/1] via 204.255.229.254, 01:26:41, Serial1/0/4:0
  19924.            [110/1] via 204.255.229.242, 01:26:41, Serial1/0/6:0
  19925.  
  19926. (two next hops because we have 2 parallel t1's to that remote city)
  19927.  
  19928. Then this traceroute:
  19929. ceroute to 204.255.234.192 (204.255.234.192): 1-30 hops, 38 byte packets
  19930.  1  gator (192.107.41.4)  2.1 ms  0.810 ms  1.3 ms
  19931.  2  lou2-fe4-1-0.lou.iglou.com (204.252.74.6)  148 ms  98.1 ms  206 ms
  19932.  3  lex1-s0.lex.iglou.com (204.255.229.254)  21.0 ms  19.3 ms  20.7 ms
  19933.  
  19934. The Cisco router handles forwarding a packet with an "all-zeros host"
  19935. address on that route correctly and forwards it on to the next-hop, even
  19936. though it sees it as the network address for that route.  It does this
  19937. because it doesn't know if the next-hop, or perhaps some hop on down the
  19938. line might be routing this block as /32's.  Will classless addressing
  19939. and routing, this is the correct thing to do.
  19940.  
  19941. Again, as I mentioned in another post, the real brokenness in the HiPer
  19942. Arc is that it ties up the definition of route aggregation with the
  19943. definition of the ip pools.  This is very limiting, and dare I say,
  19944. truly broken, as it leads to situation such as this where the Arc
  19945. doesn't handle things really quite like it should.
  19946.  
  19947. 3Com has put some really good thought into some stuff in the Arc's, but
  19948. some design considerations leave a *lot* lacking.  The control of
  19949. routing information through aggregation and stuff being a big one.
  19950. -- 
  19951. Jeff McAdams                            Email: jeffm@iglou.com
  19952. Head Network Administrator              Voice: (502) 966-3848
  19953. IgLou Internet Services                        (800) 436-4456
  19954.  
  19955. -
  19956.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  19957.  with "unsubscribe usr-tc" in the body of the message.
  19958.  For information on digests or retrieving files and old messages send
  19959.  "help" to the same address.  Do not use quotes in your message.
  19960.  
  19961.  
  19962. -------------------------------------------------------------------------------
  19963.  
  19964. From: "R. Ferguson" <cygnus@vsta.com>
  19965. Subject: (usr-tc) disconnect problems
  19966. Date: 16 Mar 1999 12:49:28 -0600
  19967.  
  19968. Hello Everyone,
  19969. I'm new to this list but from the few days i've been on it looks like
  19970. someone here might have the answer i need.
  19971. I have 3 TC chassis with the configuration shown  below. I have been having
  19972. a problem with customers calling up and getting dropped immediately. Some
  19973. users finish the handshake and get disconnected during authentication
  19974. others never get past the handshake stage  many users report messages
  19975. saying "error 631" or "a connection could not be established please check
  19976. you network configuration and try again" (something like that). Anyways
  19977. the people complaining have been long standing customers who have never
  19978. reported trouble then suddenly about a month ago everyone started having
  19979. this trouble(about the time i put in a usr update). The only real pattern i
  19980. see is that it mostly affects Kflex users and V.90 users and users with
  19981. pc's(Compaq and Gateway) less that 3 months old. USR support told me to
  19982. update the code to the version you see listed below and that all the V.90
  19983. problems would be resolved. I saw no difference with the new code except
  19984. that WebTv users work great now.  I have managed to get the real angry
  19985. customers back online by turning off 56k/v.90 in thier modems with an init
  19986. string but it's not a real solution because the problem is still there.
  19987. Is anyone else seeing this problem? Is there a known bug with V.90/56k? Can
  19988. anyone give me some advice on resolving this problem.....The USRTechs i
  19989. have spoken with say that my customers have to go get thier modems updated
  19990. to the latest code. Some of my customers have tried doing this and they are
  19991. told by their vendors that there code is solid and their ISP (me) is the
  19992. one with the problem....
  19993. any help or adice will be greatly appreciated
  19994.                          Rudy Ferguson
  19995.                          cygnus@vsta.com                                
  19996.                             
  19997.                                 
  19998. 1    3COM DUAL T1 NAC    BBB6NZTY    11C    3.0.0    512    512    0000000000000101    3.5.0
  19999. 2    3COM Quad V.34 Digital Modem NAC    BCI6XI90    19U000    2.0.0    0    0
  20000. 0000000110001000    5.10.9
  20001. 3    3COM Quad V.34 Digital Modem NAC    BCF6WXM6    19U000    2.0.0    0    0
  20002. 0000000110001000    5.10.9
  20003. 4    3COM Quad V.34 Digital Modem NAC    BCL6Y9MA    19U000    2.0.0    0    0
  20004. 0000000110001000    5.10.9
  20005. 5    3COM Quad V.34 Digital Modem NAC    BCG6X1OR    19U000    2.0.0    0    0
  20006. 0000000110001000    5.10.9
  20007. 6    3COM Quad V.34 Digital Modem NAC    BCE6WRHG    19U000    2.0.0    0    0
  20008. 0000000110001000    5.10.9
  20009. 7    3COM Quad V.34 Digital Modem NAC    BCI6XIG5    19U000    2.0.0    0    0
  20010. 0000000110001000    5.10.9
  20011. 8    3COM Quad V.34 Digital Modem NAC    BCI6XI8M    19U000    2.0.0    0    0
  20012. 0000000110001000    5.10.9
  20013. 9    3COM Quad V.34 Digital Modem NAC    BCG6X1UB    19U000    2.0.0    0    0
  20014. 0000000110001000    5.10.9
  20015. 10    3COM Quad V.34 Digital Modem NAC    BCL6Y9NM    19U000    2.0.0    0    0
  20016. 0000000110001000    5.10.9
  20017. 11    3COM Quad V.34 Digital Modem NAC    BCG6X1OL    19U000    2.0.0    0    0
  20018. 0000000110001000    5.10.9
  20019. 12    3COM Quad V.34 Digital Modem NAC    BCG6X1KL    19U000    2.0.0    0    0
  20020. 0000000110001000    5.10.9
  20021. 13    3COM Quad V.34 Digital Modem NAC    BCH6XGZI    19U000    2.0.0    0    0
  20022. 0000000110001000    5.10.9
  20023. 14    3COM High-Density 24 Channel NAC    BC77B0TF    1OQ    0.49.0    8192    2048
  20024. 0000000000000000    1.2.59
  20025. 15    3COM High-Density 24 Channel NAC    B1C8DPRE    1OQ    0.49.0    8192    2048
  20026. 0000000000000000    1.2.59
  20027. 16    3COM HiPer ARC NAC    B648VNPZ    20C    19.0.0    65536    8192    0000000000000000    4.1.59
  20028. 17    3COM Network Management Card with clock    BCI6XJ5M    11I00000    3.0    20480    8192
  20029. 0000000000000000    5.5.5
  20030. 1    3COM Bellcore Approved Long Haul Dual T1 NIC                512    512    0000000000000101    
  20031. 14    3COM T1/E1 HDM NIC                8192    2048    0000000000000000    
  20032. 15    3COM T1/E1 HDM NIC                8192    2048    0000000000000000    
  20033. 16    3COM Dual 10/100 Ethernet NIC - PCI based                65536    8192    0000000000000000    
  20034. 17    3COM Ethernet NIC    ????????        ??    0    0    0000000000000000    
  20035.  
  20036.  
  20037.  
  20038. -
  20039.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20040.  with "unsubscribe usr-tc" in the body of the message.
  20041.  For information on digests or retrieving files and old messages send
  20042.  "help" to the same address.  Do not use quotes in your message.
  20043.  
  20044.  
  20045. -------------------------------------------------------------------------------
  20046.  
  20047. From: Ricky Beam <jfbeam@beaker.interpath.net>
  20048. Subject: Re: (usr-tc)How to turn off @anything.com
  20049. Date: 16 Mar 1999 13:57:06 -0500 (EST)
  20050.  
  20051. On Tue, 16 Mar 1999, David Swearingin wrote:
  20052. >Is there a way to stop S&A manager from authenticating a user who adds
  20053. >@domain.com or @anything.com to their correct user name from being
  20054. >authenticated?  Some users get confused and instead using just their user
  20055. >name they use their email address, or something that looks like it.  As
  20056. >long as the name in front of the @ is a valid user name, they get
  20057. >authenticated.  The problem is that an entry is made in the CALLS table for
  20058. >each unique name they enter and their actual usage is spread out over all
  20059. >the names they have used.
  20060.  
  20061. (you didn't say which version of SA you were using, so I'll assume SA6)
  20062.  
  20063. The accounting server is recording whatever username that got authenticated.
  20064. You can go into the radserv.scp within the Accounting_Request function and
  20065. have it remove the [@foo] part...
  20066.  
  20067. (from Accounting_Request)
  20068.     ; Is the User-Name attribute in the request?
  20069.     if(User_Name inList Request)
  20070.         thisUser = Request.User_Name
  20071.         ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  20072.         ;;;;; Is there a @ symbol in the username?
  20073.         ;;;;; If so then proxy the accounting request
  20074.         ;;;;; if there is a domain in the domains table.
  20075.         ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  20076.         if(instr(Request.User_Name, "@") > 0)
  20077.  
  20078.             ; For Proxy requests we need to be able to
  20079.             ; differentiate between Accounting and Security
  20080.             ; messages. So, set a flag indicating that this
  20081.             ; is an Accounting message
  20082.             ;
  20083.             bAcctingProxy = True
  20084.             Call Check-RADIUS-Proxy
  20085.  
  20086.             ; If we reach this point then the
  20087.             ; accounting request has NOT been proxied
  20088.  
  20089.         endif  ; proxying accounting
  20090. ...
  20091.  
  20092. The stub "Check-RADIUS-Proxy" is the magic that actually sends the request to
  20093. another RADIUS server.  Basically what you want is the username only:
  20094.  
  20095. (from Check-RADIUS-Proxy)
  20096. ; Isolate the <User_Name>@<Domain-Name>
  20097. AtPos = instr(Request.User_Name, "@")
  20098. if(AtPos > 0)
  20099.         n = AtPos - 1
  20100.         UserNameOnly   = Mid$(Request.User_Name, 1, n)
  20101.         n = AtPos + 1
  20102.         domainname = Mid$(Request.User_Name, n)
  20103. else
  20104.         ; no domain or realm in user_name attribute
  20105.         ; so return
  20106.         return
  20107. endif
  20108.  
  20109. If you need any help, just ask.  For me, this is a 30 second "hack".
  20110.  
  20111. --Ricky
  20112.  
  20113.  
  20114.  
  20115. -
  20116.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20117.  with "unsubscribe usr-tc" in the body of the message.
  20118.  For information on digests or retrieving files and old messages send
  20119.  "help" to the same address.  Do not use quotes in your message.
  20120.  
  20121.  
  20122. -------------------------------------------------------------------------------
  20123.  
  20124. From: Ricky Beam <jfbeam@beaker.interpath.net>
  20125. Subject: Re: (usr-tc)How to turn off @anything.com
  20126. Date: 16 Mar 1999 14:00:16 -0500 (EST)
  20127.  
  20128. On Tue, 16 Mar 1999, Pete Ashdown wrote:
  20129. >Get a RADIUS with the source code.  It wouldn't take much to modify it to
  20130. >do this.
  20131.  
  20132. If you've ever even looked at the USR RADIUS server... you have the "source."
  20133. There is a tcl/perl like script that the server loads to control the
  20134. authentication process.  The user/administrator has complete control over what
  20135. the script does.  It's really a powerful engine. (if programmed efficiently)
  20136.  
  20137. --Ricky
  20138.  
  20139.  
  20140.  
  20141. -
  20142.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20143.  with "unsubscribe usr-tc" in the body of the message.
  20144.  For information on digests or retrieving files and old messages send
  20145.  "help" to the same address.  Do not use quotes in your message.
  20146.  
  20147.  
  20148. -------------------------------------------------------------------------------
  20149.  
  20150. From: Pete Ashdown <pashdown@xmission.com>
  20151. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  20152. Date: 16 Mar 1999 12:44:56 -0700 (MST)
  20153.  
  20154. Jeff Mcadams said once upon a time:
  20155.  
  20156. >The Cisco router handles forwarding a packet with an "all-zeros host"
  20157. >address on that route correctly and forwards it on to the next-hop, even
  20158. >though it sees it as the network address for that route.  It does this
  20159. >because it doesn't know if the next-hop, or perhaps some hop on down the
  20160. >line might be routing this block as /32's.  Will classless addressing
  20161. >and routing, this is the correct thing to do.
  20162.  
  20163. We're not talking about multihop aggregation here though.  We're talking
  20164. about an ARC advertising to a subnet with RIP.  Picture this problem:
  20165.  
  20166. ARC is broadcasting /27 for a group of modem clients to subnet A.
  20167. Device on subnet A sees /27, which indicates a block of IPs and and
  20168.    broadcast address and a subnet address.
  20169. Device on subnet A desires to send a broadcast to the clients in /27, it
  20170. sends it to the broadcast address.
  20171.  
  20172. What is proper behavior of the ARC at this point?
  20173.  
  20174. 1. Under broadcast rules, it then copies the broadcast to all /32's in the
  20175.    subnet?
  20176. 2. Under subnet rules, it sends it to the broadcast address, which then
  20177.    gets discarded?
  20178. 3. Under Mcadams rules, it sends the broadcast to the /32 using the
  20179.    broadcast address?
  20180.  
  20181. I'm not trying to be sarcastic here, I'm just presenting a problem to your
  20182. desired behavior.  Personally, I'd pick #2, which I believe is what
  20183. happens.  Under your proposed scheme, how is the "Device" supposed to
  20184. distinguish broadcast traffic from regular traffic for the IP using the
  20185. broadcast address?
  20186.  
  20187. -
  20188.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20189.  with "unsubscribe usr-tc" in the body of the message.
  20190.  For information on digests or retrieving files and old messages send
  20191.  "help" to the same address.  Do not use quotes in your message.
  20192.  
  20193.  
  20194. -------------------------------------------------------------------------------
  20195.  
  20196. From: "Peter D. Mayer" <dmayer@netwalk.com>
  20197. Subject: (usr-tc) No nas-identifier from Hiper ARC
  20198. Date: 16 Mar 1999 16:58:18 -0500
  20199.  
  20200. My HiperARC doesn't seem to be sending Nas-Identifer to radius.  All of my
  20201. NetServers send this info, but the HiPer doesn't.  Do I have to set anything in
  20202. the ARC besides system name and system transmit_authentication_name?
  20203.  
  20204. Anyone else having this problem?  I'm running 4.1.72.
  20205.  
  20206. Thanks,
  20207. Peter D. Mayer
  20208. NetWalk System Administrator
  20209. dmayer@netwalk.com
  20210.  
  20211.  
  20212.  
  20213. -
  20214.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20215.  with "unsubscribe usr-tc" in the body of the message.
  20216.  For information on digests or retrieving files and old messages send
  20217.  "help" to the same address.  Do not use quotes in your message.
  20218.  
  20219.  
  20220. -------------------------------------------------------------------------------
  20221.  
  20222. From: Jeff Mcadams <jeffm@iglou.com>
  20223. Subject: Re: (usr-tc) IP Pool aggregation on Arc
  20224. Date: 16 Mar 1999 16:51:29 -0500 (EST)
  20225.  
  20226. Thus spake Pete Ashdown
  20227. >Jeff Mcadams said once upon a time:
  20228. >>The Cisco router handles forwarding a packet with an "all-zeros host"
  20229. >>address on that route correctly and forwards it on to the next-hop, even
  20230. >>though it sees it as the network address for that route.  It does this
  20231. >>because it doesn't know if the next-hop, or perhaps some hop on down the
  20232. >>line might be routing this block as /32's.  Will classless addressing
  20233. >>and routing, this is the correct thing to do.
  20234.  
  20235. >We're not talking about multihop aggregation here though.  
  20236.  
  20237. But we are.
  20238.  
  20239. >We're talking
  20240. >about an ARC advertising to a subnet with RIP.  Picture this problem:
  20241.  
  20242. >ARC is broadcasting /27 for a group of modem clients to subnet A.
  20243. >Device on subnet A sees /27, which indicates a block of IPs and and
  20244. >   broadcast address and a subnet address.
  20245. >Device on subnet A desires to send a broadcast to the clients in /27, it
  20246. >sends it to the broadcast address.
  20247.  
  20248. That's just it though, Device on subnet A *can't* know whether its
  20249. sending to a broadcast address or a /32.  Under classless rules, its
  20250. sending it to a destination IP address, that IP address might be a
  20251. broadcast, it might be a host address in a larger block, or it might be
  20252. a host address (/32).
  20253.  
  20254. >What is proper behavior of the ARC at this point?
  20255.  
  20256. >1. Under broadcast rules, it then copies the broadcast to all /32's in the
  20257. >   subnet?
  20258. >2. Under subnet rules, it sends it to the broadcast address, which then
  20259. >   gets discarded?
  20260. >3. Under Mcadams rules, it sends the broadcast to the /32 using the
  20261. >   broadcast address?
  20262.  
  20263. Well, let me reword #3 to what the option really is (same could be done
  20264. on the others)
  20265.  
  20266. 3. Under Classless rules, it sends the packet to the next-hop or
  20267. destination based on the longest-match netmask in its routing table.
  20268.  
  20269. There is no concept of a packet being inherently a broadcast packet.
  20270. Its sent to a destination IP address, nothing more.  Again, that
  20271. destination IP address *might* end up being a broadcast address, but its
  20272. not necessarily just because some system along the way sees it as the
  20273. "all-ones" address of one of its routes.
  20274.  
  20275. *IF* the device finds that the destination address is a broadcast
  20276. address on a directly connected network, *then* it gets to decide if its
  20277. going to translate that directed broadcast, to a layer 2 broadcast.  My
  20278. personal preference on that decision is not to do that (no ip 
  20279. directed-broadcast :).
  20280.  
  20281. >I'm not trying to be sarcastic here, I'm just presenting a problem to your
  20282. >desired behavior.  
  20283.  
  20284. Its not a problem.  You're assuming that a device two hops away from the
  20285. destination gets to decide whether the packet is a broadcast packet or
  20286. not, and there's just no way for that device to know that under
  20287. classless rules.
  20288.  
  20289. >Personally, I'd pick #2, which I believe is what
  20290. >happens.  Under your proposed scheme, how is the "Device" supposed to
  20291. >distinguish broadcast traffic from regular traffic for the IP using the
  20292. >broadcast address?
  20293.  
  20294. If you've got a device with a /32 route for the same IP address as a
  20295. broadcast address for a directly connected broadcast-capable medium,
  20296. then that's configuration error.  That's why we, as network admins, get
  20297. paid the big bucks (if my boss is reading this, "hint, hint").  However, 
  20298. my example I originally gave, didn't involve any broadcast addresses on 
  20299. any broadcast-capable media, and yet the HiPer Arc forced me to waste IP 
  20300. addresses to avoid a situation that doesn't exist!
  20301. -- 
  20302. Jeff McAdams                            Email: jeffm@iglou.com
  20303. Head Network Administrator              Voice: (502) 966-3848
  20304. IgLou Internet Services                        (800) 436-4456
  20305.  
  20306. -
  20307.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20308.  with "unsubscribe usr-tc" in the body of the message.
  20309.  For information on digests or retrieving files and old messages send
  20310.  "help" to the same address.  Do not use quotes in your message.
  20311.  
  20312.  
  20313. -------------------------------------------------------------------------------
  20314.  
  20315. From: "Andres Kroonmaa" <andre@ml.ee>
  20316. Subject: (usr-tc) Country codes on HDMs
  20317. Date: 17 Mar 1999 00:28:47 +0200 EET
  20318.  
  20319.  
  20320.  Hi,
  20321.  
  20322.  way back with Quads it was sometimes needed to change country codes
  20323.  on modems. What about HDM's? How can you change that on HDM?
  20324.  
  20325.  
  20326.  
  20327.  ----------------------------------------------------------------------
  20328.   Andres Kroonmaa                                mail: andre@online.ee
  20329.   Network Manager
  20330.   Organization:            MicroLink Online       Tel:        6308 909
  20331.   Tallinn, Sakala 19                              Pho:  +372  6308 909
  20332.   Estonia, EE0001        http://www.online.ee     Fax:  +372  6308 901
  20333.  ----------------------------------------------------------------------
  20334.  
  20335. -
  20336.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20337.  with "unsubscribe usr-tc" in the body of the message.
  20338.  For information on digests or retrieving files and old messages send
  20339.  "help" to the same address.  Do not use quotes in your message.
  20340.  
  20341.  
  20342. -------------------------------------------------------------------------------
  20343.  
  20344. From: Paul Oster <devious@minot.com>
  20345. Subject: (usr-tc) Serial Ports on ARCS, DSP's etc
  20346. Date: 16 Mar 1999 16:29:48 -0600 (CST)
  20347.  
  20348.  
  20349.  
  20350.   Anyone know of a device that'll let me hook a modem up to it and
  20351. "switch" a dialin between numerious serial ports (which will be connected
  20352. to the above equipent)  Something CHEAP would be preferable... any
  20353. suggestions?
  20354.  
  20355. Paul M. Oster <devious@minot.com>               http://www.minot.com/
  20356. Magic Internet Services                         (701) 838-1265
  20357. Minots FIRST Internet Connection
  20358.  
  20359. -=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=--=**=-
  20360.  
  20361. "I might not agree with what you have to say but I will defend, to 
  20362. my death, your right to say it." - Voltaire
  20363.  
  20364.  
  20365. -
  20366.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20367.  with "unsubscribe usr-tc" in the body of the message.
  20368.  For information on digests or retrieving files and old messages send
  20369.  "help" to the same address.  Do not use quotes in your message.
  20370.  
  20371.  
  20372. -------------------------------------------------------------------------------
  20373.  
  20374. From: Jeff Mcadams <jeffm@iglou.com>
  20375. Subject: Re: (usr-tc) No nas-identifier from Hiper ARC
  20376. Date: 16 Mar 1999 17:36:23 -0500 (EST)
  20377.  
  20378. Thus spake Peter D. Mayer
  20379. >My HiperARC doesn't seem to be sending Nas-Identifer to radius.  All of my
  20380. >NetServers send this info, but the HiPer doesn't.  Do I have to set anything in
  20381. >the ARC besides system name and system transmit_authentication_name?
  20382.  
  20383. >Anyone else having this problem?  I'm running 4.1.72.
  20384.  
  20385. We've noticed the same thing.  Not really sure I'd term it a "problem"
  20386. as such.  To my knowledge NAS-Identifier is not required, so its just a
  20387. difference in implementation.  I almost considered using that as a way
  20388. to distinguish accounting records coming from a NETServer as opposed to
  20389. accounting records coming from an Arc, but decided that probably
  20390. wouldn't be a good thing to rely on.  :)
  20391. -- 
  20392. Jeff McAdams                            Email: jeffm@iglou.com
  20393. Head Network Administrator              Voice: (502) 966-3848
  20394. IgLou Internet Services                        (800) 436-4456
  20395.  
  20396. -
  20397.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20398.  with "unsubscribe usr-tc" in the body of the message.
  20399.  For information on digests or retrieving files and old messages send
  20400.  "help" to the same address.  Do not use quotes in your message.
  20401.  
  20402.  
  20403. -------------------------------------------------------------------------------
  20404.  
  20405. From: Jeff Mcadams <jeffm@iglou.com>
  20406. Subject: Re: (usr-tc) Serial Ports on ARCS, DSP's etc
  20407. Date: 16 Mar 1999 17:38:17 -0500 (EST)
  20408.  
  20409. Thus spake Paul Oster
  20410. >  Anyone know of a device that'll let me hook a modem up to it and
  20411. >"switch" a dialin between numerious serial ports (which will be connected
  20412. >to the above equipent)  Something CHEAP would be preferable... any
  20413. >suggestions?
  20414.  
  20415. Get an old terminal server.  We use a PM-25 or two to do this, works
  20416. pretty well for us.  We've also got some old Xyplex equipment around
  20417. that we could use if necessary (or sell if that's the route you want to
  20418. go...it would fit the requirement mentioned in all caps above :)
  20419. -- 
  20420. Jeff McAdams                            Email: jeffm@iglou.com
  20421. Head Network Administrator              Voice: (502) 966-3848
  20422. IgLou Internet Services                        (800) 436-4456
  20423.  
  20424. -
  20425.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20426.  with "unsubscribe usr-tc" in the body of the message.
  20427.  For information on digests or retrieving files and old messages send
  20428.  "help" to the same address.  Do not use quotes in your message.
  20429.  
  20430.  
  20431. -------------------------------------------------------------------------------
  20432.  
  20433. From: Pete Ashdown <pashdown@xmission.com>
  20434. Subject: Re: (usr-tc) Serial Ports on ARCS, DSP's etc
  20435. Date: 16 Mar 1999 15:42:19 -0700 (MST)
  20436.  
  20437. Jeff Mcadams said once upon a time:
  20438.  
  20439. >Thus spake Paul Oster
  20440. >>  Anyone know of a device that'll let me hook a modem up to it and
  20441. >>"switch" a dialin between numerious serial ports (which will be connected
  20442. >>to the above equipent)  Something CHEAP would be preferable... any
  20443. >>suggestions?
  20444. >
  20445. >Get an old terminal server.  We use a PM-25 or two to do this, works
  20446. >pretty well for us.  We've also got some old Xyplex equipment around
  20447. >that we could use if necessary (or sell if that's the route you want to
  20448. >go...it would fit the requirement mentioned in all caps above :)
  20449.  
  20450. No please, buy my 32 port Xylogics Annex 3.  I'll sell it to you CHEAP!!
  20451.  
  20452. -
  20453.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20454.  with "unsubscribe usr-tc" in the body of the message.
  20455.  For information on digests or retrieving files and old messages send
  20456.  "help" to the same address.  Do not use quotes in your message.
  20457.  
  20458.  
  20459. -------------------------------------------------------------------------------
  20460.  
  20461. From: Ronald Kushner <ron@glis.net>
  20462. Subject: Re: (usr-tc) Serial Ports on ARCS, DSP's etc
  20463. Date: 16 Mar 1999 17:58:00 -0500
  20464.  
  20465.  
  20466.  
  20467. Paul Oster wrote:
  20468. > 
  20469. >   Anyone know of a device that'll let me hook a modem up to it and
  20470. > "switch" a dialin between numerious serial ports (which will be connected
  20471. > to the above equipent)  Something CHEAP would be preferable... any
  20472. > suggestions?
  20473.  
  20474. BayTech sells a out of band remote site management systems. Check out
  20475. http://www.baytechdcd.com/product_cat.html#3
  20476.  
  20477. You might want to look for an old PM2 used, probably can get one for a few
  20478. hundred dollars. It will use up more space in a rack than the BayTech box,
  20479. but might cost less. 
  20480.  
  20481. -Ron
  20482. GLISnet, Inc.
  20483. +1 810/939.9885
  20484.  
  20485. -
  20486.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20487.  with "unsubscribe usr-tc" in the body of the message.
  20488.  For information on digests or retrieving files and old messages send
  20489.  "help" to the same address.  Do not use quotes in your message.
  20490.  
  20491.  
  20492. -------------------------------------------------------------------------------
  20493.  
  20494. From: Charles Sprickman <spork@inch.com>
  20495. Subject: Re: (usr-tc) Serial Ports on ARCS, DSP's etc
  20496. Date: 16 Mar 1999 18:01:14 -0500 (EST)
  20497.  
  20498. > Jeff Mcadams said once upon a time:
  20499.  
  20500. > No please, buy my 32 port Xylogics Annex 3.  I'll sell it to you CHEAP!!
  20501.  
  20502. We've got both a 64 port annex 3 and a 72 port annex 4 as well.  Not
  20503. super-duper cheap, but pretty cheap.  All cables, recent SW.  Did you know
  20504. each octupus cable cost $100 way back when???
  20505.  
  20506. Actually, we've got lots of old stuff for sale...  I know this isn't the
  20507. right forum, but other than usenet, where's a good place to sell ISP-like
  20508. equipment?
  20509.  
  20510. Thanks,
  20511.  
  20512. Charles
  20513.  
  20514.  > 
  20515. > -
  20516. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20517. >  with "unsubscribe usr-tc" in the body of the message.
  20518. >  For information on digests or retrieving files and old messages send
  20519. >  "help" to the same address.  Do not use quotes in your message.
  20520. > 
  20521.  
  20522.  
  20523. -
  20524.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20525.  with "unsubscribe usr-tc" in the body of the message.
  20526.  For information on digests or retrieving files and old messages send
  20527.  "help" to the same address.  Do not use quotes in your message.
  20528.  
  20529.  
  20530. -------------------------------------------------------------------------------
  20531.  
  20532. From: Ricky Beam <jfbeam@beaker.interpath.net>
  20533. Subject: Re: (usr-tc) Serial Ports on ARCS, DSP's etc
  20534. Date: 16 Mar 1999 18:08:24 -0500 (EST)
  20535.  
  20536. On Tue, 16 Mar 1999, Charles Sprickman wrote:
  20537. >Actually, we've got lots of old stuff for sale...  I know this isn't the
  20538. >right forum, but other than usenet, where's a good place to sell ISP-like
  20539. >equipment?
  20540.  
  20541. <grin> Start a museum.  (I've got enough junk in the warehouse^Wapartment
  20542. to build a small computer evolution museum.)
  20543.  
  20544. --Ricky
  20545.  
  20546.  
  20547. -
  20548.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20549.  with "unsubscribe usr-tc" in the body of the message.
  20550.  For information on digests or retrieving files and old messages send
  20551.  "help" to the same address.  Do not use quotes in your message.
  20552.  
  20553.  
  20554. -------------------------------------------------------------------------------
  20555.  
  20556. From: Rick <rickyz@mindspring.com>
  20557. Subject: (usr-tc) 3Com Security and Accounting upgrade from 6.0.8 to 6.0.90
  20558. Date: 16 Mar 1999 18:53:45 -0500
  20559.  
  20560. I did a test install of 6.0.9.  It installs to a different directory from 
  20561. the previous 6.0.8 -- c:\3comsuite vs. c:\usrsuite.  If c:\usrsuite exists, 
  20562. the installation routine apparently renames (or copies) the existing 
  20563. usradius.mdb to old.mdb in preparation for importing the records.
  20564.  
  20565. There is a database import utility under Server Setup / Advanced Options / 
  20566. Database Maintenance.  There are options for importing from various other 
  20567. versions, including 6.0.8.
  20568.  
  20569. So far, so good.
  20570.  
  20571. However, when I try to import the database, I get the following error 
  20572. message:
  20573.  
  20574. 3COM Security and Accounting Database Manager can't append all the records 
  20575. in the append query.
  20576.     3COM Security and Accounting Database Manager set 0 field(s) to Null 
  20577. due to a type
  20578.     conversion failure, and it didn't add 3476 record(s) to the table due 
  20579. to key violations, 0
  20580.     record(s) due to lock violations, and 0 record(s) due to validation 
  20581. rule violations.
  20582.     Do you want to run the action query anyway?
  20583.     To ignore the error(s) and run the query, click Yes.
  20584.     For an explanation of the causes of the violations, click Help.
  20585.  
  20586. If I tell it to continue on with the import, I get several more error 
  20587. messages, then when I check the users database, there are only about 200 
  20588. records.
  20589.  
  20590. What do I need to do to get this straightened out?
  20591.  
  20592. ricky@mindspring.com
  20593.  
  20594.  
  20595. -
  20596.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20597.  with "unsubscribe usr-tc" in the body of the message.
  20598.  For information on digests or retrieving files and old messages send
  20599.  "help" to the same address.  Do not use quotes in your message.
  20600.  
  20601.  
  20602. -------------------------------------------------------------------------------
  20603.  
  20604. From: Blake Fithen <fithen@NetworksPlus.com>
  20605. Subject: RE: (usr-tc) 3Com Security and Accounting upgrade from 6.0.8 to 6
  20606. Date: 16 Mar 1999 18:16:13 -0600
  20607.  
  20608. I had that error once.  Are you importing accounting information?
  20609. If so, I would uncheck that box in the appropriate window.  One 
  20610. other problem I ran in to with 6.0.9 is our two session users
  20611. would not get logged in.  Strange thing is I didn't even see them
  20612. hitting the hub via "mon ppp" or "mon radius".  After I changed the
  20613. "maximum number of concurrent sessions" from 2 to 0 they got right
  20614. in. (a two channel ISDN user).
  20615.  
  20616. blake
  20617.  
  20618. > -----Original Message-----
  20619. > From: Rick [mailto:rickyz@mindspring.com]
  20620. > Sent: Tuesday, March 16, 1999 5:54 PM
  20621. > To: usr-tc@lists.xmission.com
  20622. > Subject: (usr-tc) 3Com Security and Accounting upgrade from 6.0.8 to
  20623. > 6.0.90
  20624. > 
  20625. > 
  20626. > I did a test install of 6.0.9.  It installs to a different 
  20627. > directory from 
  20628. > the previous 6.0.8 -- c:\3comsuite vs. c:\usrsuite.  If 
  20629. > c:\usrsuite exists, 
  20630. > the installation routine apparently renames (or copies) the existing 
  20631. > usradius.mdb to old.mdb in preparation for importing the records.
  20632. > 
  20633. > There is a database import utility under Server Setup / 
  20634. > Advanced Options / 
  20635. > Database Maintenance.  There are options for importing from 
  20636. > various other 
  20637. > versions, including 6.0.8.
  20638. > 
  20639. > So far, so good.
  20640. > 
  20641. > However, when I try to import the database, I get the following error 
  20642. > message:
  20643. > 
  20644. > 3COM Security and Accounting Database Manager can't append 
  20645. > all the records 
  20646. > in the append query.
  20647. >     3COM Security and Accounting Database Manager set 0 
  20648. > field(s) to Null 
  20649. > due to a type
  20650. >     conversion failure, and it didn't add 3476 record(s) to 
  20651. > the table due 
  20652. > to key violations, 0
  20653. >     record(s) due to lock violations, and 0 record(s) due to 
  20654. > validation 
  20655. > rule violations.
  20656. >     Do you want to run the action query anyway?
  20657. >     To ignore the error(s) and run the query, click Yes.
  20658. >     For an explanation of the causes of the violations, click Help.
  20659. > 
  20660. > If I tell it to continue on with the import, I get several more error 
  20661. > messages, then when I check the users database, there are 
  20662. > only about 200 
  20663. > records.
  20664. > 
  20665. > What do I need to do to get this straightened out?
  20666. > 
  20667. > ricky@mindspring.com
  20668. > 
  20669. > 
  20670. > -
  20671. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20672. >  with "unsubscribe usr-tc" in the body of the message.
  20673. >  For information on digests or retrieving files and old messages send
  20674. >  "help" to the same address.  Do not use quotes in your message.
  20675. > 
  20676.  
  20677. -
  20678.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20679.  with "unsubscribe usr-tc" in the body of the message.
  20680.  For information on digests or retrieving files and old messages send
  20681.  "help" to the same address.  Do not use quotes in your message.
  20682.  
  20683.  
  20684. -------------------------------------------------------------------------------
  20685.  
  20686. From: "Randy Cosby" <dcosby@infowest.com>
  20687. Subject: RE: (usr-tc) My latest toy TC script...
  20688. Date: 16 Mar 1999 17:35:43 -0700
  20689.  
  20690. What version of NMC are you using?  I'm getting the card names/types right,
  20691. but no lights.
  20692.  
  20693. Randy
  20694.  
  20695.  
  20696. > -----Original Message-----
  20697. > From: owner-usr-tc@lists.xmission.com
  20698. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stephen Amadei
  20699. > Sent: Tuesday, March 16, 1999 3:47 AM
  20700. > To: usr-tc@lists.xmission.com
  20701. > Subject: (usr-tc) My latest toy TC script...
  20702. >
  20703. >
  20704. >
  20705. > A couple of days ago, I was inquiring about the LED status on the USR's...
  20706. > I'd like to thank everyone who responded, and as I promised, I am sharing
  20707. > the fruits of my labor...
  20708. >
  20709. > Someone else has probably already done this, but since I couldn't find any
  20710. > code like it, I wrote my own...
  20711. >
  20712. > A "Total Control Virtual Display Program"  What this does is create
  20713. > Gif files that represent your TC units.  This is an early edition... I
  20714. > plan on prettying it up later, but it's mostly functional now, but I need
  20715. > to write a few other useless toys for my company.  ;-)
  20716. >
  20717. > Some limitations:
  20718. >
  20719. >  - It creates FOUR gif files for each of your Total Controls.  This is in
  20720. >    order to create an animated Gif file in the future, to provide for
  20721. >    blinking LEDs.  Disregard the extra GIFs.
  20722. >  - It does not support the NetServer... I didn't have one handy when I
  20723. >    built this... if someone gives me readonly access to a NetServer
  20724. >    equipped TC, I will add it.
  20725. >  - It does support the T1 card, Digital Quads, Analog Quads, D-A Quads,
  20726. >    Hiper DSP, Hiper ARC, NMC and NMC with clock.  For added cards, see
  20727. >    note above about NetServer.
  20728. >  - Requires CMU-SNMP, SNMPWALK, the GD library, GD perl library things and
  20729. >    parts of MRTG.
  20730. >  - It's absolutely not guarenteed to work anywhere... ;-)
  20731. >
  20732. > If you are feeling lucky, you can get the script at
  20733. > http://www.dandy.net/~amadei/tcview
  20734. > and see a live demo at
  20735. > http://www.dandy.net/statistics/tc.html
  20736. >
  20737. > Let me know what you think, and any suggestions.
  20738. >
  20739. >                     ----Steve
  20740. > Stephen Amadei
  20741. > Director of MIS
  20742. > Dandy Connections, Inc.
  20743. > Atlantic City, NJ
  20744. >
  20745. >
  20746. > -
  20747. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20748. >  with "unsubscribe usr-tc" in the body of the message.
  20749. >  For information on digests or retrieving files and old messages send
  20750. >  "help" to the same address.  Do not use quotes in your message.
  20751. >
  20752.  
  20753.  
  20754. -
  20755.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20756.  with "unsubscribe usr-tc" in the body of the message.
  20757.  For information on digests or retrieving files and old messages send
  20758.  "help" to the same address.  Do not use quotes in your message.
  20759.  
  20760.  
  20761. -------------------------------------------------------------------------------
  20762.  
  20763. From: "Tony Loosle" <tony@tcsourceone.com>
  20764. Subject: Re: (usr-tc) Radius Server Recommendations??
  20765. Date: 16 Mar 1999 17:56:55 -0700
  20766.  
  20767. I would be interested in looking at what you have done with the script.  I have
  20768. seen it there, but never really paid attention to it.
  20769.  
  20770. I am using ver 6.0.8 on an nt??  I wonder if it will still work?
  20771. tony
  20772.  
  20773.  
  20774. Ricky Beam wrote:
  20775.  
  20776. > On Mon, 15 Mar 1999, Chris Hanes wrote:
  20777. > >As has been noted here before, the USR Radius server scarcely works.
  20778. > >I've been looking at alternatives - in particular Cistron, Merit, and
  20779. > >Radiator - and am looking for advice.  What's the best bet in terms of
  20780. > >cost, performance, reliability, ease of maintenance, etc.?
  20781. >
  20782. > Yes, people have noted that before.  The USR radius server, as it comes from
  20783. > USR, is a very poor excuse for a RADIUS server.  HOWEVER, if you spend some
  20784. > time working on replacing the script, the core server part of the system is
  20785. > very powerful.  I look at it like buying "perl" and getting some bad "example"
  20786. > code with it.
  20787. >
  20788. > Chris, et. al., drop me a note directly if you are interested in seeing what
  20789. > magic I've done to the script and database schema.  It doesn't take 5k per
  20790. > user anymore; you can limit access for ISDN, MLPPP, X2/V.90, and
  20791. > analog/digital call enforcement as well as the usual DNIS/ANI/portgroup
  20792. > stuff.  As for speed... using SA4.3.11 (143Mhz sparc 10 / solaris 2.5.1) +
  20793. > postgres v6.3.2 (dual PII-300 / linux), the system could handle over 30
  20794. > authentication requests _per_ _second_.  (Imagine what that would be if I
  20795. > were to use Oracle or even flat files.)  (BTW, SA4 will compile and run
  20796. > perfectly under linux -- with one small change to the select() handling.)
  20797. >
  20798. > I will say this again: The script is designed for SA4.  It can be dropped into
  20799. > SA5 with minor modifications.  If will not work for SA6 with extensive
  20800. > changes.  And, as hiper hardware didn't exist when I designed the script,
  20801. > there is no specific handling for hiper hardware.
  20802. >
  20803. > IF there is interest, I can finish work already in progress in updating the
  20804. > SA4 script for SA6 (with full hiper support.)
  20805. >
  20806. > If I still had access to the source code (and some access hardware), I could
  20807. > do some beautiful things to that server... faster client auth checks, true
  20808. > duplicate packet handling, full multithreaded processing...
  20809. >
  20810. > --Ricky
  20811. >
  20812. > -
  20813. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20814. >  with "unsubscribe usr-tc" in the body of the message.
  20815. >  For information on digests or retrieving files and old messages send
  20816. >  "help" to the same address.  Do not use quotes in your message.
  20817.  
  20818.  
  20819. -
  20820.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20821.  with "unsubscribe usr-tc" in the body of the message.
  20822.  For information on digests or retrieving files and old messages send
  20823.  "help" to the same address.  Do not use quotes in your message.
  20824.  
  20825.  
  20826. -------------------------------------------------------------------------------
  20827.  
  20828. From: <pferraro@wna-linknet.com>
  20829. Subject: RE: (usr-tc) My latest toy TC script...
  20830. Date: 16 Mar 1999 22:45:52 -0500 (EST)
  20831.  
  20832.  
  20833.     Me tooo.....  Get the hubs cards, but no LIGHTS!  I do get the Hub
  20834. name in the NMC! 8-)
  20835.  
  20836. ==============================================================================
  20837. Phillip Ferraro                WorldNet Access, Inc
  20838. pferraro@wna-linknet.com    Onslow County's PREMIER InterNet Service 
  20839. Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  20840. FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  20841. ==============================================================================
  20842.  
  20843. On Tue, 16 Mar 1999, Randy Cosby wrote:
  20844.  
  20845. > What version of NMC are you using?  I'm getting the card names/types right,
  20846. > but no lights.
  20847. > 
  20848. > Randy
  20849. > 
  20850. > 
  20851. > > -----Original Message-----
  20852. > > From: owner-usr-tc@lists.xmission.com
  20853. > > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Stephen Amadei
  20854. > > Sent: Tuesday, March 16, 1999 3:47 AM
  20855. > > To: usr-tc@lists.xmission.com
  20856. > > Subject: (usr-tc) My latest toy TC script...
  20857. > >
  20858. > >
  20859. > >
  20860. > > A couple of days ago, I was inquiring about the LED status on the USR's...
  20861. > > I'd like to thank everyone who responded, and as I promised, I am sharing
  20862. > > the fruits of my labor...
  20863. > >
  20864. > > Someone else has probably already done this, but since I couldn't find any
  20865. > > code like it, I wrote my own...
  20866. > >
  20867. > > A "Total Control Virtual Display Program"  What this does is create
  20868. > > Gif files that represent your TC units.  This is an early edition... I
  20869. > > plan on prettying it up later, but it's mostly functional now, but I need
  20870. > > to write a few other useless toys for my company.  ;-)
  20871. > >
  20872. > > Some limitations:
  20873. > >
  20874. > >  - It creates FOUR gif files for each of your Total Controls.  This is in
  20875. > >    order to create an animated Gif file in the future, to provide for
  20876. > >    blinking LEDs.  Disregard the extra GIFs.
  20877. > >  - It does not support the NetServer... I didn't have one handy when I
  20878. > >    built this... if someone gives me readonly access to a NetServer
  20879. > >    equipped TC, I will add it.
  20880. > >  - It does support the T1 card, Digital Quads, Analog Quads, D-A Quads,
  20881. > >    Hiper DSP, Hiper ARC, NMC and NMC with clock.  For added cards, see
  20882. > >    note above about NetServer.
  20883. > >  - Requires CMU-SNMP, SNMPWALK, the GD library, GD perl library things and
  20884. > >    parts of MRTG.
  20885. > >  - It's absolutely not guarenteed to work anywhere... ;-)
  20886. > >
  20887. > > If you are feeling lucky, you can get the script at
  20888. > > http://www.dandy.net/~amadei/tcview
  20889. > > and see a live demo at
  20890. > > http://www.dandy.net/statistics/tc.html
  20891. > >
  20892. > > Let me know what you think, and any suggestions.
  20893. > >
  20894. > >                     ----Steve
  20895. > > Stephen Amadei
  20896. > > Director of MIS
  20897. > > Dandy Connections, Inc.
  20898. > > Atlantic City, NJ
  20899. > >
  20900. > >
  20901. > > -
  20902. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20903. > >  with "unsubscribe usr-tc" in the body of the message.
  20904. > >  For information on digests or retrieving files and old messages send
  20905. > >  "help" to the same address.  Do not use quotes in your message.
  20906. > >
  20907. > 
  20908. > 
  20909. > -
  20910. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20911. >  with "unsubscribe usr-tc" in the body of the message.
  20912. >  For information on digests or retrieving files and old messages send
  20913. >  "help" to the same address.  Do not use quotes in your message.
  20914. > 
  20915.  
  20916.  
  20917. -
  20918.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  20919.  with "unsubscribe usr-tc" in the body of the message.
  20920.  For information on digests or retrieving files and old messages send
  20921.  "help" to the same address.  Do not use quotes in your message.
  20922.  
  20923.  
  20924. -------------------------------------------------------------------------------
  20925.  
  20926. From: Brian <signal@shreve.net>
  20927. Subject: (usr-tc) RIP/OSPF Routing
  20928. Date: 16 Mar 1999 23:23:21 -0600 (EST)
  20929.  
  20930.  
  20931. Just trying to find out how all of you are dealing with the ARC only being
  20932. able to do RIP (4.1.x).
  20933.  
  20934. We take in RIP at our router, and redistribute via OSPF.........is this
  20935. what alot of you do, or do you do something else?
  20936.  
  20937. I am setting up some POPs with total controls that are tied back to our
  20938. main site via serial links (t1's).  My plan is to redistribute rip into
  20939. ospf and get it back to our main router.
  20940.  
  20941. I thought of just distributing it via rip, but wasn't having much luck.
  20942. Since its going over a serial link, I would have to use "neighbor" in my
  20943. rip statment etc, and I don't like how I can't just delcare a "network
  20944. a.b.c.d mask a.b.c.d" and how you have to just use a classfull mask.
  20945.  
  20946. If someone who has some pops connected via RIP and/or OSPF could post
  20947. their config (for just the router rip/router ospf) that would be great.
  20948. Also tell me ip of router and arc.
  20949.  
  20950. Shouldn't something like this work for say a RIP only config:
  20951.  
  20952.  
  20953.  
  20954. Main Router (208.206.76.1/24)
  20955. ==============================
  20956. router rip
  20957.  version 2
  20958.  timers basic 30 30 2 60 300
  20959.  network 208.206.76.0
  20960.  no auto-summary
  20961.  neighbor 208.242.79.1
  20962.  neighbor 208.242.79.16
  20963.  
  20964.  
  20965. POP 1 (208.242.79.1/28)
  20966. =======================
  20967. router rip
  20968.  version 2
  20969.  timers basic 30 30 2 60 300
  20970.  network 208.242.79.0
  20971.  no auto-summary
  20972.  neighbor 208.206.76.1
  20973.  
  20974. POP 3 (208.242.79.16/28)
  20975. ========================
  20976. router rip
  20977.  version 2
  20978.  timers basic 30 30 2 60 300
  20979.  network 208.242.79.0
  20980.  no auto-summary
  20981.  neighbor 208.206.76.1
  20982.  
  20983.  
  20984. A few questions:
  20985.  
  20986. 1. ip directed broadcasts would have to be "enabled" (not disabled) for
  20987. RIP information to cross the serial links?
  20988.  
  20989. 2. The pops are just /28's because thats just for the switch, arc's,
  20990. router eth interface.  The IP pools are seperate /24's that will be routed
  20991. to those pops.  
  20992.  
  20993. Brian
  20994.  
  20995.  
  20996.  
  20997.  
  20998.  
  20999. Brian Feeny (BF304)     signal@shreve.net   
  21000. 318-222-2638 x 109    http://www.shreve.net/~signal      
  21001. Network Administrator   ShreveNet Inc. (ASN 11881)           
  21002.  
  21003.  
  21004. -
  21005.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21006.  with "unsubscribe usr-tc" in the body of the message.
  21007.  For information on digests or retrieving files and old messages send
  21008.  "help" to the same address.  Do not use quotes in your message.
  21009.  
  21010.  
  21011. -------------------------------------------------------------------------------
  21012.  
  21013. From: Stephen Amadei <amadei@dandy.net>
  21014. Subject: RE: (usr-tc) My latest toy TC script...
  21015. Date: 17 Mar 1999 01:42:19 -0500 (EST)
  21016.  
  21017. On Tue, 16 Mar 1999, Randy Cosby wrote:
  21018.  
  21019. > What version of NMC are you using?  I'm getting the card names/types right,
  21020. > but no lights.
  21021.  
  21022. I have two physical NMC's... one comes up as a "Network Management Card",
  21023. and one comes up as a "Network Management Card with Clock"... both are
  21024. running the lastest firmware, 5.5.5.  Unless there is a difference in the
  21025. locations of the LEDs MIBs, the NMC shouldn't matter.
  21026.  
  21027. Anyway, I have posted a newer version that includes a debug feature.  Edit
  21028. the tcview file and set debug=1 on line 37.  Run the script:
  21029. "./tcview your.nmc.here.net yourcommunity test 2> output" and email me the
  21030. output, and I will check to see what's going on.  I have had _many_
  21031. reports that the cards are being drawn, but the LEDs are all coming in
  21032. dark.  At this point, I'm not sure if this is a hardware difference or a 
  21033. software difference, but I didn't see anthing like this with my equipment.
  21034.  
  21035.                     ----Steve
  21036. Stephen Amadei
  21037. Director of MIS
  21038. Dandy Connections, Inc.
  21039. Atlantic City, NJ
  21040.  
  21041.  
  21042. -
  21043.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21044.  with "unsubscribe usr-tc" in the body of the message.
  21045.  For information on digests or retrieving files and old messages send
  21046.  "help" to the same address.  Do not use quotes in your message.
  21047.  
  21048.  
  21049. -------------------------------------------------------------------------------
  21050.  
  21051. From: Jeff Mcadams <jeffm@iglou.com>
  21052. Subject: Re: (usr-tc) RIP/OSPF Routing
  21053. Date: 17 Mar 1999 01:30:55 -0500 (EST)
  21054.  
  21055. Thus spake Brian
  21056. >We take in RIP at our router, and redistribute via OSPF.........is this
  21057. >what alot of you do, or do you do something else?
  21058.  
  21059. I think that's pretty much standard procedure.  :)
  21060.  
  21061. >I am setting up some POPs with total controls that are tied back to our
  21062. >main site via serial links (t1's).  My plan is to redistribute rip into
  21063. >ospf and get it back to our main router.
  21064.  
  21065. >I thought of just distributing it via rip, but wasn't having much luck.
  21066. >Since its going over a serial link, I would have to use "neighbor" in my
  21067. >rip statment etc, and I don't like how I can't just delcare a "network
  21068. >a.b.c.d mask a.b.c.d" and how you have to just use a classfull mask.
  21069.  
  21070. Nope, and nope.  You can use a network statement for serial links.
  21071. Assuming you've assigned /30's to your serial links, you can just put a
  21072. network statement on there for that /30, works like a charm.  As far as
  21073. the mask.  It doesn't have to be classful for RIPv2.  Keep in mind that
  21074. its a wildcard mask, not a netmask...in other word, invert all your bits.
  21075. Personally, I just assign all of our /30's for our internal t1's out of
  21076. the same /24, and since I run OSPF across all of them, just put the
  21077. network statement in the OSPF config for the whole /24.  That way if I
  21078. add a t1 to a POP (one of our POPs just got a second t1 back to the main
  21079. city) I don't have to remember to add another network statement for it.
  21080. The previous network statement for the /24 covers it already.
  21081.  
  21082. >A few questions:
  21083.  
  21084. >1. ip directed broadcasts would have to be "enabled" (not disabled) for
  21085. >RIP information to cross the serial links?
  21086.  
  21087. Nope, RIP uses direct broadcasts, it never directs it.  RIP only
  21088. advertises information hop by hop, it never directed broadcasts routing
  21089. information to a remote network broadcast's address (ref. my recent
  21090. posting about classless routing as to why it really isn't feasible for
  21091. it to know what the remote broadcast addresses really are)
  21092.  
  21093. >2. The pops are just /28's because thats just for the switch, arc's,
  21094. >router eth interface.  The IP pools are seperate /24's that will be routed
  21095. >to those pops.  
  21096.  
  21097. Should work fine.  If the NETServers/Arcs will be advertising the /24's
  21098. to the Cisco's, the Cisco's will pass on that routing information, no
  21099. problem.
  21100.  
  21101. You could do the whole thing using just RIP if you want...that's how I
  21102. started out with us, advertising everything all the way around with RIP,
  21103. eventually switched over to OSPF since RIP just really doesn't scale
  21104. very well.  The transition was actually not too bad with some careful
  21105. route-maps.  Was actually done gradually (over the course of a whole
  21106. day) without any loss of service in the process.
  21107. -- 
  21108. Jeff McAdams                            Email: jeffm@iglou.com
  21109. Head Network Administrator              Voice: (502) 966-3848
  21110. IgLou Internet Services                        (800) 436-4456
  21111.  
  21112. -
  21113.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21114.  with "unsubscribe usr-tc" in the body of the message.
  21115.  For information on digests or retrieving files and old messages send
  21116.  "help" to the same address.  Do not use quotes in your message.
  21117.  
  21118.  
  21119. -------------------------------------------------------------------------------
  21120.  
  21121. From: "Ray Whelan" <Ray_Whelan@eur.3com.com>
  21122. Subject: Re: (usr-tc) Country codes on HDMs
  21123. Date: 17 Mar 1999 09:28:01 +0000
  21124.  
  21125.  
  21126.  
  21127. Hi
  21128.  
  21129. Country codes setting for the HDM are only applicable to version 2.0. x code
  21130. which is in Beta,
  21131. We have kept the same command settings with the DSP as was used with the Quad.
  21132. The only difference is one command changes will change all the modems on the DSP
  21133. as for the Quad you had to access each modem.
  21134.  
  21135. Ray Whelan
  21136. Net Sys
  21137. Dublin
  21138.  
  21139.  
  21140.  
  21141.  
  21142. "Andres Kroonmaa" <andre@ml.ee> on 16/03/99 22:28:47
  21143.  
  21144. Please respond to usr-tc@lists.xmission.com
  21145.  
  21146. cc:    (Ray Whelan/IE/3Com)
  21147.  
  21148.  
  21149.  
  21150.  
  21151.  
  21152.  Hi,
  21153.  
  21154.  way back with Quads it was sometimes needed to change country codes
  21155.  on modems. What about HDM's? How can you change that on HDM?
  21156.  
  21157.  
  21158.  
  21159.  ----------------------------------------------------------------------
  21160.   Andres Kroonmaa                                mail: andre@online.ee
  21161.   Network Manager
  21162.   Organization:            MicroLink Online       Tel:        6308 909
  21163.   Tallinn, Sakala 19                              Pho:  +372  6308 909
  21164.   Estonia, EE0001        http://www.online.ee     Fax:  +372  6308 901
  21165.  ----------------------------------------------------------------------
  21166.  
  21167. -
  21168.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21169.  with "unsubscribe usr-tc" in the body of the message.
  21170.  For information on digests or retrieving files and old messages send
  21171.  "help" to the same address.  Do not use quotes in your message.
  21172.  
  21173.  
  21174.  
  21175.  
  21176.  
  21177.  
  21178.  
  21179.  
  21180.  
  21181. -
  21182.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21183.  with "unsubscribe usr-tc" in the body of the message.
  21184.  For information on digests or retrieving files and old messages send
  21185.  "help" to the same address.  Do not use quotes in your message.
  21186.  
  21187.  
  21188. -------------------------------------------------------------------------------
  21189.  
  21190. From: MegaZone <megazone@megazone.org>
  21191. Subject: Re: (usr-tc) Radius Server Recommendations??
  21192. Date: 17 Mar 1999 01:23:51 -0800 (PST)
  21193.  
  21194. Once upon a time Ray Bellis shaped the electrons to say...
  21195. >simple pluggable extensions which can be chained together to provide
  21196. >sophisticated authentication and accounting mechanisms.
  21197. >
  21198. >I've already used the API to implement
  21199. >
  21200. >o  Access control based on DNIS and JDBC
  21201. >o  GRIC roaming proxy
  21202. >o  Unix password authentication (uses JNI to access getpwnam)
  21203. >o  JDBC password authentication
  21204. >o  JDBC attribute setting
  21205. >o  JDBC accounting
  21206. >
  21207. >I'd be interested in getting feedback from other RADIUS users on
  21208. >whether an easily extensible RADIUS server would have any demand
  21209. >(commercial or otherwise).
  21210.  
  21211. Seeing as Lucent currently markets *2* extensible 100% Java RADIUS servers -
  21212. RADIUS ABM and Port Authority (though they are merging them into one server
  21213. with the features of both, keeping the PA name (it goes with PM)) - I think
  21214. you could safely assume the answer is *yes*.
  21215.  
  21216. Radiator is also extremely popular because it is extremely easy to extend -
  21217. being all Perl.  (And it performs well too - especially if you pre-compile 
  21218. it with the Perl Compiler.)
  21219.  
  21220. -MZ
  21221. -- 
  21222. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  21223. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  21224. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  21225. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  21226. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  21227.  
  21228. -
  21229.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21230.  with "unsubscribe usr-tc" in the body of the message.
  21231.  For information on digests or retrieving files and old messages send
  21232.  "help" to the same address.  Do not use quotes in your message.
  21233.  
  21234.  
  21235. -------------------------------------------------------------------------------
  21236.  
  21237. From: MegaZone <megazone@megazone.org>
  21238. Subject: Re: (usr-tc) Missing attribute codes
  21239. Date: 17 Mar 1999 01:27:54 -0800 (PST)
  21240.  
  21241. Once upon a time Sam Lowe shaped the electrons to say...
  21242. >Do any of you fine list members know what the attribute codes 38978 & 38979 refer to.  I suspect they have something to do with the HIPER cards, but can't find this info anywhere.
  21243.  
  21244. Sounds like a couple of VSAs:
  21245.  
  21246. ATTRIB_NMC      USR-Modem-Training-Time                 0x9842  integer
  21247. ATTRIB_NMC      USR-Interface-Index                     0x9843  integer
  21248.  
  21249. -MZ
  21250. -- 
  21251. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  21252. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  21253. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  21254. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  21255. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  21256.  
  21257. -
  21258.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21259.  with "unsubscribe usr-tc" in the body of the message.
  21260.  For information on digests or retrieving files and old messages send
  21261.  "help" to the same address.  Do not use quotes in your message.
  21262.  
  21263.  
  21264. -------------------------------------------------------------------------------
  21265.  
  21266. From: MegaZone <megazone@megazone.org>
  21267. Subject: Re: (usr-tc) Radius Probs
  21268. Date: 17 Mar 1999 01:32:05 -0800 (PST)
  21269.  
  21270. Once upon a time Jamie Orzechowski shaped the electrons to say...
  21271. >here is my DEFAULT radius user
  21272. >
  21273. >DEFAULT         Authentication-Type= Unix-PW, Framed-Protocol= PPP,
  21274. >Simultaneous-use= 2
  21275.  
  21276. Looks like Merit - correct?
  21277.  
  21278. First off, you have Framed-Protocol as a Check Item, not a Reply Item.
  21279. So it only matches PAP/CHAP users.  Remove it as a Check Item and make
  21280. it a Reply Item.
  21281.  
  21282. As for Simultaneous-Use - well, that's non-standard, server specific so I
  21283. don't know if you really want it as a Check Item (as you have it) or a 
  21284. Reply Item.
  21285.  
  21286. -MZ
  21287. -- 
  21288. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  21289. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  21290. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  21291. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  21292. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  21293.  
  21294. -
  21295.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21296.  with "unsubscribe usr-tc" in the body of the message.
  21297.  For information on digests or retrieving files and old messages send
  21298.  "help" to the same address.  Do not use quotes in your message.
  21299.  
  21300.  
  21301. -------------------------------------------------------------------------------
  21302.  
  21303. From: MegaZone <megazone@megazone.org>
  21304. Subject: Re: (usr-tc) Serial Ports on ARCS, DSP's etc
  21305. Date: 17 Mar 1999 01:38:38 -0800 (PST)
  21306.  
  21307. Once upon a time Paul Oster shaped the electrons to say...
  21308. >  Anyone know of a device that'll let me hook a modem up to it and
  21309. >"switch" a dialin between numerious serial ports (which will be connected
  21310. >to the above equipent)  Something CHEAP would be preferable... any
  21311. >suggestions?
  21312.  
  21313. Aka a console server.
  21314.  
  21315. PortMaster-2, PortMaster-25, Cisco 2511, Remote Annex 2000, etc, etc.
  21316.  
  21317. -MZ
  21318. -- 
  21319. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  21320. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  21321. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  21322. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  21323. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  21324.  
  21325.  
  21326. -
  21327.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21328.  with "unsubscribe usr-tc" in the body of the message.
  21329.  For information on digests or retrieving files and old messages send
  21330.  "help" to the same address.  Do not use quotes in your message.
  21331.  
  21332.  
  21333. -------------------------------------------------------------------------------
  21334.  
  21335. From: MegaZone <megazone@megazone.org>
  21336. Subject: Re: (usr-tc) Serial Ports on ARCS, DSP's etc
  21337. Date: 17 Mar 1999 01:39:38 -0800 (PST)
  21338.  
  21339. Once upon a time Pete Ashdown shaped the electrons to say...
  21340. >No please, buy my 32 port Xylogics Annex 3.  I'll sell it to you CHEAP!!
  21341.  
  21342. What did Paul ever do to you to deserve such a fate? ;-)
  21343.  
  21344. -MZ, who used to work for Xylo...
  21345. -- 
  21346. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  21347. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  21348. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  21349. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  21350. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  21351.  
  21352. -
  21353.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21354.  with "unsubscribe usr-tc" in the body of the message.
  21355.  For information on digests or retrieving files and old messages send
  21356.  "help" to the same address.  Do not use quotes in your message.
  21357.  
  21358.  
  21359. -------------------------------------------------------------------------------
  21360.  
  21361. From: MegaZone <megazone@megazone.org>
  21362. Subject: Re: (usr-tc) Serial Ports on ARCS, DSP's etc
  21363. Date: 17 Mar 1999 01:40:36 -0800 (PST)
  21364.  
  21365. Once upon a time Charles Sprickman shaped the electrons to say...
  21366. >Actually, we've got lots of old stuff for sale...  I know this isn't the
  21367. >right forum, but other than usenet, where's a good place to sell ISP-like
  21368. >equipment?
  21369.  
  21370. isp-equipment@isp-equipment.com and isp-services@ispc.org
  21371.  
  21372. And eBay of course.
  21373.  
  21374. -MZ
  21375. -- 
  21376. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  21377. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  21378. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  21379. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  21380. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  21381.  
  21382. -
  21383.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21384.  with "unsubscribe usr-tc" in the body of the message.
  21385.  For information on digests or retrieving files and old messages send
  21386.  "help" to the same address.  Do not use quotes in your message.
  21387.  
  21388.  
  21389. -------------------------------------------------------------------------------
  21390.  
  21391. From: MegaZone <megazone@megazone.org>
  21392. Subject: Re: (usr-tc) Radius Server Recommendations??
  21393. Date: 17 Mar 1999 01:50:54 -0800 (PST)
  21394.  
  21395. Once upon a time Chris Hanes shaped the electrons to say...
  21396. >As has been noted here before, the USR Radius server scarcely works.
  21397. >I've been looking at alternatives - in particular Cistron, Merit, and
  21398. >Radiator - and am looking for advice.  What's the best bet in terms of
  21399. >cost, performance, reliability, ease of maintenance, etc.?
  21400.  
  21401. You can't beat the price on Cistron - it is free.  And you get all of the
  21402. source, so you can tweak it as you like.  It includes simultaneous use 
  21403. controls for all the popular platforms, including 3Com, can call external
  21404. programs during the auth process, can cascade entries, etc.  And there are
  21405. a number of SQL patches available.  Cistron is becoming the focus of a 
  21406. growing open source RADIUS effort, lots of interesting things happening there.
  21407.  
  21408. Radiator is probably the most bang for the buck - I believe pricing runs in
  21409. the $600-$1000 range.  It has a TON of features, and is all Perl so it is
  21410. incredibly customizable.  Now, some people think Perl means poor performance -
  21411. bullshit.  There are ISPs using Radiator ith tens of thousands of users.
  21412. It is intepreted/compiled when you start it and once running it is in
  21413. memory.  If you want ever better performance you can pre-compile it with the
  21414. Perl Compiler.  Since it is Perl it can talk to most every database you could
  21415. want.
  21416.  
  21417. If you're on NT then IEA's RadiusNT is probably the best thing going.  They
  21418. were the first with an effecting NT RADIUS server, and they likely have the
  21419. largest market share for RADIUS on NT.  Nice product.
  21420.  
  21421. At the 'high end' - in terms of performance, features, and price - are
  21422. the major commercial servers such as Lucent's RADIUS ABM and Port Authority
  21423. (both 100% Java, feature laden, high performance, with APIs for extensions),
  21424. and Funk's Steel-Belted RADIUS.
  21425.  
  21426. -MZ
  21427. -- 
  21428. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  21429. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  21430. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  21431. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  21432. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  21433.  
  21434. -
  21435.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21436.  with "unsubscribe usr-tc" in the body of the message.
  21437.  For information on digests or retrieving files and old messages send
  21438.  "help" to the same address.  Do not use quotes in your message.
  21439.  
  21440.  
  21441. -------------------------------------------------------------------------------
  21442.  
  21443. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  21444. Subject: (usr-tc) DNIS dynamic config summary
  21445. Date: 17 Mar 1999 07:42:16 -0500 (EST)
  21446.  
  21447.  
  21448. Welp, I tested the plan outlined in previous threads, and have some
  21449. excellent news. (:
  21450.  
  21451. RECAP:
  21452.  
  21453. The problem to be solved is having to tell customers who typically
  21454. have lame modems [how] to turn off [some feature like v42bis] so they
  21455. can connect to your ultracoolhightech gear. First, telling them that
  21456. makes you sound lame. Second, for a high percentage of customers, the
  21457. act of telling them how is, umm, problematic.
  21458.  
  21459. The solution to it is simple on your HDSP (maybe quads too, I dunno
  21460. about them), and makes you look like the ultracoolguru that you are. (:
  21461.  
  21462.  
  21463. OVERVIEW:
  21464.  
  21465. The idea is to have two different modem configurations: one is set up
  21466. for maximum performance on modern modems with good code. 56k stuff and
  21467. fancy compression and the like. The other configuration is designed
  21468. to connect with anything...sacrificing some of the bells and whistles
  21469. that freak out lame modems.
  21470.  
  21471. You then get another number pointed to your huntgroup, and configure
  21472. the modems differently based on what number the customer called.
  21473.  
  21474. At that point, when a customer can't connect, you can just tell 'em
  21475. to try the other number.
  21476.  
  21477.  
  21478. HOWTO:
  21479.  
  21480. Ensure that the telco is providing you with DNIS digits; use the
  21481. performance monitor in TCM to see if they're coming in. If you don't
  21482. see 'em or they don't look right, verify the setting of 'DNIS-Based
  21483. Incoming Call Digits' in the modem and/or template configuration under
  21484. the 'Call Control' group. If you are unsure of what to set it to, you
  21485. can either experiment or call your telco and ask how many they send,
  21486. whichever is easier in your circumstance. If you're on T1's instead of
  21487. PRI's there's probably other configuration items that need verification,
  21488. [mftones or dtmftones??] I don't know.
  21489.  
  21490. Call your telco and get another phone number pointed to the head of
  21491. your huntgroup. When they get around to doing it, give it a quick call
  21492. while watching the modems' performance monitor and verify that the
  21493. DNIS numbers are what you think they are.
  21494.  
  21495. [I do my HDSP configuration via templates, so that's how I'll explain
  21496. it]
  21497.  
  21498. In TCM, select your HDSP cards and hit 'Configure'. Select the Template(s)
  21499. you're using. Go to 'Call Control Options'. Scroll down and make sure
  21500. that 'Call Init String' is set to 'enable', and 'ANI/DNIS Call Init
  21501. Strings' is set to 'dnisBase'. Also note the 'DNIS-Based Incoming Call'
  21502. value if you didn't do it in the first step above.
  21503.  
  21504. Then go to the 'DNIS Access Codes' parameter group. For the 'DNIS
  21505. Group 1' parameter, enter the DNIS number (as seen on your TCM
  21506. Performance Monitor) for your newly added second phone number. For
  21507. the 'DNIS Init String 1' parameter, enter in the AT command string
  21508. which will switch the modem from your normal configuration to your
  21509. connect-with-anything configuration (discussed below).
  21510.  
  21511. Hit 'Ok'. Then go to 'Commands', select 'Software' and 'Refresh
  21512. Template 1 Config Channels', and then hit 'Execute'. Close the window
  21513. when you're done, and you're ready to test it.
  21514.  
  21515. Fire up TCM's performance monitor. Call in to your rack using your
  21516. normal phone number and note the stuff negiotiated. Then call in using
  21517. the new phone number, and check again. If it works for you like it
  21518. worked here, you'll see appropriate changes (my test string turned off
  21519. compression and disabled x2 & v90....and I see that no compression gets
  21520. negiotiated and 'x2 status' is 'x2v90disabledLocal').
  21521.  
  21522. Save everything to NVRAM and tell your tech support people the good
  21523. news. (:
  21524.  
  21525.  
  21526. THE INIT STRING:
  21527.  
  21528. Here, I want to default to my max performance settings, so that's how
  21529. I config everything in my templates and set the modems to by default.
  21530.  
  21531. Since that's how the modem is set, my 'secondary' init string only
  21532. has to reflect the differences, i.e. the turning off of various features.
  21533.  
  21534. At the moment, I'm using 'AT&K0S27.3=1S76.1=1S81.5=1':
  21535.  
  21536.          &K0:     turns off compression
  21537.          S27.3=1: turns off 2100Hz answer tone
  21538.          S76.1=1: turns off x2
  21539.          S81.5=1: turns off v90
  21540.  
  21541. Any insight anyone can give regarding the 'perfect' string to use
  21542. for this would be helpful. I'm sure there are other things that
  21543. probably should be included here but just haven't played with it
  21544. enough to find out. v42 Selective reject, maybe?
  21545.  
  21546. Enjoy!!!
  21547.  
  21548. Lon Stockton
  21549. MoonStar
  21550.  
  21551.  
  21552. -
  21553.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21554.  with "unsubscribe usr-tc" in the body of the message.
  21555.  For information on digests or retrieving files and old messages send
  21556.  "help" to the same address.  Do not use quotes in your message.
  21557.  
  21558.  
  21559. -------------------------------------------------------------------------------
  21560.  
  21561. From: Erik Zweers <zweers@execulink.com>
  21562. Subject: Re: (usr-tc) odd problem
  21563. Date: 17 Mar 1999 08:56:14 -0500
  21564.  
  21565. Paul Oster wrote:
  21566. > 
  21567. >   umm, well, my call with 3com seems to have solved this, they told me not
  21568. > to set MTU in radius....  Who do I call to make this into an official bug
  21569. > report.
  21570. > 
  21571. > Paul M. Oster <devious@minot.com>               http://www.minot.com/
  21572. > Magic Internet Services                         (701) 838-1265
  21573. > Minots FIRST Internet Connection
  21574. > 
  21575.  
  21576. Dealt with something like this before, but not TC related.  I'll assume
  21577. that you were setting the MTU at lower then 1500.  Anyways, I'm not sure
  21578. about the first two sites, but many sites on the net block ICMP from
  21579. entering into their network.  Anyways, any sites that have this
  21580. implemented (Microsoft is another one) will fail to communicate if the
  21581. size of the file is larger the the size of the MTU.
  21582.  
  21583. ICMP is involved in the process of reducing the size of the packets.  I
  21584. believe the type is ICMP_UNREACH_NEEDFRAG, anyways, since certain sites
  21585. which are no less running incredibly secure servers have decided to
  21586. block ICMP, we can't adjust MTU anymore.
  21587.  
  21588. Erik.
  21589.  
  21590. -
  21591.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21592.  with "unsubscribe usr-tc" in the body of the message.
  21593.  For information on digests or retrieving files and old messages send
  21594.  "help" to the same address.  Do not use quotes in your message.
  21595.  
  21596.  
  21597. -------------------------------------------------------------------------------
  21598.  
  21599. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  21600. Subject: Re: (usr-tc) DNIS dynamic config summary
  21601. Date: 17 Mar 1999 09:13:31 -0500 (EST)
  21602.  
  21603.  
  21604. Oops...looks like I left out an obvious step....
  21605.  
  21606.  
  21607. On Wed, 17 Mar 1999, Lon R. Stockton, Jr. wrote:
  21608. > [...]
  21609. > Then go to the 'DNIS Access Codes' parameter group. For the 'DNIS
  21610. > Group 1' parameter, enter the DNIS number (as seen on your TCM
  21611. > Performance Monitor) for your newly added second phone number. For
  21612. > the 'DNIS Init String 1' parameter, enter in the AT command string
  21613. > which will switch the modem from your normal configuration to your
  21614. > connect-with-anything configuration (discussed below).
  21615.  
  21616. After this, enter the AT command string that reverses the stuff you
  21617. did in the other string in the 'DNIS Default String'.
  21618.  
  21619. > At the moment, I'm using 'AT&K0S27.3=1S76.1=1S81.5=1'
  21620.  
  21621. And my DNIS Default String is 'AT&K3S27.3=0S76.1=0S81.5=0'
  21622.  
  21623.  
  21624. Lon Stockton
  21625. MoonStar
  21626.  
  21627.  
  21628.  
  21629. -
  21630.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21631.  with "unsubscribe usr-tc" in the body of the message.
  21632.  For information on digests or retrieving files and old messages send
  21633.  "help" to the same address.  Do not use quotes in your message.
  21634.  
  21635.  
  21636. -------------------------------------------------------------------------------
  21637.  
  21638. From: "Brian M. Gordon" <administrator@westelcom.com>
  21639. Subject: Re: (usr-tc) Radius Server Recommendations??
  21640. Date: 17 Mar 1999 09:30:17 -0500
  21641.  
  21642. Speaking of Radius what is the optimal configuration for a user in radius
  21643. for a default user for hiper dsp/arc dialin user?
  21644.  
  21645. Thanks,
  21646.  
  21647. Brian Gordon, MCP, A+
  21648. Network Administrator
  21649. Westelcom Internet
  21650. 518-566-8376 Voice
  21651. 518-566-8348 Fax
  21652. http://home.westelcom.com
  21653. administrator@westelcom.com
  21654. ----- Original Message -----
  21655. Sent: Wednesday, March 17, 1999 4:23 AM
  21656.  
  21657.  
  21658. >Once upon a time Ray Bellis shaped the electrons to say...
  21659. >>simple pluggable extensions which can be chained together to provide
  21660. >>sophisticated authentication and accounting mechanisms.
  21661. >>
  21662. >>I've already used the API to implement
  21663. >>
  21664. >>o  Access control based on DNIS and JDBC
  21665. >>o  GRIC roaming proxy
  21666. >>o  Unix password authentication (uses JNI to access getpwnam)
  21667. >>o  JDBC password authentication
  21668. >>o  JDBC attribute setting
  21669. >>o  JDBC accounting
  21670. >>
  21671. >>I'd be interested in getting feedback from other RADIUS users on
  21672. >>whether an easily extensible RADIUS server would have any demand
  21673. >>(commercial or otherwise).
  21674. >
  21675. >Seeing as Lucent currently markets *2* extensible 100% Java RADIUS
  21676. servers -
  21677. >RADIUS ABM and Port Authority (though they are merging them into one server
  21678. >with the features of both, keeping the PA name (it goes with PM)) - I think
  21679. >you could safely assume the answer is *yes*.
  21680. >
  21681. >Radiator is also extremely popular because it is extremely easy to extend -
  21682. >being all Perl.  (And it performs well too - especially if you pre-compile
  21683. >it with the Perl Compiler.)
  21684. >
  21685. >-MZ
  21686. >--
  21687. >-=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/>
  21688. X*=-
  21689. ><URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer,
  21690. me..
  21691. >Join ISP/C Internet Service Providers' Consortium
  21692. <URL:http://www.ispc.org/>
  21693. >"A little nonsense now and then, is relished by the wisest men"
  21694. 781-788-0130
  21695. ><URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail
  21696. Discordia!
  21697. >
  21698. >-
  21699. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21700. > with "unsubscribe usr-tc" in the body of the message.
  21701. > For information on digests or retrieving files and old messages send
  21702. > "help" to the same address.  Do not use quotes in your message.
  21703. >
  21704.  
  21705.  
  21706. -
  21707.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21708.  with "unsubscribe usr-tc" in the body of the message.
  21709.  For information on digests or retrieving files and old messages send
  21710.  "help" to the same address.  Do not use quotes in your message.
  21711.  
  21712.  
  21713. -------------------------------------------------------------------------------
  21714.  
  21715. From: Brian <signal@shreve.net>
  21716. Subject: Re: (usr-tc) RIP/OSPF Routing
  21717. Date: 17 Mar 1999 08:38:15 -0600 (EST)
  21718.  
  21719. On Wed, 17 Mar 1999, Jeff Mcadams wrote:
  21720.  
  21721. > Thus spake Brian
  21722. > >We take in RIP at our router, and redistribute via OSPF.........is this
  21723. > >what alot of you do, or do you do something else?
  21724. > 
  21725. > I think that's pretty much standard procedure.  :)
  21726. > 
  21727. > >I am setting up some POPs with total controls that are tied back to our
  21728. > >main site via serial links (t1's).  My plan is to redistribute rip into
  21729. > >ospf and get it back to our main router.
  21730. > 
  21731. > >I thought of just distributing it via rip, but wasn't having much luck.
  21732. > >Since its going over a serial link, I would have to use "neighbor" in my
  21733. > >rip statment etc, and I don't like how I can't just delcare a "network
  21734. > >a.b.c.d mask a.b.c.d" and how you have to just use a classfull mask.
  21735. > 
  21736. > Nope, and nope.  You can use a network statement for serial links.
  21737. > Assuming you've assigned /30's to your serial links, you can just put a
  21738. > network statement on there for that /30, works like a charm.  As far as
  21739.  
  21740. But I don't assign 30's, I use ip unnumbered..........can RIP broadcasts
  21741. traverse an ip unnumbered link without a neighbor statment?
  21742.  
  21743.  
  21744. > the mask.  It doesn't have to be classful for RIPv2.  Keep in mind that
  21745. > its a wildcard mask, not a netmask...in other word, invert all your bits.
  21746. > Personally, I just assign all of our /30's for our internal t1's out of
  21747. > the same /24, and since I run OSPF across all of them, just put the
  21748. > network statement in the OSPF config for the whole /24.  That way if I
  21749. > add a t1 to a POP (one of our POPs just got a second t1 back to the main
  21750. > city) I don't have to remember to add another network statement for it.
  21751. > The previous network statement for the /24 covers it already.
  21752.  
  21753. nod.
  21754.  
  21755. > 
  21756. > >A few questions:
  21757. > 
  21758. > >1. ip directed broadcasts would have to be "enabled" (not disabled) for
  21759. > >RIP information to cross the serial links?
  21760. > 
  21761. > Nope, RIP uses direct broadcasts, it never directs it.  RIP only
  21762. > advertises information hop by hop, it never directed broadcasts routing
  21763. > information to a remote network broadcast's address (ref. my recent
  21764. > posting about classless routing as to why it really isn't feasible for
  21765. > it to know what the remote broadcast addresses really are)
  21766.  
  21767. I thought that using the "neighbor" statment in a RIP config forced a
  21768. directed broadcast.    
  21769.  
  21770.  
  21771. > >2. The pops are just /28's because thats just for the switch, arc's,
  21772. > >router eth interface.  The IP pools are seperate /24's that will be routed
  21773. > >to those pops.  
  21774. > 
  21775. > Should work fine.  If the NETServers/Arcs will be advertising the /24's
  21776. > to the Cisco's, the Cisco's will pass on that routing information, no
  21777. > problem.
  21778. > 
  21779. > You could do the whole thing using just RIP if you want...that's how I
  21780. > started out with us, advertising everything all the way around with RIP,
  21781. > eventually switched over to OSPF since RIP just really doesn't scale
  21782. > very well.  The transition was actually not too bad with some careful
  21783. > route-maps.  Was actually done gradually (over the course of a whole
  21784. > day) without any loss of service in the process.
  21785.  
  21786.  
  21787. Brian
  21788.  
  21789.  
  21790. > -- 
  21791. > Jeff McAdams                            Email: jeffm@iglou.com
  21792. > Head Network Administrator              Voice: (502) 966-3848
  21793. > IgLou Internet Services                        (800) 436-4456
  21794. > 
  21795. > -
  21796. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21797. >  with "unsubscribe usr-tc" in the body of the message.
  21798. >  For information on digests or retrieving files and old messages send
  21799. >  "help" to the same address.  Do not use quotes in your message.
  21800. > 
  21801.  
  21802. Brian Feeny (BF304)     signal@shreve.net   
  21803. 318-222-2638 x 109    http://www.shreve.net/~signal      
  21804. Network Administrator   ShreveNet Inc. (ASN 11881)           
  21805.  
  21806.  
  21807. -
  21808.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21809.  with "unsubscribe usr-tc" in the body of the message.
  21810.  For information on digests or retrieving files and old messages send
  21811.  "help" to the same address.  Do not use quotes in your message.
  21812.  
  21813.  
  21814. -------------------------------------------------------------------------------
  21815.  
  21816. From: Brian <signal@Shreve.net>
  21817. Subject: Re: (usr-tc) RIP/OSPF Routing
  21818. Date: 17 Mar 1999 08:52:14 -0600 (EST)
  21819.  
  21820. > Nope, and nope.  You can use a network statement for serial links.
  21821. > Assuming you've assigned /30's to your serial links, you can just put a
  21822. > network statement on there for that /30, works like a charm.  As far as
  21823. > the mask.  It doesn't have to be classful for RIPv2.  Keep in mind that
  21824. > its a wildcard mask, not a netmask...in other word, invert all your bits.
  21825. > Personally, I just assign all of our /30's for our internal t1's out of
  21826. > the same /24, and since I run OSPF across all of them, just put the
  21827. > network statement in the OSPF config for the whole /24.  That way if I
  21828. > add a t1 to a POP (one of our POPs just got a second t1 back to the main
  21829. > city) I don't have to remember to add another network statement for it.
  21830. > The previous network statement for the /24 covers it already.
  21831. > 
  21832.  
  21833. What do you think about using 192.168.x.x space for the /30's?  Do you
  21834. think that is a good idea?  I am considering using like 192.168.1.0/24 and
  21835. assign all the serial /30's from that, then I can just do "network
  21836. 192.168.1.0 mask 0.0.0.255" and get everything talking.
  21837.  
  21838.  
  21839. > You could do the whole thing using just RIP if you want...that's how I
  21840. > started out with us, advertising everything all the way around with RIP,
  21841. > eventually switched over to OSPF since RIP just really doesn't scale
  21842. > very well.  The transition was actually not too bad with some careful
  21843. > route-maps.  Was actually done gradually (over the course of a whole
  21844. > day) without any loss of service in the process.
  21845.  
  21846. hmm, going from unnumberd to numbered shouldn't you be able to do, on a
  21847. live link:
  21848.  
  21849. int sX/X
  21850. ip address 192.168.1.5 255.255.255.252
  21851. no ip unnumbered eX/X
  21852. exit
  21853.  
  21854. or is their more to defusing the situation :)?
  21855.  
  21856. Brian
  21857.  
  21858.  
  21859. > -- 
  21860. > Jeff McAdams                            Email: jeffm@iglou.com
  21861. > Head Network Administrator              Voice: (502) 966-3848
  21862. > IgLou Internet Services                        (800) 436-4456
  21863. > 
  21864. > -
  21865. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21866. >  with "unsubscribe usr-tc" in the body of the message.
  21867. >  For information on digests or retrieving files and old messages send
  21868. >  "help" to the same address.  Do not use quotes in your message.
  21869. > 
  21870.  
  21871. Brian Feeny (BF304)     signal@shreve.net   
  21872. 318-222-2638 x 109    http://www.shreve.net/~signal      
  21873. Network Administrator   ShreveNet Inc. (ASN 11881)           
  21874.  
  21875.  
  21876. -
  21877.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21878.  with "unsubscribe usr-tc" in the body of the message.
  21879.  For information on digests or retrieving files and old messages send
  21880.  "help" to the same address.  Do not use quotes in your message.
  21881.  
  21882.  
  21883. -------------------------------------------------------------------------------
  21884.  
  21885. From: Jeff Mcadams <jeffm@iglou.com>
  21886. Subject: Re: (usr-tc) RIP/OSPF Routing
  21887. Date: 17 Mar 1999 11:15:37 -0500 (EST)
  21888.  
  21889. Thus spake Brian
  21890. >On Wed, 17 Mar 1999, Jeff Mcadams wrote:
  21891. >> Nope, and nope.  You can use a network statement for serial links.
  21892. >> Assuming you've assigned /30's to your serial links, you can just put a
  21893. >> network statement on there for that /30, works like a charm.  As far as
  21894.  
  21895. >But I don't assign 30's, I use ip unnumbered..........can RIP broadcasts
  21896. >traverse an ip unnumbered link without a neighbor statment?
  21897.  
  21898. with IP unnumbered, you may be correct.
  21899.  
  21900. >I thought that using the "neighbor" statment in a RIP config forced a
  21901. >directed broadcast.    
  21902.  
  21903. Nope, I don't believe so.  I believe the neighbor statement makes it get
  21904. sent as a unicast to that IP address rather than any type of broadcast.
  21905. -- 
  21906. Jeff McAdams                            Email: jeffm@iglou.com
  21907. Head Network Administrator              Voice: (502) 966-3848
  21908. IgLou Internet Services                        (800) 436-4456
  21909.  
  21910. -
  21911.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21912.  with "unsubscribe usr-tc" in the body of the message.
  21913.  For information on digests or retrieving files and old messages send
  21914.  "help" to the same address.  Do not use quotes in your message.
  21915.  
  21916.  
  21917. -------------------------------------------------------------------------------
  21918.  
  21919. From: David Bolen <db3l@ans.net>
  21920. Subject: Re: (usr-tc) RIP/OSPF Routing
  21921. Date: 17 Mar 1999 11:44:20 EST
  21922.  
  21923. Brian <signal@shreve.net> writes:
  21924.  
  21925. > We take in RIP at our router, and redistribute via OSPF.........is this
  21926. > what alot of you do, or do you do something else?
  21927.  
  21928. For our setup, we only use RIP (v1 at that still on the NETServers) at
  21929. the fringes in order to get the "next hop" right between our Cisco
  21930. border routers and the appropriate NETServer/HiperARC.  We don't
  21931. redistribute the RIP announcements dynamically beyond that point.
  21932.  
  21933. Our overall addressing plan is pre-allocated amongst our sites
  21934. globally, and the appropriate address prefix is configured into each
  21935. border Cisco as a static route to Null0.  This static information is
  21936. then redistributed into both OSPF and BGP for backbone routing
  21937. purposes.
  21938.  
  21939. This configuration has a key advantage that we don't flap routes
  21940. within the core just as the first user in a given prefix comes on or
  21941. off, which at a large scale can be a problem.  It also means that
  21942. routes within the core are always aggregated (while the ARC may do it,
  21943. our NETServers announce individual /32s for the dialup users), and
  21944. they can then be aggregated even further the next level up (the POP)
  21945. since they were initially allocated just for that purpose.
  21946.  
  21947. Within the backbone, dialup prefixes are always live, and can be
  21948. traced to the site from which they are announced with or without users
  21949. online.  The static route to Null0 on the border Cisco just drops such
  21950. packets on the floor once they reach the Cisco if there is no user
  21951. actually online with the specific target address.  It also avoids any
  21952. issues with the redistribution of RIP into any other protocol, since
  21953. RIP is soley used on the final ethernet leg.  We can also turn down
  21954. the RIP timers to almost nothing to remove any problems with address
  21955. reuse (next hop changing quickly as someone gets off and a new user on
  21956. a different box gets the same address) since such a timer change does
  21957. not affect the backbone proper.
  21958.  
  21959. On the "con" side, this configuration requires somewhat more
  21960. configuration (not so much during initial install as during later
  21961. maintenance/modification), and it also does have a disadvantage that
  21962. except in special cases, address space is not mobile at all -
  21963. dynamically assigned within a site, but not across the backbone.
  21964.  
  21965. -- David
  21966.  
  21967. /-----------------------------------------------------------------------\
  21968.  \               David Bolen              \  Internet: db3l@ans.net    /
  21969.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  21970.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  21971. \-----------------------------------------------------------------------/
  21972.  
  21973. -
  21974.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  21975.  with "unsubscribe usr-tc" in the body of the message.
  21976.  For information on digests or retrieving files and old messages send
  21977.  "help" to the same address.  Do not use quotes in your message.
  21978.  
  21979.  
  21980. -------------------------------------------------------------------------------
  21981.  
  21982. From: Scott Boggs <sboggs@unitedbank.net>
  21983. Subject: RE: (usr-tc) disconnect problems
  21984. Date: 17 Mar 1999 12:07:30 -0500
  21985.  
  21986. I had the exact same situation, except my modem cards were HiperDSPs.
  21987. 3com support told me the same thing about users upgrading their winmodem
  21988. software.
  21989. Not really feasible with ~2500 inexperienced users.
  21990. We had channelized T1s with line-side termination.  Found out that exceeds
  21991. the v.90 requirement for digital-to-analog conversions.  If they were trunk
  21992. side terminations we might have been OK.  Anyway, we got a good deal
  21993. from Bell for the line screwup, and we put in PRIs.  Things have been great
  21994. since.
  21995. Check with your carrier about your exact line build,  and I recommend
  21996. PRIs if available, fast & and digital helps a lot with 56k.
  21997.  
  21998. Scott Boggs
  21999. IS Manager
  22000. United Bank
  22001. Zebulon Georgia
  22002.  
  22003. > -----Original Message-----
  22004. > From:    R. Ferguson [SMTP:cygnus@vsta.com]
  22005. > Sent:    Tuesday, March 16, 1999 1:49 PM
  22006. > To:    usr-tc@lists.xmission.com
  22007. > Subject:    (usr-tc) disconnect problems
  22008. > 
  22009. > Hello Everyone,
  22010. > I'm new to this list but from the few days i've been on it looks like
  22011. > someone here might have the answer i need.
  22012. > I have 3 TC chassis with the configuration shown  below. I have been
  22013. > having
  22014. > a problem with customers calling up and getting dropped immediately. Some
  22015. > users finish the handshake and get disconnected during authentication
  22016. > others never get past the handshake stage  many users report messages
  22017. > saying "error 631" or "a connection could not be established please check
  22018. > you network configuration and try again" (something like that). Anyways
  22019. > the people complaining have been long standing customers who have never
  22020. > reported trouble then suddenly about a month ago everyone started having
  22021. > this trouble(about the time i put in a usr update). The only real pattern
  22022. > i
  22023. > see is that it mostly affects Kflex users and V.90 users and users with
  22024. > pc's(Compaq and Gateway) less that 3 months old. USR support told me to
  22025. > update the code to the version you see listed below and that all the V.90
  22026. > problems would be resolved. I saw no difference with the new code except
  22027. > that WebTv users work great now.  I have managed to get the real angry
  22028. > customers back online by turning off 56k/v.90 in thier modems with an init
  22029. > string but it's not a real solution because the problem is still there.
  22030. > Is anyone else seeing this problem? Is there a known bug with V.90/56k?
  22031. > Can
  22032. > anyone give me some advice on resolving this problem.....The USRTechs i
  22033. > have spoken with say that my customers have to go get thier modems updated
  22034. > to the latest code. Some of my customers have tried doing this and they
  22035. > are
  22036. > told by their vendors that there code is solid and their ISP (me) is the
  22037. > one with the problem....
  22038. > any help or adice will be greatly appreciated
  22039. >                          Rudy Ferguson
  22040. >                          cygnus@vsta.com
  22041. > 
  22042. >                             
  22043. >                                 
  22044. > 1    3COM DUAL T1 NAC    BBB6NZTY    11C    3.0.0    512    512
  22045. > 0000000000000101    3.5.0
  22046. > 2    3COM Quad V.34 Digital Modem NAC    BCI6XI90    19U000
  22047. > 2.0.0    0    0
  22048. > 0000000110001000    5.10.9
  22049. > 3    3COM Quad V.34 Digital Modem NAC    BCF6WXM6    19U000
  22050. > 2.0.0    0    0
  22051. > 0000000110001000    5.10.9
  22052. > 4    3COM Quad V.34 Digital Modem NAC    BCL6Y9MA    19U000
  22053. > 2.0.0    0    0
  22054. > 0000000110001000    5.10.9
  22055. > 5    3COM Quad V.34 Digital Modem NAC    BCG6X1OR    19U000
  22056. > 2.0.0    0    0
  22057. > 0000000110001000    5.10.9
  22058. > 6    3COM Quad V.34 Digital Modem NAC    BCE6WRHG    19U000
  22059. > 2.0.0    0    0
  22060. > 0000000110001000    5.10.9
  22061. > 7    3COM Quad V.34 Digital Modem NAC    BCI6XIG5    19U000
  22062. > 2.0.0    0    0
  22063. > 0000000110001000    5.10.9
  22064. > 8    3COM Quad V.34 Digital Modem NAC    BCI6XI8M    19U000
  22065. > 2.0.0    0    0
  22066. > 0000000110001000    5.10.9
  22067. > 9    3COM Quad V.34 Digital Modem NAC    BCG6X1UB    19U000
  22068. > 2.0.0    0    0
  22069. > 0000000110001000    5.10.9
  22070. > 10    3COM Quad V.34 Digital Modem NAC    BCL6Y9NM    19U000
  22071. > 2.0.0    0    0
  22072. > 0000000110001000    5.10.9
  22073. > 11    3COM Quad V.34 Digital Modem NAC    BCG6X1OL    19U000
  22074. > 2.0.0    0    0
  22075. > 0000000110001000    5.10.9
  22076. > 12    3COM Quad V.34 Digital Modem NAC    BCG6X1KL    19U000
  22077. > 2.0.0    0    0
  22078. > 0000000110001000    5.10.9
  22079. > 13    3COM Quad V.34 Digital Modem NAC    BCH6XGZI    19U000
  22080. > 2.0.0    0    0
  22081. > 0000000110001000    5.10.9
  22082. > 14    3COM High-Density 24 Channel NAC    BC77B0TF    1OQ
  22083. > 0.49.0    8192    2048
  22084. > 0000000000000000    1.2.59
  22085. > 15    3COM High-Density 24 Channel NAC    B1C8DPRE    1OQ
  22086. > 0.49.0    8192    2048
  22087. > 0000000000000000    1.2.59
  22088. > 16    3COM HiPer ARC NAC    B648VNPZ    20C    19.0.0    65536    8192
  22089. > 0000000000000000    4.1.59
  22090. > 17    3COM Network Management Card with clock    BCI6XJ5M    11I00000
  22091. > 3.0    20480    8192
  22092. > 0000000000000000    5.5.5
  22093. > 1    3COM Bellcore Approved Long Haul Dual T1 NIC
  22094. > 512    512    0000000000000101    
  22095. > 14    3COM T1/E1 HDM NIC                8192    2048
  22096. > 0000000000000000    
  22097. > 15    3COM T1/E1 HDM NIC                8192    2048
  22098. > 0000000000000000    
  22099. > 16    3COM Dual 10/100 Ethernet NIC - PCI based
  22100. > 65536    8192    0000000000000000    
  22101. > 17    3COM Ethernet NIC    ????????        ??    0    0
  22102. > 0000000000000000    
  22103. > 
  22104. > 
  22105. > 
  22106. > -
  22107. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22108. >  with "unsubscribe usr-tc" in the body of the message.
  22109. >  For information on digests or retrieving files and old messages send
  22110. >  "help" to the same address.  Do not use quotes in your message.
  22111.  
  22112. -
  22113.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22114.  with "unsubscribe usr-tc" in the body of the message.
  22115.  For information on digests or retrieving files and old messages send
  22116.  "help" to the same address.  Do not use quotes in your message.
  22117.  
  22118.  
  22119. -------------------------------------------------------------------------------
  22120.  
  22121. From: "Richard Gamberg" <bbhi@shaka.com>
  22122. Subject: RE: (usr-tc) disconnect problems
  22123. Date: 17 Mar 1999 08:12:31 -1000
  22124.  
  22125. -> I had the exact same situation, except my modem cards were HiperDSPs.
  22126. -> 3com support told me the same thing about users upgrading their winmodem
  22127. -> software.
  22128.  
  22129. Well, the Rockwell/Conexant HCF modems with older version driver are buggy
  22130. and need update badly.... these modems are now being used by Compaq, IBM,
  22131. HP, Sony, and many more vendors - in place of the much better (with updated
  22132. firmware) Lucent LT....
  22133. See my HCF page at http://808hi.com/56k/rockhcf.htm
  22134. and Lucent LT at   http://808hi.com/56k/x2-lucent.htm
  22135.  
  22136. There are getting to be so many versions of client and server firmware,
  22137. combined with varying telco digital impairments, that in some ways 56k
  22138. connectivity is getting worse, not better. Some 3Com client versions are
  22139. having trouble with some 3Com server versions! And 3Com doesn't make it easy
  22140. if the customer 'upgrades' their firmware and 'downgrades' their connection.
  22141. V.90 Interoperability status  -
  22142. http://808hi.com/56k/x2-interop.htm
  22143.  
  22144.  
  22145. New Pages & Recent updates at the 56k=v.Unreliable site
  22146. http://808hi.com/56k/  [mirrored at http://808news.com/56k]
  22147.  
  22148.  
  22149. Rockwell/Conexant HCF modems info-  http://808hi.com/56k/rockhcf.htm
  22150.  
  22151. The Main Troubleshooting Page has been updated with a section on
  22152. frequent disconnects, and the list of ISP access numbers has been
  22153. updated to reflect the type of server modem used by the ISP.
  22154. http://808hi.com/56k/r-rnut-x2-3.htm - Main Troubleshooting Page
  22155.  
  22156. What's a 56k-compatible line? -     http://808hi.com/56k/56kline.htm
  22157. Modems & Call Waiting -             http://808hi.com/56k/callwait.htm
  22158. RBS & 56k update -                  http://808hi.com/56k/rbs2.htm
  22159. Inexpensive, Decent 56k modems -    http://808hi.com/56k/buy56k.htm
  22160. Useful Links -                      http://808hi.com/56k/links.htm
  22161. How to Flashback 3Com/USR modems -  http://808hi.com/56k/flashback.htm
  22162.  
  22163. 56k TROUBLESHOOTING -
  22164. Check Your Throughput -             http://808hi.com/56k/x2-thru.htm
  22165. Limiting Your Connect Speed -
  22166. http://808hi.com/56k/x2-linklimit.htm
  22167. Who Manufactured Your Modem? -      http://808hi.com/56k/whomadeit.htm
  22168. 3Com Diagnostic Screens -           http://808hi.com/56k/diag3com.htm
  22169. If you get 115.2k connects -        http://808hi.com/56k/x2-inf1.htm
  22170.  
  22171. LUCENT LT Winmodem / latest driver/firmware
  22172. http://808hi.com/56k/x2-lucent.htm
  22173.  
  22174. NEWS & UPDATES -       http://808hi.com/56k/news.htm
  22175. LATEST UPDATES -       http://808hi.com/56k/latest.htm
  22176.  
  22177. Why 56k=v.Unreliable - http://808hi.com/56k/why56kis.htm
  22178.  
  22179. From the guestbook -   http://808hi.com/56k/guestbook.htm
  22180. "AWESOME site...."
  22181. "Your page on limiting connection speed put me on the right track..."
  22182. "When you are totally frustrated this is a great place to go see that
  22183. you aren't alone!!!"
  22184. "This site was very helpful to me, in finding out about my Rockwell
  22185. HCF 56k PCI modem. I located my modem, and the newest upgrade driver,
  22186. downloaded and installed it. It is now working great. Thanks."
  22187. "Excellent page. I am the administrator for a regional cable/dialup
  22188. ISP and this is one of the most informative pages on 56k I have ever
  22189. read. I have gleaned much more useful information from your pages in
  22190. 30 minutes than I have ever received from 3Com (and that's having
  22191. direct access to one of their SE's). Thanks!"
  22192.  
  22193. Note - my site is copyrighted; many ISP help pages link to one or more of my
  22194. pages - no permission is needed to do this; however, if you want to COPY
  22195. info & place on your site, you need to get my permission. Thanks.
  22196. Aloha,
  22197. Richard
  22198.  
  22199.  
  22200. -
  22201.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22202.  with "unsubscribe usr-tc" in the body of the message.
  22203.  For information on digests or retrieving files and old messages send
  22204.  "help" to the same address.  Do not use quotes in your message.
  22205.  
  22206.  
  22207. -------------------------------------------------------------------------------
  22208.  
  22209. From: "Tony Loosle" <tony@tcsourceone.com>
  22210. Subject: (usr-tc) Rack mount brackets for netserver 16
  22211. Date: 17 Mar 1999 12:20:31 -0700
  22212.  
  22213. I need a pair of brackets to rackmount a netserver 16.
  22214.  
  22215. Thanks....
  22216.  
  22217. tony
  22218.  
  22219.  
  22220.  
  22221. -
  22222.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22223.  with "unsubscribe usr-tc" in the body of the message.
  22224.  For information on digests or retrieving files and old messages send
  22225.  "help" to the same address.  Do not use quotes in your message.
  22226.  
  22227.  
  22228. -------------------------------------------------------------------------------
  22229.  
  22230. From: "Network Administrator" <netadmin@seidata.com>
  22231. Subject: (usr-tc) DSP
  22232. Date: 17 Mar 1999 14:55:57 -0500
  22233.  
  22234.  
  22235. I am working to implementing a dedicated modem from a DSP card. The modem
  22236. would be free from the hunt group on the T1. I was curious if someone had a
  22237. clue on how to configure the DSP or ARC card for this feature. I have read
  22238. through several pages of manuals, but this feature is not mentioned. At
  22239. least I have not come across it. I am running the following software
  22240. versions:
  22241. NMC  5.5.5
  22242. ARC  4.1.59
  22243. DSP  1.2.59
  22244.  
  22245.  
  22246. Scott Childers
  22247. Network Systems Manager
  22248. SEI Data Network Services
  22249. http://www.seidata.com
  22250. VenusNet
  22251. http://www.venus.net
  22252.  
  22253.  
  22254. -
  22255.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22256.  with "unsubscribe usr-tc" in the body of the message.
  22257.  For information on digests or retrieving files and old messages send
  22258.  "help" to the same address.  Do not use quotes in your message.
  22259.  
  22260.  
  22261. -------------------------------------------------------------------------------
  22262.  
  22263. From: matthews <matthews@brunnet.net>
  22264. Subject: RE: (usr-tc) DSP
  22265. Date: 17 Mar 1999 16:12:35 -0400
  22266.  
  22267.  
  22268. I currently have a call in to the telco to see if they assign a POTS number 
  22269. to a single channel and make it separate from the POTS number assigned to 
  22270. the rest of the channels.  They're quite sure they can but they have yet to 
  22271. get back to me.  I think that would effectively accomplish what you're 
  22272. trying to do without having to bugger with the DSP configuration.
  22273.  
  22274.  
  22275. On Wednesday, March 17, 1999 3:56 PM, Network Administrator 
  22276. [SMTP:netadmin@seidata.com] wrote:
  22277. >
  22278. > I am working to implementing a dedicated modem from a DSP card. The modem
  22279. > would be free from the hunt group on the T1. I was curious if someone had 
  22280. a
  22281. > clue on how to configure the DSP or ARC card for this feature. I have 
  22282. read
  22283. > through several pages of manuals, but this feature is not mentioned. At
  22284. > least I have not come across it. I am running the following software
  22285. > versions:
  22286. > NMC  5.5.5
  22287. > ARC  4.1.59
  22288. > DSP  1.2.59
  22289. >
  22290. >
  22291. > Scott Childers
  22292. > Network Systems Manager
  22293. > SEI Data Network Services
  22294. > http://www.seidata.com
  22295. > VenusNet
  22296. > http://www.venus.net
  22297. >
  22298. >
  22299. > -
  22300. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22301. >  with "unsubscribe usr-tc" in the body of the message.
  22302. >  For information on digests or retrieving files and old messages send
  22303. >  "help" to the same address.  Do not use quotes in your message.
  22304.  
  22305.  
  22306.  
  22307.  
  22308. -
  22309.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22310.  with "unsubscribe usr-tc" in the body of the message.
  22311.  For information on digests or retrieving files and old messages send
  22312.  "help" to the same address.  Do not use quotes in your message.
  22313.  
  22314.  
  22315. -------------------------------------------------------------------------------
  22316.  
  22317. From: Robert von Bismarck <rvb@petrel.ch>
  22318. Subject: RE: (usr-tc) HyperARC needs a regular reboot?
  22319. Date: 18 Mar 1999 11:54:20 +0100
  22320.  
  22321. Sound like the dreaded 4.1.72-7 memory leak on the ARC. This is probably
  22322. coming from MPIP. There's only one solution : upgrade your code
  22323.  
  22324. Regards,
  22325.  
  22326. Robert
  22327.  
  22328.  
  22329. > -----Original Message-----
  22330. > From:    Brett Murphy [SMTP:sysadmin@alphalink.com.au]
  22331. > Sent:    mardi, 16. mars 1999 00:57
  22332. > To:    usr-tc@lists.xmission.com
  22333. > Subject:    (usr-tc) HyperARC needs a regular reboot?
  22334. > 
  22335. > Hi All,
  22336. > Far too regularly I am finding that when I telnet to my HyperARC
  22337. > it drops the connection immediately. The problem remains until I
  22338. > powercycle the chassis. Has anyone seen this before?
  22339. > 
  22340. > --
  22341. > 
  22342. > All the best,
  22343. > Brett Murphy
  22344. > System Administrator, Alphalink (Australia) PTY LTD
  22345. > ph: +61 3 9486-8844 fax: +61 3 9486-6822
  22346. > email: sysadmin@alphalink.com.au
  22347. > 
  22348. > The contents of this message may not be quoted,
  22349. > copied, reproduced or published in part or in whole,
  22350. > without the written authorization of Brett Murphy,
  22351. > Director, Alphalink (Australia) Pty Ltd.
  22352. > 
  22353. > 
  22354. > 
  22355. > -
  22356. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22357. >  with "unsubscribe usr-tc" in the body of the message.
  22358. >  For information on digests or retrieving files and old messages send
  22359. >  "help" to the same address.  Do not use quotes in your message.
  22360.  
  22361. -
  22362.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22363.  with "unsubscribe usr-tc" in the body of the message.
  22364.  For information on digests or retrieving files and old messages send
  22365.  "help" to the same address.  Do not use quotes in your message.
  22366.  
  22367.  
  22368. -------------------------------------------------------------------------------
  22369.  
  22370. From: Rick <rickyz@mindspring.com>
  22371. Subject: RE: (usr-tc) 3Com Security and Accounting upgrade from 6.0.8 to 6.0.90
  22372. Date: 18 Mar 1999 07:52:03 -0500
  22373.  
  22374. Thanks Blake...I'll check that.
  22375.  
  22376. RickyZ
  22377.  
  22378. -----Original Message-----
  22379. Sent:    Tuesday, March 16, 1999 7:16 PM
  22380.  
  22381. I had that error once.  Are you importing accounting information?
  22382. If so, I would uncheck that box in the appropriate window.  One 
  22383. other problem I ran in to with 6.0.9 is our two session users
  22384. would not get logged in.  Strange thing is I didn't even see them
  22385. hitting the hub via "mon ppp" or "mon radius".  After I changed the
  22386. "maximum number of concurrent sessions" from 2 to 0 they got right
  22387. in. (a two channel ISDN user).
  22388.  
  22389. blake
  22390.  
  22391. > -----Original Message-----
  22392. > From: Rick [mailto:rickyz@mindspring.com]
  22393. > Sent: Tuesday, March 16, 1999 5:54 PM
  22394. > To: usr-tc@lists.xmission.com
  22395. > Subject: (usr-tc) 3Com Security and Accounting upgrade from 6.0.8 to
  22396. > 6.0.90
  22397. > 
  22398. > 
  22399. > I did a test install of 6.0.9.  It installs to a different 
  22400. > directory from 
  22401. > the previous 6.0.8 -- c:\3comsuite vs. c:\usrsuite.  If 
  22402. > c:\usrsuite exists, 
  22403. > the installation routine apparently renames (or copies) the existing 
  22404. > usradius.mdb to old.mdb in preparation for importing the records.
  22405. > 
  22406. > There is a database import utility under Server Setup / 
  22407. > Advanced Options / 
  22408. > Database Maintenance.  There are options for importing from 
  22409. > various other 
  22410. > versions, including 6.0.8.
  22411. > 
  22412. > So far, so good.
  22413. > 
  22414. > However, when I try to import the database, I get the following error 
  22415. > message:
  22416. > 
  22417. > 3COM Security and Accounting Database Manager can't append 
  22418. > all the records 
  22419. > in the append query.
  22420. >     3COM Security and Accounting Database Manager set 0 
  22421. > field(s) to Null 
  22422. > due to a type
  22423. >     conversion failure, and it didn't add 3476 record(s) to 
  22424. > the table due 
  22425. > to key violations, 0
  22426. >     record(s) due to lock violations, and 0 record(s) due to 
  22427. > validation 
  22428. > rule violations.
  22429. >     Do you want to run the action query anyway?
  22430. >     To ignore the error(s) and run the query, click Yes.
  22431. >     For an explanation of the causes of the violations, click Help.
  22432. > 
  22433. > If I tell it to continue on with the import, I get several more error 
  22434. > messages, then when I check the users database, there are 
  22435. > only about 200 
  22436. > records.
  22437. > 
  22438. > What do I need to do to get this straightened out?
  22439. > 
  22440. > ricky@mindspring.com
  22441. > 
  22442. > 
  22443. > -
  22444. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22445. >  with "unsubscribe usr-tc" in the body of the message.
  22446. >  For information on digests or retrieving files and old messages send
  22447. >  "help" to the same address.  Do not use quotes in your message.
  22448. > 
  22449.  
  22450. -
  22451.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22452.  with "unsubscribe usr-tc" in the body of the message.
  22453.  For information on digests or retrieving files and old messages send
  22454.  "help" to the same address.  Do not use quotes in your message.
  22455.  
  22456. begin 600 WINMAIL.DAT
  22457. M>)\^(@L,`0:0" `$```````!``$``0>0!@`(````Y 0```````#H``$(@ <`
  22458. M& ```$E032Y-:6-R;W-O9G0@36%I;"Y.;W1E`#$(`0V ! `"`````@`"``$$
  22459. MD 8`T $```$````0`````P``, (````+``\.``````(!_P\!````40``````
  22460. M``"!*Q^DOJ,0&9UN`-T!#U0"`````'5S<BUT8T!L:7-T<RYX;6ES<VEO;BYC
  22461. M;VT`4TU44 !U<W(M=&- ;&ES=',N>&UI<W-I;VXN8V]M`````!X``C !````
  22462. M!0```%--5% `````'@`#, $````:````=7-R+71C0&QI<W1S+GAM:7-S:6]N
  22463. M+F-O;0````,`%0P!`````P#^#P8````>``$P`0```!P````G=7-R+71C0&QI
  22464. M<W1S+GAM:7-S:6]N+F-O;2<``@$+, $````?````4TU44#I54U(M5$- 3$E3
  22465. M5%,N6$U)4U-)3TXN0T]-```#```Y``````L`0#H!````'@#V7P$````:````
  22466. M=7-R+71C0&QI<W1S+GAM:7-S:6]N+F-O;0````(!]U\!````40````````"!
  22467. M*Q^DOJ,0&9UN`-T!#U0"`````'5S<BUT8T!L:7-T<RYX;6ES<VEO;BYC;VT`
  22468. M4TU44 !U<W(M=&- ;&ES=',N>&UI<W-I;VXN8V]M``````,`_5\!`````P#_
  22469. M7P`````"`?8/`0````0````````"^6@!!( !`$<```!213H@*'5S<BUT8RD@
  22470. M,T-O;2!396-U<FET>2!A;F0@06-C;W5N=&EN9R!U<&=R861E(&9R;VT@-BXP
  22471. M+C@@=&\@-BXP+CDP`$P6`06 `P`.````SP<#`!(`!P`T``,`! `M`0$@@ ,`
  22472. M#@```,\'`P`2``<`,P`F``0`3P$!"8 !`"$```!!1#<U138W-S V1$1$,C$Q
  22473. M.#0Q130T-#4U,S4T,# P, #D!@$#D 8`Z H``"$````+``(``0````L`(P``
  22474. M`````P`F```````+`"D```````,`+@```````P`V``````! `#D`(!?"'CYQ
  22475. MO@$>`' ``0```$<```!213H@*'5S<BUT8RD@,T-O;2!396-U<FET>2!A;F0@
  22476. M06-C;W5N=&EN9R!U<&=R861E(&9R;VT@-BXP+C@@=&\@-BXP+CDP```"`7$`
  22477. M`0```!8````!OG$^'L)WYG6NW081TH0>1$535 `````>`!X,`0````4```!3
  22478. M3510`````!X`'PP!````%@```')I8VMY>D!M:6YD<W!R:6YG+F-O;0````,`
  22479. M!A!IV@7H`P`'$)X(```>``@0`0```&4```!42$%.2U-"3$%+14E,3$-(14-+
  22480. M5$A!5%))0TM96BTM+2TM3U))1TE.04Q-15-304=%+2TM+2U&4D]-.D),04M%
  22481. M1DE42$5.4TU44#I&251(14Y 3D545T]22U-03%530T]-4T5.``````(!"1 !
  22482. M````F@<``)8'``!'#@``3%I&=5RPL*!W``H!`P'W( *D`^,"`&.": K <V5T
  22483. M," '$X<"@P!0#O9P<G$R#_8F?0J ",@@.PEO,C5F-0* "H%U8P!0"P-C`P!!
  22484. M"V!N9S$P,S-)"Z8@5 ^ ;FL$($(1"V!K92X7($DG;$<#( ]P!9!K('0/@'1.
  22485. M+@JB"H0*@%)I%]!YAEH86@KT;&DS-@% IQ40`4 10&]T!9!T$(10,38@+1PR
  22486. M3P409P\+@ = != 'D'-A9V4_'#,85AM$&Q$+$QM&:2T8,30T`4 :D#$X,$<!
  22487. M0 S0']-B($8#83K=#(-B#^ 6TR$0:1@`"?" (%M33510.A^@92)R0 ? ='<%
  22488. ML!:@4,D*0',N!:!M71A5(0`7!F ","%G5 I0<V1AW'DL!= *P ]P(!P`)G!$
  22489. M,3DG0" W.AP!4%)-)*=4;R%G)R0P<I M=&- &I!S="1 M'AM! %I`B D4B<D
  22490. MJ!AU8FH;<2%G4D4Z1" H*40I(#,(4&U%!E%C"'%T>2 `<&0U#_!C!:!U`C +
  22491. M@&<@5'5P"<!A`0`@`U(@H#8N,"XX%_!O+]-^.1ZS'A\;-AJ4"[888TGN( ^ 
  22492. M+D 8`B $D -@!<"U`B!C%Q @#_$B,'D(8/H@!W!P"1$NT@#0+H<+@%T"$'(`
  22493. MP"[ `B _,W5F."!S;R9P,] CP'5LURY +J 7J" &X'@W$1?Q^2(P87 ;,1% 
  22494. M!S ;8#C D0N 9&]W-2%/;B(POQA4&U 7L 7 &S$"8&4M</\ST"] `Z Z0C!0
  22495. M`_ 8`#!D_S7 !" (81?P(\ X8!TA*F%?+P`/L ^@&%0XU&X;4"#W'6 %0 D`
  22496. M9QU@+D +@#4A_%-T/:$=8!?Q-N,$(#/0H&1I9&XG-&%V(I'_#[!"TCU0&%1#
  22497. M``) +M(Z<I)H*X @=@<P("($8/,#H#K <"(TT 7 1H,O0?II)# B-2(!@#S1
  22498. M,] /<9M"L30291A41H!A> =PJG4M<&Y*,&(\T6\X4/\%H#3P"' )< (P/Y9'
  22499. M\"^$WQ%P,$$/X")Q+@!G04$<D>YH&Y 88T(B*$9@/V)(PD,\$ ,@25-$3D 3
  22500. M*>\82P)@%O$86CX<+QT^4@"_(2,'\!DA(K 5`SCP( # FP,0,$ Z!1 9,7I 
  22501. M*B#]+C!S.P$5<"12&N,X\ _@'R254@`E,R7_)P8U.C7^-"?'4@`H@4 1*6\J
  22502. M=%?G_RN%+*\MOR[/+]=1IC!Z4@#_8JY#@U]P%_ 'D 5 "X IT-\'0 ,@2M$P
  22503. M<S4A2637!"#_,$%&8$.@`2 $D$MR4:9#H/\)<!N !;!?8"^34:8Z<A% ?T00
  22504. M*F D,"_54B 7D"%@7+(S)&%S=2)@(C!V)$#_:Q-;<6NC9?(X4%&F;$HT</]*
  22505. M`"G163!I2F3U-X,]D A@;V A.I,*P"5!;%]@2V%AK0>"* 6Q!:!P")!S7H _
  22506. M.G)NLV R4:9;<4>S+FWN9"$`,$$&\&1U`SI!:@'_"K%P9#=!-<DZ<FAQ!;!6
  22507. MD/\816,(%F!G<3[B9Q$8( &@_F$/L#7%8&!@(!J07U%@`"\$@0921"!\`G1@
  22508. M<" O<6,7061V`' U`%^@3_<%,$OR?.E$>E8FD N &V#_4L T]'F4<7$TT'XU
  22509. M=OQH^_]]L 40:E(\I(,'0$%+\EDP?0N 8PI 0Z!@02_C>(]3_3!09@K 63 X
  22510. M<$U1!'"&?^Y(.[!$$8?1=R*",]!"@/]?8#!!>M4Z<GI&.))!<CIR_P(0%W [
  22511. ML& R-(11I@>!'4+G(6!BO5Z@3TU>[U_V?TG_4L =8'*1`'!#X3JQ"?!?H+]1
  22512. MIF4R=]EC%SI(DU)Q"E#_:,"(=Y="C^^0_Y(*#[%,X6=1IA^@3U!D*',",%!.
  22513. M_SCP`R%GY@I09M280)- EMK_2P&$Y8>A`Q (<(P17X(B8,=#EF"P7Z S-#<<
  22514. M$'@4_YNE:4H!D3U G--I1S!0%P#_F%!J,7!4;P%BEY="H2B<Y?\)`!?1I$I?
  22515. M@@_@I=^#"!J0]WI!/^)1IG(X\&OAI%>6R_9$,% UDG<`<(M!,%"K$%\Z51N 
  22516. M/^*6<U]Q>:U >>\WU9<T*( UP&=!,#5A<S/_-)*;HE^"K<:6<UDPA:!4LO99
  22517. M!Y"6RT8%L0.1;K +4?]2P'!S2M$Z<I+ 0"$_`;6$ZZ1*LN1(3U!PB'\X08IA
  22518. M_T]0`R"?\3!!2P%@(9SQ/_'_/D-OLS7CC"8/L'Q14M$$8/\U88V/'4)O`2)S
  22519. MBA47IB(P_T CBYD\LH#T4:8"(''!`:"_<-%,D"!@JHAX+U'$5S1"_SN@.*$\
  22520. M$$D2,%#%<3!!C&3_/O$IT&"@3;()\$'Q<-&O=_^JEQDB5EYBOU'%EM>P06 `
  22521. M_6N@8@3R2I P,EMTA^&34F^T@E6",#))T6K#T0-P;]I *AHBEM<^0R+,VEMT
  22522. M]T<`.D4&X&284+5UCF66R/^T0C<INK)#H+YA*>!'$@EP_T* ")!&0(*"`Q '
  22523. MD5^"=8'WO@?.,Y;7(A>PN !'`#!!_SIR'4 '@*"""7 $$#4AK-'_03) (99A
  22524. M&U$$(#I!-9$%P/_4/AA:'<7,G\VOSK_/S]]5_]%OTG_3C]26U3_63]=?V&]_
  22525. MV77:#]L?W"_=/PJ $@$``?%@```#`! 0``````,`$1 !`````P" $/____] 
  22526. M``<PH-<P$#YQO@% ``@PH-<P$#YQO@$+`"2 "" &``````# ````````1@``
  22527. M```#A0````````,`)8 (( 8``````, ```````!&`````!"%`````````P`F
  22528. M@ @@!@``````P ```````$8`````4H4``+<-```>`"> "" &``````# ````
  22529. M````1@````!4A0```0````0````X+C ``P`H@ @@!@``````P ```````$8`
  22530. M`````84````````+`"F "" &``````# ````````1@`````.A0````````,`
  22531. M*H (( 8``````, ```````!&`````!&%`````````P`K@ @@!@``````P ``
  22532. M`````$8`````&(4````````>`"R "" &``````# ````````1@`````VA0``
  22533. M`0````$`````````'@`M@ @@!@``````P ```````$8`````-X4```$````!
  22534. M`````````!X`+H (( 8``````, ```````!&`````#B%```!`````0``````
  22535. @```>`#T``0````4```!213H@``````,`#33]-P``-4.%
  22536. `
  22537. end
  22538.  
  22539.  
  22540. -
  22541.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22542.  with "unsubscribe usr-tc" in the body of the message.
  22543.  For information on digests or retrieving files and old messages send
  22544.  "help" to the same address.  Do not use quotes in your message.
  22545.  
  22546.  
  22547. -------------------------------------------------------------------------------
  22548.  
  22549. From: "Mark Starr" <squid@greenapple.com>
  22550. Subject: (usr-tc) Port Limit with bsdi radius
  22551. Date: 18 Mar 1999 12:26:55 -0500
  22552.  
  22553. Hello,
  22554.  I am using bsdi radius that comes with 3.1(very close to merit radius). I
  22555. am trying to implement the port-limit setting, but it does not seem to work.
  22556. I have three machines doing auth and one doing all the logging. I set
  22557. Port-Limit = 1 and even tried Simultaneous-Use = 1, but am still able to
  22558. login mult. times. Any ideas or suggestions?
  22559.  
  22560. Thanks, Mark
  22561.  
  22562.  
  22563. -
  22564.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22565.  with "unsubscribe usr-tc" in the body of the message.
  22566.  For information on digests or retrieving files and old messages send
  22567.  "help" to the same address.  Do not use quotes in your message.
  22568.  
  22569.  
  22570. -------------------------------------------------------------------------------
  22571.  
  22572. From: Netlink Hardware admin <hw@netlinkcom.com>
  22573. Subject: (usr-tc) Netserver 8/16 I assigning DNS to users.
  22574. Date: 18 Mar 1999 12:37:34 -0600 (EST)
  22575.  
  22576.  
  22577. Hello all,
  22578.  
  22579. I am using Netserver 8/16 I for X2, V.90, ISDN, and analog dial in.
  22580. I also use Livingson PM2E for strictly analog dial in.
  22581.  
  22582. I have the DNS servers set in the Netserver config. (and PM2)
  22583.  
  22584. Currently we have the users specify the Name Server addresses in their
  22585. setup.
  22586.  
  22587. While testing I set my config (WIN95/98) to use server assigned name
  22588. server addresses.
  22589.  
  22590. This works fine on the PM2, but the Netserver doesn't seem to report the
  22591. nameservers to the clients when they dial in.
  22592.  
  22593. Is this a known problem/feature or should I be looking for some other
  22594. problem?
  22595.  
  22596. How can I set up the Netservers to assign the DNS to the dial-in clients?
  22597.  
  22598. Thanks,
  22599.  
  22600. Curt
  22601.  
  22602.  
  22603.  
  22604.  
  22605. -
  22606.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22607.  with "unsubscribe usr-tc" in the body of the message.
  22608.  For information on digests or retrieving files and old messages send
  22609.  "help" to the same address.  Do not use quotes in your message.
  22610.  
  22611.  
  22612. -------------------------------------------------------------------------------
  22613.  
  22614. From: "Robert J. Adams" <radams@siscom.net>
  22615. Subject: (usr-tc) DSP1.2.43 
  22616. Date: 18 Mar 1999 15:03:36 -0500
  22617.  
  22618. Hello,
  22619.  
  22620. Anyone tried the new 1.2.43 code yet?
  22621.  
  22622. -j
  22623.  
  22624. ---
  22625. Robert J. Adams radams@siscom.net http://www.siscom.net
  22626. Looking to outsource news? http://www.newshosting.com
  22627. SISCOM Network Administration - President, SISCOM Inc.
  22628. Phone: 937-222-8150 FAX: 937-222-8153 
  22629.  
  22630.  
  22631. -
  22632.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22633.  with "unsubscribe usr-tc" in the body of the message.
  22634.  For information on digests or retrieving files and old messages send
  22635.  "help" to the same address.  Do not use quotes in your message.
  22636.  
  22637.  
  22638. -------------------------------------------------------------------------------
  22639.  
  22640. From: "Stainforth, Matthew (Sys Mgr - BrunNet)"
  22641. Subject: (usr-tc) second span takes down calls on first span
  22642. Date: 18 Mar 1999 15:57:45 -0400
  22643.  
  22644. I'm currently having a problem I've never had before.  For quite a while we
  22645. have had one active span on a dual PRI card.  This week we ordered the
  22646. second span and attempted to put it into service.  However, the instant I
  22647. plugged the span into the second port of the dual PRI card, it caused all
  22648. the calls on the first span to drop.  After a few seconds, calls start
  22649. coming in on the first span again but are dropped after a few seconds.  All
  22650. the calls seem to drop simultaneously.  I talked to the guys at the switch
  22651. about it and they said it looked like it was related to signalling which
  22652. would make sense since I'm using NFAS to share the D channel between the two
  22653. spans.  The configuration on the card looks okay and I have compared it with
  22654. configurations on other cards I have had in service for over a year.  All
  22655. code is up to date.  The other strange thing is the carrier and channels
  22656. seem to come up on the second span but the DS1 terminator box that the telco
  22657. installed indicates that AMI framing is being used.  But I thought the
  22658. carrier wouldn't even come up if the framing was incorrect (I have it set on
  22659. the PRI Card as b8zs, wihch is what it should be).
  22660.  
  22661. Error counters for the second span are through the roof according to the CLI
  22662. on the PRI card.
  22663.  
  22664. Has anybody seen this before?  At this point I'm not sure if it's the line
  22665. has been provisioned wrong by the telco or if my PRI card is bad.  In my
  22666. experience, I thought the carrier on the ds1 wouldn't even come up if the
  22667. line was provisioned wrong.  Any ideas?
  22668.  
  22669. -
  22670.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22671.  with "unsubscribe usr-tc" in the body of the message.
  22672.  For information on digests or retrieving files and old messages send
  22673.  "help" to the same address.  Do not use quotes in your message.
  22674.  
  22675.  
  22676. -------------------------------------------------------------------------------
  22677.  
  22678. From: Dan Hollis <goemon@sasami.anime.net>
  22679. Subject: (usr-tc) card management through hiperarc cli?
  22680. Date: 18 Mar 1999 12:19:58 -0800 (PST)
  22681.  
  22682. Are there any plans in the future to allow management of HiperDSP cards
  22683. through the HiperARC cli? Doing things through the windoze nmc manager is
  22684. a real pain, and hooking up the serial ports at remote unmanned pops is
  22685. not always possible.
  22686.  
  22687. It would be nice to be able to e.g. in-service/out-of-service channels and
  22688. spans from the CLI. This is one thing about Ciscos that is *very* nice.
  22689.  
  22690. -Dan
  22691.  
  22692.  
  22693. -
  22694.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22695.  with "unsubscribe usr-tc" in the body of the message.
  22696.  For information on digests or retrieving files and old messages send
  22697.  "help" to the same address.  Do not use quotes in your message.
  22698.  
  22699.  
  22700. -------------------------------------------------------------------------------
  22701.  
  22702. From: Blake Fithen <fithen@NetworksPlus.com>
  22703. Subject: RE: (usr-tc) DSP1.2.43 
  22704. Date: 18 Mar 1999 14:21:25 -0600
  22705.  
  22706. yep, no problems so far. 
  22707.  
  22708. blake
  22709.  
  22710. > -----Original Message-----
  22711. > From: Robert J. Adams [mailto:radams@siscom.net]
  22712. > Sent: Thursday, March 18, 1999 2:04 PM
  22713. > To: usr-tc@lists.xmission.com
  22714. > Subject: (usr-tc) DSP1.2.43 
  22715. > 
  22716. > 
  22717. > Hello,
  22718. > 
  22719. > Anyone tried the new 1.2.43 code yet?
  22720. > 
  22721. > -j
  22722. > 
  22723. > ---
  22724. > Robert J. Adams radams@siscom.net http://www.siscom.net
  22725. > Looking to outsource news? http://www.newshosting.com
  22726. > SISCOM Network Administration - President, SISCOM Inc.
  22727. > Phone: 937-222-8150 FAX: 937-222-8153 
  22728. > 
  22729. > 
  22730. > -
  22731. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22732. >  with "unsubscribe usr-tc" in the body of the message.
  22733. >  For information on digests or retrieving files and old messages send
  22734. >  "help" to the same address.  Do not use quotes in your message.
  22735. > 
  22736.  
  22737. -
  22738.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22739.  with "unsubscribe usr-tc" in the body of the message.
  22740.  For information on digests or retrieving files and old messages send
  22741.  "help" to the same address.  Do not use quotes in your message.
  22742.  
  22743.  
  22744. -------------------------------------------------------------------------------
  22745.  
  22746. From: Curt Shambeau <curt@execpc.com>
  22747. Subject: (usr-tc) Comment from 3COM on latest DSP code please...
  22748. Date: 18 Mar 1999 14:33:51 -0600 (CST)
  22749.  
  22750.  
  22751. The release notes only show differences in 1.2.43 and 1.2.5.
  22752.  
  22753. I just got done flashing 1.2.59 into a LOT of my chassis around here.
  22754. Could somebody please comment on the changes between 1.2.59 and 1.2.43.
  22755.  
  22756. Thank you.
  22757.  
  22758. | Curtis V. Shambeau  |  curt@execpc.com  |  http://www.execpc.com/~curt |
  22759. |                Senior Vice President - Exec-PC, Inc.                   |
  22760.  
  22761.  
  22762. -
  22763.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22764.  with "unsubscribe usr-tc" in the body of the message.
  22765.  For information on digests or retrieving files and old messages send
  22766.  "help" to the same address.  Do not use quotes in your message.
  22767.  
  22768.  
  22769. -------------------------------------------------------------------------------
  22770.  
  22771. From: "Frank Basso" <frank@got.net>
  22772. Subject: Re: (usr-tc) DSP1.2.43 
  22773. Date: 18 Mar 1999 12:43:03 -0800
  22774.  
  22775. It always starts that way......
  22776. -----Original Message-----
  22777.  
  22778.  
  22779. >yep, no problems so far. 
  22780. >
  22781. >blake
  22782. >
  22783. >> -----Original Message-----
  22784. >> From: Robert J. Adams [mailto:radams@siscom.net]
  22785. >> Sent: Thursday, March 18, 1999 2:04 PM
  22786. >> To: usr-tc@lists.xmission.com
  22787. >> Subject: (usr-tc) DSP1.2.43 
  22788. >> 
  22789. >> 
  22790. >> Hello,
  22791. >> 
  22792. >> Anyone tried the new 1.2.43 code yet?
  22793. >> 
  22794. >> -j
  22795. >> 
  22796. >> ---
  22797. >> Robert J. Adams radams@siscom.net http://www.siscom.net
  22798. >> Looking to outsource news? http://www.newshosting.com
  22799. >> SISCOM Network Administration - President, SISCOM Inc.
  22800. >> Phone: 937-222-8150 FAX: 937-222-8153 
  22801. >> 
  22802. >> 
  22803. >> -
  22804. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22805. >>  with "unsubscribe usr-tc" in the body of the message.
  22806. >>  For information on digests or retrieving files and old messages send
  22807. >>  "help" to the same address.  Do not use quotes in your message.
  22808. >> 
  22809. >
  22810. >-
  22811. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22812. > with "unsubscribe usr-tc" in the body of the message.
  22813. > For information on digests or retrieving files and old messages send
  22814. > "help" to the same address.  Do not use quotes in your message.
  22815. >
  22816.  
  22817.  
  22818. -
  22819.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22820.  with "unsubscribe usr-tc" in the body of the message.
  22821.  For information on digests or retrieving files and old messages send
  22822.  "help" to the same address.  Do not use quotes in your message.
  22823.  
  22824.  
  22825. -------------------------------------------------------------------------------
  22826.  
  22827. From: Jeremy Shaffner <jer@jorsm.com>
  22828. Subject: (usr-tc) Subnet routing on NETServer 16I
  22829. Date: 18 Mar 1999 14:57:13 -0600 (CST)
  22830.  
  22831.  
  22832. We're using a NS16I for dedicated dial-up customers (ISDN & x2.)  Static
  22833. routes (Since the 16I doesn't do RIP2) do the trick for two Class C's, and
  22834. one host route (They're using NAT), but we have a new customer with a /28
  22835. (16 IP's) subnet.
  22836.  
  22837. The subnet is 209.224.119.224/28.
  22838. 209.224.119.238 is assigned to them via RADIUS.
  22839.  
  22840. I've added and saved a static route on the NetServer with `add route
  22841. 209.224.119.224
  22842. 209.224.119.238 1`.
  22843.  
  22844. I've added and saved an entry to the netmask table with `add netmask
  22845. 209.224.119.224
  22846. 255.255.255.240`.
  22847.  
  22848. A `show route` rightly shows these two entries:
  22849.  
  22850. 209.224.119.224        209.224.119.238      HSC    1  ptp12
  22851. 209.224.119.238        209.224.119.238      HLC    1  ptp12
  22852.  
  22853. And a `show table netmask` shows:
  22854.  
  22855. Active Netmasks:
  22856. Network          Netmask          Type
  22857. ---------------- ---------------- -------
  22858. 209.224.119.224  255.255.255.240  Static
  22859. 209.100.92.0     255.255.255.192  Dynamic
  22860. Stored Netmasks:
  22861. Network          Netmask
  22862. ---------------- ----------------
  22863. 209.224.119.224  255.255.255.240
  22864.  
  22865.  
  22866. A static route has been created on our Cisco 3640 directing
  22867. 209.224.119.224/28 traffic to the NETServer.
  22868.  
  22869. Traces to 209.224.119.238 arrive as expected.  Any traces to
  22870. 209.224.119.225-237 bounce back and forth between the NETServer and the
  22871. Cisco.
  22872.  
  22873. The NETServer is running 3.3.0 (Date: Nov 14 1997)
  22874.  
  22875. How can I get this to work correctly?  14 static routes is messy, and 
  22876. upgrading to NetServer+ is worse.
  22877.  
  22878. TIA,
  22879.  
  22880. -Jeremy
  22881.  
  22882.  
  22883. -=========================================================================-
  22884. Jeremy Shaffner                  JORSM Internet, Regional Internet Services    
  22885. Senior Technical Support         7 Area Codes in Chicagoland and NW Indiana 
  22886. jer@jorsm.com                    100Mbps+ Connectivity, 56K-DS3, V.90, ISDN  
  22887. support@jorsm.com                Quality Service, Affordable Prices
  22888. http://www.jorsm.com             Serving Gov, Biz, Indivds Since 1995
  22889. -=========================================================================-
  22890.  
  22891.  
  22892. -
  22893.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22894.  with "unsubscribe usr-tc" in the body of the message.
  22895.  For information on digests or retrieving files and old messages send
  22896.  "help" to the same address.  Do not use quotes in your message.
  22897.  
  22898.  
  22899. -------------------------------------------------------------------------------
  22900.  
  22901. From: <pferraro@wna-linknet.com>
  22902. Subject: RE: (usr-tc) DSP1.2.43 
  22903. Date: 18 Mar 1999 16:06:34 -0500 (EST)
  22904.  
  22905.  
  22906.     When did they "RELEASE" this code?  We still have 1.2.59!  Any
  22907. "REAL" bug fixes in this release?
  22908.  
  22909. ==============================================================================
  22910. Phillip Ferraro                WorldNet Access, Inc
  22911. pferraro@wna-linknet.com    Onslow County's PREMIER InterNet Service 
  22912. Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  22913. FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  22914. ==============================================================================
  22915.  
  22916. On Thu, 18 Mar 1999, Blake Fithen wrote:
  22917.  
  22918. > yep, no problems so far. 
  22919. > 
  22920. > blake
  22921. > 
  22922. > > -----Original Message-----
  22923. > > From: Robert J. Adams [mailto:radams@siscom.net]
  22924. > > Sent: Thursday, March 18, 1999 2:04 PM
  22925. > > To: usr-tc@lists.xmission.com
  22926. > > Subject: (usr-tc) DSP1.2.43 
  22927. > > 
  22928. > > 
  22929. > > Hello,
  22930. > > 
  22931. > > Anyone tried the new 1.2.43 code yet?
  22932. > > 
  22933. > > -j
  22934. > > 
  22935. > > ---
  22936. > > Robert J. Adams radams@siscom.net http://www.siscom.net
  22937. > > Looking to outsource news? http://www.newshosting.com
  22938. > > SISCOM Network Administration - President, SISCOM Inc.
  22939. > > Phone: 937-222-8150 FAX: 937-222-8153 
  22940. > > 
  22941. > > 
  22942. > > -
  22943. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22944. > >  with "unsubscribe usr-tc" in the body of the message.
  22945. > >  For information on digests or retrieving files and old messages send
  22946. > >  "help" to the same address.  Do not use quotes in your message.
  22947. > > 
  22948. > 
  22949. > -
  22950. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22951. >  with "unsubscribe usr-tc" in the body of the message.
  22952. >  For information on digests or retrieving files and old messages send
  22953. >  "help" to the same address.  Do not use quotes in your message.
  22954. > 
  22955.  
  22956.  
  22957. -
  22958.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22959.  with "unsubscribe usr-tc" in the body of the message.
  22960.  For information on digests or retrieving files and old messages send
  22961.  "help" to the same address.  Do not use quotes in your message.
  22962.  
  22963.  
  22964. -------------------------------------------------------------------------------
  22965.  
  22966. From: Brian Elfert <brian@citilink.com>
  22967. Subject: (usr-tc) Debugging RIP
  22968. Date: 18 Mar 1999 15:34:42 -0600 (CST)
  22969.  
  22970. I have 4 TCs with Netservers that broadcast RIPv1 to a Cisco 7206
  22971. (Formerly a Cisco 4000) just fine.
  22972.  
  22973. I installed another TC with Netserver with the same exact config, but it's
  22974. talking to a Cisco 4000 instead.  No RIP routes show up on the Cisco 4000,
  22975. but routing is working, probably due to proxy ARP.
  22976.  
  22977. How can I debug the RIP problems?  (I double checked the TC settings.)
  22978.  
  22979. Here is my Cisco config
  22980.  
  22981. router rip
  22982.  passive-interface Ethernet0
  22983.  passive-interface Ethernet2
  22984.  network 209.98.223.0
  22985.  
  22986. The network is on e1 and the IP addresses are in 209.98.223/24.
  22987.  
  22988. Brian
  22989.  
  22990.  
  22991. -
  22992.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  22993.  with "unsubscribe usr-tc" in the body of the message.
  22994.  For information on digests or retrieving files and old messages send
  22995.  "help" to the same address.  Do not use quotes in your message.
  22996.  
  22997.  
  22998. -------------------------------------------------------------------------------
  22999.  
  23000. From: David Bolen <db3l@ans.net>
  23001. Subject: Re: (usr-tc) Debugging RIP
  23002. Date: 18 Mar 1999 16:46:17 EST
  23003.  
  23004. Brian Elfert <brian@citilink.com> writes:
  23005.  
  23006. > How can I debug the RIP problems?  (I double checked the TC settings.)
  23007.  
  23008. My first shot would be "debug ip rip" on the Cisco.  (with "term mon"
  23009. to see debugging).
  23010.  
  23011. This will at least let you know what the Cisco thinks it is hearing
  23012. (if anything) versus what the NETServer is generating (which you might
  23013. verify if it's otherwise idle with ptrace).  Might at least let you
  23014. point at one side or the other.
  23015.  
  23016. -- David
  23017.  
  23018. /-----------------------------------------------------------------------\
  23019.  \               David Bolen              \  Internet: db3l@ans.net    /
  23020.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  23021.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  23022. \-----------------------------------------------------------------------/
  23023.  
  23024. -
  23025.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23026.  with "unsubscribe usr-tc" in the body of the message.
  23027.  For information on digests or retrieving files and old messages send
  23028.  "help" to the same address.  Do not use quotes in your message.
  23029.  
  23030.  
  23031. -------------------------------------------------------------------------------
  23032.  
  23033. From: "David Bachta" <David_Bachta@mw.3com.com>
  23034. Subject: Re: (usr-tc) Comment from 3COM on latest DSP code please...
  23035. Date: 18 Mar 1999 16:07:00 -0600
  23036.  
  23037.  
  23038.  
  23039. Hi Curt,
  23040.  
  23041. Below are the two major issues resolved from 1.2.59 to 1.2.43.
  23042.  
  23043. Hope this helps.
  23044.  
  23045. Regards,
  23046. David
  23047.  
  23048. MR 2021 Improved V.42 compatibility with slower Win-modem clients.
  23049. MR 2029 Issue : Failure to connect rates were too high and back channel
  23050. speeds were too low.  Resolution : The answer tone level was hard-coded and too
  23051. loud
  23052. to trigger the network echo cancellers in some environments.
  23053.  
  23054.  
  23055.  
  23056.  
  23057.  
  23058. Curt Shambeau <curt@execpc.com> on 03/18/99 02:33:51 PM
  23059.  
  23060. Please respond to usr-tc@lists.xmission.com
  23061.  
  23062. cc:    (David Bachta/MW/US/3Com)
  23063.  
  23064.  
  23065.  
  23066.  
  23067.  
  23068. The release notes only show differences in 1.2.43 and 1.2.5.
  23069.  
  23070. I just got done flashing 1.2.59 into a LOT of my chassis around here.
  23071. Could somebody please comment on the changes between 1.2.59 and 1.2.43.
  23072.  
  23073. Thank you.
  23074.  
  23075. | Curtis V. Shambeau  |  curt@execpc.com  |  http://www.execpc.com/~curt |
  23076. |                Senior Vice President - Exec-PC, Inc.                   |
  23077.  
  23078.  
  23079. -
  23080.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23081.  with "unsubscribe usr-tc" in the body of the message.
  23082.  For information on digests or retrieving files and old messages send
  23083.  "help" to the same address.  Do not use quotes in your message.
  23084.  
  23085.  
  23086.  
  23087.  
  23088.  
  23089.  
  23090.  
  23091.  
  23092. -
  23093.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23094.  with "unsubscribe usr-tc" in the body of the message.
  23095.  For information on digests or retrieving files and old messages send
  23096.  "help" to the same address.  Do not use quotes in your message.
  23097.  
  23098.  
  23099. -------------------------------------------------------------------------------
  23100.  
  23101. From: K Mitchell <mitch@keyconn.net>
  23102. Subject: RE: (usr-tc) HyperARC needs a regular reboot?
  23103. Date: 18 Mar 1999 17:12:50 -0500
  23104.  
  23105. At 11:54 AM 3/18/99 +0100, Robert von Bismarck wrote:
  23106. >Sound like the dreaded 4.1.72-7 memory leak on the ARC. This is probably
  23107. >coming from MPIP. There's only one solution : upgrade your code
  23108.  
  23109. I know this is a bit far-fetched but; I haven't had any problems with my
  23110. ARC console connection but, I've recently seen S&A Server sucking up
  23111. increasing amounts of memory, requiring a restart every couple of days. I'm
  23112. running;
  23113. S&A Server 5.5.3 on NT 4
  23114. ARC 4.1.72
  23115.  
  23116. Kirk
  23117.  
  23118.  
  23119.  
  23120. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  23121. Keystone Connect                http://www.keyconn.net
  23122. Altoona, PA   814-941-5000         We Unlock the World
  23123.  
  23124.  
  23125. -
  23126.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23127.  with "unsubscribe usr-tc" in the body of the message.
  23128.  For information on digests or retrieving files and old messages send
  23129.  "help" to the same address.  Do not use quotes in your message.
  23130.  
  23131.  
  23132. -------------------------------------------------------------------------------
  23133.  
  23134. From: Blake Fithen <fithen@NetworksPlus.com>
  23135. Subject: RE: (usr-tc) HyperARC needs a regular reboot?
  23136. Date: 18 Mar 1999 16:40:39 -0600
  23137.  
  23138. upgrade to 6.0.9.  5.3.3 is very old.  3com said 6.0.9 is 
  23139. backward compatible with all ARC releases.  hard to believe
  23140. but... (can't find the Software Compatibility Matrix to
  23141. verify).
  23142.  
  23143. blake
  23144.  
  23145. > -----Original Message-----
  23146. > From: K Mitchell [mailto:mitch@keyconn.net]
  23147. > Sent: Thursday, March 18, 1999 4:13 PM
  23148. > To: usr-tc@lists.xmission.com
  23149. > Subject: RE: (usr-tc) HyperARC needs a regular reboot?
  23150. > 
  23151. > 
  23152. > At 11:54 AM 3/18/99 +0100, Robert von Bismarck wrote:
  23153. > >Sound like the dreaded 4.1.72-7 memory leak on the ARC. This 
  23154. > is probably
  23155. > >coming from MPIP. There's only one solution : upgrade your code
  23156. > 
  23157. > I know this is a bit far-fetched but; I haven't had any 
  23158. > problems with my
  23159. > ARC console connection but, I've recently seen S&A Server sucking up
  23160. > increasing amounts of memory, requiring a restart every 
  23161. > couple of days. I'm
  23162. > running;
  23163. > S&A Server 5.5.3 on NT 4
  23164. > ARC 4.1.72
  23165. > 
  23166. > Kirk
  23167. > 
  23168. > 
  23169. > 
  23170. > Kirk Mitchell-General Manager     sysadmin@keyconn.net
  23171. > Keystone Connect                http://www.keyconn.net
  23172. > Altoona, PA   814-941-5000         We Unlock the World
  23173. > 
  23174. > 
  23175. > -
  23176. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23177. >  with "unsubscribe usr-tc" in the body of the message.
  23178. >  For information on digests or retrieving files and old messages send
  23179. >  "help" to the same address.  Do not use quotes in your message.
  23180. > 
  23181.  
  23182. -
  23183.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23184.  with "unsubscribe usr-tc" in the body of the message.
  23185.  For information on digests or retrieving files and old messages send
  23186.  "help" to the same address.  Do not use quotes in your message.
  23187.  
  23188.  
  23189. -------------------------------------------------------------------------------
  23190.  
  23191. From: MegaZone <megazone@megazone.org>
  23192. Subject: Re: (usr-tc) Port Limit with bsdi radius
  23193. Date: 18 Mar 1999 15:50:27 -0800 (PST)
  23194.  
  23195. Once upon a time Mark Starr shaped the electrons to say...
  23196. > I am using bsdi radius that comes with 3.1(very close to merit radius). I
  23197. >am trying to implement the port-limit setting, but it does not seem to work.
  23198. >I have three machines doing auth and one doing all the logging. I set
  23199. >Port-Limit = 1 and even tried Simultaneous-Use = 1, but am still able to
  23200. >login mult. times. Any ideas or suggestions?
  23201.  
  23202. Port-Limit DOES NOT limit multiple logins - period.  What Port-Limit controls
  23203. is the number of channels allowed in an MP bundle - it has no bearing at all
  23204. on mutliple simultaneous, SEPARATE, logins.
  23205.  
  23206. Simultaneous-Use is server specific and requires intelligence on the 
  23207. RADIUS server to deal with it.  Last I knew Merit didn't handle it well -
  23208. my personal recommendation would be to grab Cistron RADIUS which DOES
  23209. handle simultaneous use limits with all popular NASen.  AND Cistron also
  23210. handles 3Com VSAs.
  23211.  
  23212. -MZ
  23213. -- 
  23214. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  23215. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  23216. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  23217. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  23218. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  23219.  
  23220. -
  23221.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23222.  with "unsubscribe usr-tc" in the body of the message.
  23223.  For information on digests or retrieving files and old messages send
  23224.  "help" to the same address.  Do not use quotes in your message.
  23225.  
  23226.  
  23227. -------------------------------------------------------------------------------
  23228.  
  23229. From: K Mitchell <mitch@keyconn.net>
  23230. Subject: RE: (usr-tc) HyperARC needs a regular reboot?
  23231. Date: 18 Mar 1999 19:07:59 -0500
  23232.  
  23233. At 04:40 PM 3/18/99 -0600, you wrote:
  23234. >upgrade to 6.0.9.  5.3.3 is very old.  3com said 6.0.9 is 
  23235. >backward compatible with all ARC releases.  hard to believe
  23236. >but... (can't find the Software Compatibility Matrix to
  23237. >verify).
  23238.  
  23239. I'd love to but, S&A Server was originally provided to me free by Source,
  23240. who sold me my hub. It appears that Source no longer provides this and,
  23241. naturally, 3Com won't give me a free upgrade(despite the fact that 5.5.3
  23242. has never worked correctly for me). I hesitate to pay for the newer version
  23243. considering I can likely get a much better product than S&A Server if I'm
  23244. shelling out bucks.
  23245.  
  23246. Kirk
  23247.  
  23248.  
  23249.  
  23250. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  23251. Keystone Connect                http://www.keyconn.net
  23252. Altoona, PA   814-941-5000         We Unlock the World
  23253.  
  23254.  
  23255. -
  23256.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23257.  with "unsubscribe usr-tc" in the body of the message.
  23258.  For information on digests or retrieving files and old messages send
  23259.  "help" to the same address.  Do not use quotes in your message.
  23260.  
  23261.  
  23262. -------------------------------------------------------------------------------
  23263.  
  23264. From: Rick <rickyz@mindspring.com>
  23265. Subject: (usr-tc) Facility IP Level critical..
  23266. Date: 18 Mar 1999 20:02:56 -0500
  23267.  
  23268. Anyone,
  23269. I had error message on my log screen, it is the first time since we 
  23270. installed this system last May.
  23271.  
  23272. It seems to me everything looks normal for now...but I want your opinion.
  23273. It said:
  23274.    At 19:16:52, Facility "IP", Level "CRITICAL" :: [../../net/igmp_host.C]:
  23275.    Failed to join the multicast group, 224.0.0.1
  23276.  
  23277. I do not what this means, so I am little worried.
  23278. Can you explain it to me??
  23279.  
  23280. Rickyz@mindspring.com
  23281.  
  23282.  
  23283.  
  23284. -
  23285.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23286.  with "unsubscribe usr-tc" in the body of the message.
  23287.  For information on digests or retrieving files and old messages send
  23288.  "help" to the same address.  Do not use quotes in your message.
  23289.  
  23290.  
  23291. -------------------------------------------------------------------------------
  23292.  
  23293. From: "Mike Hamrich" <mhamrich@drfast.net>
  23294. Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  23295. Date: 18 Mar 1999 20:20:40 -0500
  23296.  
  23297. OK HiperArc with latest code 3/4/99
  23298.  
  23299. Since the "upgrade" we are having tons of connection issues.
  23300. Couriers can't connect
  23301. Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  23302. OEM/Brown box Sportsters can't stay connected
  23303.  
  23304. We also told owner of non X2 modem to go elsewere.
  23305.  
  23306. We surveyed our users, 248 replied so far:
  23307. 67% say slower speed, 22% are having problems saying connected, 4% can't
  23308. connect at all, and ONLY 7%  report better connection.
  23309.  
  23310. We have PRI lines, Set PPP offloading to no, Authenticate ANY Preferrd PAP
  23311.  
  23312. Any other ideas to make this stuff work as well as the old stuff did?
  23313.  
  23314. Thanks in advance for you help
  23315.  
  23316. Mike Hamrich
  23317. CIO, DrFast.Net, Inc.
  23318. (216) 797-1040
  23319.  
  23320.  
  23321. -
  23322.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23323.  with "unsubscribe usr-tc" in the body of the message.
  23324.  For information on digests or retrieving files and old messages send
  23325.  "help" to the same address.  Do not use quotes in your message.
  23326.  
  23327.  
  23328. -------------------------------------------------------------------------------
  23329.  
  23330. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  23331. Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  23332. Date: 18 Mar 1999 19:52:03 -0600 (CST)
  23333.  
  23334. On Thu, 18 Mar 1999, Mike Hamrich wrote:
  23335.  
  23336. > OK HiperArc with latest code 3/4/99
  23337.  
  23338. I assume that you now have HiPer arc 4.1.59 -6 code.  
  23339. What is the DSP code that you have?
  23340. > 
  23341. > Since the "upgrade" we are having tons of connection issues.
  23342. > Couriers can't connect
  23343. > Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  23344. > OEM/Brown box Sportsters can't stay connected
  23345. > 
  23346. > We also told owner of non X2 modem to go elsewere.
  23347. > 
  23348. > We surveyed our users, 248 replied so far:
  23349. > 67% say slower speed, 22% are having problems saying connected, 4% can't
  23350. > connect at all, and ONLY 7%  report better connection.
  23351. > 
  23352. > We have PRI lines, Set PPP offloading to no, Authenticate ANY Preferrd PAP
  23353.  
  23354. If look at the release notes for this - There is a clear mention to set
  23355. PPP offloading to enable  and also to disable ppp receive_accm
  23356.  
  23357.  
  23358.  
  23359. > Any other ideas to make this stuff work as well as the old stuff did?
  23360.  
  23361.  
  23362. Set the PPP off loading to enable
  23363.  
  23364. enable ppp offloading
  23365. that should help you a lot.
  23366.  
  23367. Also need to know the version of DSP code
  23368.  
  23369. regards
  23370. krish
  23371. > 
  23372. > Thanks in advance for you help
  23373. > 
  23374. > Mike Hamrich
  23375. > CIO, DrFast.Net, Inc.
  23376. > (216) 797-1040
  23377. > 
  23378. > 
  23379. > -
  23380. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23381. >  with "unsubscribe usr-tc" in the body of the message.
  23382. >  For information on digests or retrieving files and old messages send
  23383. >  "help" to the same address.  Do not use quotes in your message.
  23384. > 
  23385.  
  23386. -
  23387.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23388.  with "unsubscribe usr-tc" in the body of the message.
  23389.  For information on digests or retrieving files and old messages send
  23390.  "help" to the same address.  Do not use quotes in your message.
  23391.  
  23392.  
  23393. -------------------------------------------------------------------------------
  23394.  
  23395. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  23396. Subject: Re: (usr-tc) Facility IP Level critical..
  23397. Date: 18 Mar 1999 20:13:57 -0600 (CST)
  23398.  
  23399. On Thu, 18 Mar 1999, Rick wrote:
  23400.  
  23401. > Anyone,
  23402. > I had error message on my log screen, it is the first time since we 
  23403. > installed this system last May.
  23404. > 
  23405. > It seems to me everything looks normal for now...but I want your opinion.
  23406. > It said:
  23407. >    At 19:16:52, Facility "IP", Level "CRITICAL" :: [../../net/igmp_host.C]:
  23408. >    Failed to join the multicast group, 224.0.0.1
  23409.  
  23410. This message basically tells you that the Hiper arc could not join the 
  23411. multicast group.  This could be because you have not setup multicast 
  23412. properlly on the ARC.
  23413.  
  23414. Check your multicast configuration - rather the igmp config
  23415.  
  23416. krish
  23417.  
  23418. > 
  23419. > I do not what this means, so I am little worried.
  23420. > Can you explain it to me??
  23421. > 
  23422. > Rickyz@mindspring.com
  23423. > 
  23424. > 
  23425. > 
  23426. > -
  23427. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23428. >  with "unsubscribe usr-tc" in the body of the message.
  23429. >  For information on digests or retrieving files and old messages send
  23430. >  "help" to the same address.  Do not use quotes in your message.
  23431. > 
  23432.  
  23433. -
  23434.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23435.  with "unsubscribe usr-tc" in the body of the message.
  23436.  For information on digests or retrieving files and old messages send
  23437.  "help" to the same address.  Do not use quotes in your message.
  23438.  
  23439.  
  23440. -------------------------------------------------------------------------------
  23441.  
  23442. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  23443. Subject: Re: (usr-tc) Netserver 8/16 I assigning DNS to users.
  23444. Date: 18 Mar 1999 20:15:03 -0600 (CST)
  23445.  
  23446. On Thu, 18 Mar 1999, Netlink Hardware admin wrote:
  23447.  
  23448. > 
  23449. > Hello all,
  23450. > 
  23451. > I am using Netserver 8/16 I for X2, V.90, ISDN, and analog dial in.
  23452. > I also use Livingson PM2E for strictly analog dial in.
  23453. > 
  23454.  
  23455.  
  23456. The Netserver 8/16 does not support the DNS and wins attributes.
  23457.  
  23458. krish
  23459.  
  23460. > I have the DNS servers set in the Netserver config. (and PM2)
  23461. > 
  23462. > Currently we have the users specify the Name Server addresses in their
  23463. > setup.
  23464. > 
  23465. > While testing I set my config (WIN95/98) to use server assigned name
  23466. > server addresses.
  23467. > 
  23468. > This works fine on the PM2, but the Netserver doesn't seem to report the
  23469. > nameservers to the clients when they dial in.
  23470. > 
  23471. > Is this a known problem/feature or should I be looking for some other
  23472. > problem?
  23473. > 
  23474. > How can I set up the Netservers to assign the DNS to the dial-in clients?
  23475. > 
  23476. > Thanks,
  23477. > 
  23478. > Curt
  23479. > 
  23480. > 
  23481. > 
  23482. > 
  23483. > -
  23484. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23485. >  with "unsubscribe usr-tc" in the body of the message.
  23486. >  For information on digests or retrieving files and old messages send
  23487. >  "help" to the same address.  Do not use quotes in your message.
  23488. > 
  23489.  
  23490. -
  23491.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23492.  with "unsubscribe usr-tc" in the body of the message.
  23493.  For information on digests or retrieving files and old messages send
  23494.  "help" to the same address.  Do not use quotes in your message.
  23495.  
  23496.  
  23497. -------------------------------------------------------------------------------
  23498.  
  23499. From: Blake Fithen <fithen@NetworksPlus.com>
  23500. Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  23501. Date: 18 Mar 1999 20:10:34 -0600
  23502.  
  23503. ARC 4.1.59-6
  23504. DSP 1.2.43
  23505.  
  23506. The only thing we having problems with are ISDN calls.  Analog
  23507. current link transmit rates are anywhere from 14,400 to 53,300.
  23508. But i haven't seen a single ISDN call get established and pass 
  23509. data. mon ppp, and mon radius show nothing - "li co"  will show 
  23510. the modem being tied up but after about 10 seconds it drops.  I 
  23511. had a few ISDN customers connected with 4.1.59 and 1.2.59 but
  23512. as soon as I upgraded the DSP to 1.2.43 things went downhill.  
  23513.  
  23514. [1 hour goes by]
  23515.  
  23516. and at 7:30 my pager goes nuts saying that all our dedicated
  23517. ISDN customers are back up.  during this time i have been
  23518. gathering statistics from the incomplete ISDN calls and then 
  23519. many dedicated customers with ISDN devices from many different
  23520. vendors begin working again without any intervention from me.
  23521. Ah! and everything came back up about the same time last night!
  23522.  
  23523. WHAT THE HELL??!?!?!
  23524.  
  23525. any similar experiences? TELCO sabotage? 
  23526.  
  23527. blake
  23528.  
  23529.  
  23530. > -----Original Message-----
  23531. > From: Mike Hamrich [mailto:mhamrich@drfast.net]
  23532. > Sent: Thursday, March 18, 1999 7:21 PM
  23533. > To: usr-tc@lists.xmission.com
  23534. > Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  23535. > 
  23536. > 
  23537. > OK HiperArc with latest code 3/4/99
  23538. > 
  23539. > Since the "upgrade" we are having tons of connection issues.
  23540. > Couriers can't connect
  23541. > Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  23542. > OEM/Brown box Sportsters can't stay connected
  23543. > 
  23544. > We also told owner of non X2 modem to go elsewere.
  23545. > 
  23546. > We surveyed our users, 248 replied so far:
  23547. > 67% say slower speed, 22% are having problems saying 
  23548. > connected, 4% can't
  23549. > connect at all, and ONLY 7%  report better connection.
  23550. > 
  23551. > We have PRI lines, Set PPP offloading to no, Authenticate ANY 
  23552. > Preferrd PAP
  23553. > 
  23554. > Any other ideas to make this stuff work as well as the old stuff did?
  23555. > 
  23556. > Thanks in advance for you help
  23557. > 
  23558. > Mike Hamrich
  23559. > CIO, DrFast.Net, Inc.
  23560. > (216) 797-1040
  23561. > 
  23562. > 
  23563. > -
  23564. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23565. >  with "unsubscribe usr-tc" in the body of the message.
  23566. >  For information on digests or retrieving files and old messages send
  23567. >  "help" to the same address.  Do not use quotes in your message.
  23568. > 
  23569.  
  23570. -
  23571.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23572.  with "unsubscribe usr-tc" in the body of the message.
  23573.  For information on digests or retrieving files and old messages send
  23574.  "help" to the same address.  Do not use quotes in your message.
  23575.  
  23576.  
  23577. -------------------------------------------------------------------------------
  23578.  
  23579. From: Jeff Mcadams <jeffm@iglou.com>
  23580. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  23581. Date: 18 Mar 1999 22:09:11 -0500 (EST)
  23582.  
  23583. Thus spake K Mitchell
  23584. >At 04:40 PM 3/18/99 -0600, you wrote:
  23585. >>upgrade to 6.0.9.  5.3.3 is very old.  3com said 6.0.9 is 
  23586. >>backward compatible with all ARC releases.  hard to believe
  23587. >>but... (can't find the Software Compatibility Matrix to
  23588. >>verify).
  23589.  
  23590. >I'd love to but, S&A Server was originally provided to me free by Source,
  23591. >who sold me my hub. It appears that Source no longer provides this and,
  23592. >naturally, 3Com won't give me a free upgrade(despite the fact that 5.5.3
  23593. >has never worked correctly for me). I hesitate to pay for the newer version
  23594. >considering I can likely get a much better product than S&A Server if I'm
  23595. >shelling out bucks.
  23596.  
  23597. Gee...can I connect this back to my "3Com Problems" thread from last
  23598. week or so?  Sounds like much the same situation, and screw the customer
  23599. even though 3Com didn't deliver what they promised attitude that we're
  23600. *still* fighting with 3Com.
  23601. -- 
  23602. Jeff McAdams                            Email: jeffm@iglou.com
  23603. Head Network Administrator              Voice: (502) 966-3848
  23604. IgLou Internet Services                        (800) 436-4456
  23605.  
  23606. -
  23607.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23608.  with "unsubscribe usr-tc" in the body of the message.
  23609.  For information on digests or retrieving files and old messages send
  23610.  "help" to the same address.  Do not use quotes in your message.
  23611.  
  23612.  
  23613. -------------------------------------------------------------------------------
  23614.  
  23615. From: K Mitchell <mitch@keyconn.net>
  23616. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  23617. Date: 18 Mar 1999 22:37:41 -0500
  23618.  
  23619. At 10:09 PM 3/18/99 -0500, Jeff Mcadams wrote:
  23620. >Thus spake K Mitchell
  23621. >>At 04:40 PM 3/18/99 -0600, you wrote:
  23622. >>>upgrade to 6.0.9.  5.3.3 is very old.  3com said 6.0.9 is 
  23623. >>>backward compatible with all ARC releases.  hard to believe
  23624. >>>but... (can't find the Software Compatibility Matrix to
  23625. >>>verify).
  23626. >
  23627. >>I'd love to but, S&A Server was originally provided to me free by Source,
  23628. >>who sold me my hub. It appears that Source no longer provides this and,
  23629. >>naturally, 3Com won't give me a free upgrade(despite the fact that 5.5.3
  23630. >>has never worked correctly for me). I hesitate to pay for the newer version
  23631. >>considering I can likely get a much better product than S&A Server if I'm
  23632. >>shelling out bucks.
  23633. >
  23634. >Gee...can I connect this back to my "3Com Problems" thread from last
  23635. >week or so?  Sounds like much the same situation, and screw the customer
  23636. >even though 3Com didn't deliver what they promised attitude that we're
  23637. >*still* fighting with 3Com.
  23638.  
  23639. No arguement here. It's really a shame that 3Com continues support policies
  23640. that steer so many potential customers to other vendors. Hardware-wise, I
  23641. feel the HiPer chassis is amoung the best currently available, but 3Com
  23642. management is selling a lot of product for their competitors.
  23643.  
  23644. Kirk
  23645.  
  23646.  
  23647.  
  23648.  
  23649. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  23650. Keystone Connect                http://www.keyconn.net
  23651. Altoona, PA   814-941-5000         We Unlock the World
  23652.  
  23653.  
  23654. -
  23655.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23656.  with "unsubscribe usr-tc" in the body of the message.
  23657.  For information on digests or retrieving files and old messages send
  23658.  "help" to the same address.  Do not use quotes in your message.
  23659.  
  23660.  
  23661. -------------------------------------------------------------------------------
  23662.  
  23663. From: d baud <dbaud@bigfoot.com>
  23664. Subject: (usr-tc) PRI to overflow to another telco's PRI ?
  23665. Date: 19 Mar 1999 00:13:31 -0500
  23666.  
  23667. I am currently trying to switch to another PRI provider, and to do a
  23668. gradual move of all my PRIs I would need to have my old PRIs to overflow
  23669. (when busy) to some other PRIs in another Central Office (in the same
  23670. area code).
  23671. The two telcos say that it is technically impossible to program this
  23672. feature on the DMS since it is not in the same Central Office.  Could
  23673. someone confirm if this is true ?
  23674.  
  23675. Also, would you say that it would be possible to have the old telco PRI
  23676. to overflow to a centrex line in the same CO.  And then program the
  23677. centrex line to forward calls to the phone number of the other PRI of
  23678. the other telco ?
  23679.  
  23680. D Baud
  23681.  
  23682. -
  23683.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23684.  with "unsubscribe usr-tc" in the body of the message.
  23685.  For information on digests or retrieving files and old messages send
  23686.  "help" to the same address.  Do not use quotes in your message.
  23687.  
  23688.  
  23689. -------------------------------------------------------------------------------
  23690.  
  23691. From: Ricky Beam <jfbeam@beaker.interpath.net>
  23692. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  23693. Date: 19 Mar 1999 01:05:02 -0500 (EST)
  23694.  
  23695. On Thu, 18 Mar 1999, Jeff Mcadams wrote:
  23696. >Gee...can I connect this back to my "3Com Problems" thread from last
  23697. >week or so?  Sounds like much the same situation, and screw the customer
  23698. >even though 3Com didn't deliver what they promised attitude that we're
  23699. >*still* fighting with 3Com.
  23700.  
  23701. No.  I got Win3.1 with my computer; does that mean Microsoft should give me
  23702. a free copy of 95? (or 95->98...)  He didn't buy the radius server, so why
  23703. should 3Com give away something they've devoted resources to develop?  What
  23704. kind of problems do you have with 5.5.3?
  23705.  
  23706. --Ricky
  23707.  
  23708.  
  23709.  
  23710. -
  23711.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23712.  with "unsubscribe usr-tc" in the body of the message.
  23713.  For information on digests or retrieving files and old messages send
  23714.  "help" to the same address.  Do not use quotes in your message.
  23715.  
  23716.  
  23717. -------------------------------------------------------------------------------
  23718.  
  23719. From: Ricky Beam <jfbeam@beaker.interpath.net>
  23720. Subject: Re: (usr-tc) PRI to overflow to another telco's PRI ?
  23721. Date: 19 Mar 1999 01:18:23 -0500 (EST)
  23722.  
  23723. On Fri, 19 Mar 1999, d baud wrote:
  23724. >The two telcos say that it is technically impossible to program this
  23725. >feature on the DMS since it is not in the same Central Office.  Could
  23726. >someone confirm if this is true ?
  23727.  
  23728. Not "impossible", just impracticle.  It would not be a normal rotary type of
  23729. setup.  The telco would have to setup some form of call forwarding to get the
  23730. overflow from on PRI to another switch.  I know for a fact this can be done,
  23731. because I had it done before.  The 800# rotary landed as 800 traffic on
  23732. hardware in four different cities.  Two of those cities had dedicated hardware
  23733. and T1's from the 800 provider (BTI).  The other two POPs were pre-existing
  23734. PRI feed POPs from different telcos (GTE or USLEC, and Bellsouth.)
  23735.  
  23736. I don't know how they did it, but they did charge for the 800# overflow.  The
  23737. only possible difference is the fact that BTI is a LD provider who has
  23738. interconnections with the telcos handling the overflow.  (Personally, I was
  23739. amazed to see BTI get it right the first time. :-) (no offense))
  23740.  
  23741. --Ricky
  23742.  
  23743.  
  23744.  
  23745. -
  23746.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23747.  with "unsubscribe usr-tc" in the body of the message.
  23748.  For information on digests or retrieving files and old messages send
  23749.  "help" to the same address.  Do not use quotes in your message.
  23750.  
  23751.  
  23752. -------------------------------------------------------------------------------
  23753.  
  23754. From: K Mitchell <mitch@keyconn.net>
  23755. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  23756. Date: 19 Mar 1999 01:43:21 -0500
  23757.  
  23758. At 01:05 AM 3/19/99 -0500, Ricky Beam wrote:
  23759. >No.  I got Win3.1 with my computer; does that mean Microsoft should give me
  23760. >a free copy of 95? (or 95->98...)  He didn't buy the radius server, so why
  23761. >should 3Com give away something they've devoted resources to develop?  What
  23762. >kind of problems do you have with 5.5.3?
  23763.  
  23764.   No, I didn't buy it. As I said, it was included with my purchase by
  23765. Source. My understanding is that Source had an agreement with 3Com that
  23766. allowed them to do this for their customers and 3Com discontinued the
  23767. agreement. Personally I feel that I should at least have something that
  23768. works, whether it's upgraded to 6.x.x or not.
  23769.   As for the problems...the only log that works is Event Log. All of the
  23770. other logs either display "error#" under the column headers or they display
  23771. the sample information containing 3 months worth of data from 1995. I've
  23772. gone over the accounting and logging configuration 3 times with support to
  23773. no avail. 5.5.3 is running on NT4/SP4 with Access 98
  23774.  
  23775. Kirk
  23776.  
  23777.  
  23778.  
  23779. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  23780. Keystone Connect                http://www.keyconn.net
  23781. Altoona, PA   814-941-5000         We Unlock the World
  23782.  
  23783.  
  23784. -
  23785.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23786.  with "unsubscribe usr-tc" in the body of the message.
  23787.  For information on digests or retrieving files and old messages send
  23788.  "help" to the same address.  Do not use quotes in your message.
  23789.  
  23790.  
  23791. -------------------------------------------------------------------------------
  23792.  
  23793. From: d baud <dbaud@bigfoot.com>
  23794. Subject: (usr-tc) PPP offloading and NT
  23795. Date: 19 Mar 1999 04:40:45 -0500
  23796.  
  23797. I re-enabled ppp offloading and disabled ppp receive_accm as it is
  23798. recomended in the release notes of 4.1.59-6.
  23799. After doing this, we started receiving a rash of NT people getting
  23800. blocked at the PAP authentication.  Fortunately, this problem can be
  23801. fixed by disabling the LCP Extensions on the NT machine.
  23802.  
  23803. I am planning to disable ppp offloading to avoid this but I need to know
  23804. how bad this will impact the gerneral performance for a chasis with a
  23805. maximum of 4 DSP cards per HiperArc.
  23806.  
  23807. D Baud
  23808.  
  23809. -
  23810.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23811.  with "unsubscribe usr-tc" in the body of the message.
  23812.  For information on digests or retrieving files and old messages send
  23813.  "help" to the same address.  Do not use quotes in your message.
  23814.  
  23815.  
  23816. -------------------------------------------------------------------------------
  23817.  
  23818. From: "Sam Lowe" <slowe@universalcom.net>
  23819. Subject: Re: (usr-tc) PRI to overflow to another telco's PRI ?
  23820. Date: 19 Mar 1999 03:58:30 -0600
  23821.  
  23822. Thia has less to do with technical capabilities and more to do with politics
  23823. and turf.
  23824.  
  23825. The only real way to do this is to bring in your new PRIs and have your
  23826. initial provider call forward all calls to you new PRI number.  Since the
  23827. cut will also be an issue, you will have to have the new PRIs running and
  23828. tested (and believe me there will be a hundred reasons the new ones will
  23829. need to be tested), and then watch for the calls to start dropping and plug
  23830. in the new PRIs.  Once you are up on the new PRIs, then you can have the old
  23831. ones disconnected, but maintain the call forwards on the old number (unless
  23832. you have number portability in your area).
  23833.  
  23834. Over a few months you can get the word out to your customers, and gradually
  23835. reduce the number of call forward paths from the old number.
  23836.  
  23837. -----Original Message-----
  23838.  
  23839.  
  23840. >I am currently trying to switch to another PRI provider, and to do a
  23841. >gradual move of all my PRIs I would need to have my old PRIs to overflow
  23842. >(when busy) to some other PRIs in another Central Office (in the same
  23843. >area code).
  23844. >The two telcos say that it is technically impossible to program this
  23845. >feature on the DMS since it is not in the same Central Office.  Could
  23846. >someone confirm if this is true ?
  23847. >
  23848. >Also, would you say that it would be possible to have the old telco PRI
  23849. >to overflow to a centrex line in the same CO.  And then program the
  23850. >centrex line to forward calls to the phone number of the other PRI of
  23851. >the other telco ?
  23852. >
  23853. >D Baud
  23854. >
  23855. >-
  23856. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23857. > with "unsubscribe usr-tc" in the body of the message.
  23858. > For information on digests or retrieving files and old messages send
  23859. > "help" to the same address.  Do not use quotes in your message.
  23860. >
  23861.  
  23862.  
  23863. -
  23864.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23865.  with "unsubscribe usr-tc" in the body of the message.
  23866.  For information on digests or retrieving files and old messages send
  23867.  "help" to the same address.  Do not use quotes in your message.
  23868.  
  23869.  
  23870. -------------------------------------------------------------------------------
  23871.  
  23872. From: Jeff Mcadams <jeffm@iglou.com>
  23873. Subject: Re: (usr-tc) HyperARC needs a regular reboot?
  23874. Date: 19 Mar 1999 07:35:12 -0500 (EST)
  23875.  
  23876. Thus spake Ricky Beam
  23877. >On Thu, 18 Mar 1999, Jeff Mcadams wrote:
  23878. >>Gee...can I connect this back to my "3Com Problems" thread from last
  23879. >>week or so?  Sounds like much the same situation, and screw the customer
  23880. >>even though 3Com didn't deliver what they promised attitude that we're
  23881. >>*still* fighting with 3Com.
  23882.  
  23883. >No.  I got Win3.1 with my computer; does that mean Microsoft should give me
  23884. >a free copy of 95? (or 95->98...)  He didn't buy the radius server, so why
  23885. >should 3Com give away something they've devoted resources to develop?  What
  23886. >kind of problems do you have with 5.5.3?
  23887.  
  23888. Geez...you're just not getting it.  Its not an issue of upgrading from
  23889. one product that works to another better product that works.  Its an
  23890. issue of being sold a product that doesn't work, and then being told to
  23891. get a fix you have to pay more money for a different product.  Its bait
  23892. and switch and its illegal.
  23893. -- 
  23894. Jeff McAdams                            Email: jeffm@iglou.com
  23895. Head Network Administrator              Voice: (502) 966-3848
  23896. IgLou Internet Services                        (800) 436-4456
  23897.  
  23898. -
  23899.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23900.  with "unsubscribe usr-tc" in the body of the message.
  23901.  For information on digests or retrieving files and old messages send
  23902.  "help" to the same address.  Do not use quotes in your message.
  23903.  
  23904.  
  23905. -------------------------------------------------------------------------------
  23906.  
  23907. From: jeff.binkley@asacomp.com (Jeff Binkley)
  23908. Subject: (usr-tc) RE: (USR-TC) HYPERARC NEE
  23909. Date: 19 Mar 1999 08:45:00 -0500
  23910.  
  23911.  
  23912.  
  23913.  
  23914. Anyone know why 6.0.9 isn't freely downloadable since it is called a 
  23915. service release ?  Just wondering.
  23916.  
  23917. Jeff Binkley
  23918. ASA Network Computing
  23919.  
  23920.  
  23921. U>upgrade to 6.0.9.  5.3.3 is very old.  3com said 6.0.9 is 
  23922. U>backward compatible with all ARC releases.  hard to believe
  23923. U>but... (can't find the Software Compatibility Matrix to
  23924. U>verify).
  23925.  
  23926. U>blake
  23927.  
  23928. U>> -----Original Message-----
  23929. U>> From: K Mitchell [mailto:mitch@keyconn.net]
  23930. U>> Sent: Thursday, March 18, 1999 4:13 PM
  23931. U>> To: usr-tc@lists.xmission.com
  23932. U>> Subject: RE: (usr-tc) HyperARC needs a regular reboot?
  23933.  
  23934.  
  23935. U>> At 11:54 AM 3/18/99 +0100, Robert von Bismarck wrote:
  23936. U>> >Sound like the dreaded 4.1.72-7 memory leak on the ARC. This 
  23937. U>> is probably
  23938. U>> >coming from MPIP. There's only one solution : upgrade your code
  23939.  
  23940. U>> I know this is a bit far-fetched but; I haven't had any 
  23941. U>> problems with my
  23942. U>> ARC console connection but, I've recently seen S&A Server sucking up
  23943. U>> increasing amounts of memory, requiring a restart every 
  23944. U>> couple of days. I'm
  23945. U>> running;
  23946. U>> S&A Server 5.5.3 on NT 4
  23947. U>> ARC 4.1.72
  23948.  
  23949. U>> Kirk
  23950.  
  23951.  
  23952.  
  23953. U>> Kirk Mitchell-General Manager     sysadmin@keyconn.net
  23954. U>> Keystone Connect                http://www.keyconn.net
  23955. U>> Altoona, PA   814-941-5000         We Unlock the World
  23956.  
  23957.  
  23958. U>> -
  23959. U>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23960. U>>  with "unsubscribe usr-tc" in the body of the message.
  23961. U>>  For information on digests or retrieving files and old messages
  23962. U>>  send "help" to the same address.  Do not use quotes in your
  23963. U>> message. 
  23964.  
  23965.  
  23966. U>-
  23967. U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23968. U> with "unsubscribe usr-tc" in the body of the message.
  23969. U> For information on digests or retrieving files and old messages send
  23970. U> "help" to the same address.  Do not use quotes in your message.
  23971.  
  23972. U>          
  23973.  
  23974. CMPQwk 1.42 9999
  23975.  
  23976. -
  23977.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  23978.  with "unsubscribe usr-tc" in the body of the message.
  23979.  For information on digests or retrieving files and old messages send
  23980.  "help" to the same address.  Do not use quotes in your message.
  23981.  
  23982.  
  23983. -------------------------------------------------------------------------------
  23984.  
  23985. From: jeff.binkley@asacomp.com (Jeff Binkley)
  23986. Subject: (usr-tc) RE: (USR-TC) SINCE HIPERA
  23987. Date: 19 Mar 1999 08:45:00 -0500
  23988.  
  23989.  
  23990.  
  23991.  
  23992. Krish,
  23993.  
  23994. Note he has Preferred set to PAP which may be a problem with Quads as 
  23995. you and I discovered the other day.
  23996.  
  23997. Jeff Binkley
  23998. ASA Network Computing
  23999.  
  24000.  
  24001. U>On Thu, 18 Mar 1999, Mike Hamrich wrote:
  24002.  
  24003. U>> OK HiperArc with latest code 3/4/99
  24004.  
  24005. U>I assume that you now have HiPer arc 4.1.59 -6 code.  
  24006. U>What is the DSP code that you have?
  24007.  
  24008. U>> Since the "upgrade" we are having tons of connection issues.
  24009. U>> Couriers can't connect
  24010. U>> Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  24011. U>> OEM/Brown box Sportsters can't stay connected
  24012.  
  24013. U>> We also told owner of non X2 modem to go elsewere.
  24014.  
  24015. U>> We surveyed our users, 248 replied so far:
  24016. U>> 67% say slower speed, 22% are having problems saying connected, 4%
  24017. U>> can't connect at all, and ONLY 7%  report better connection.
  24018.  
  24019. U>> We have PRI lines, Set PPP offloading to no, Authenticate ANY
  24020. U>> Preferrd PAP
  24021.  
  24022. U>If look at the release notes for this - There is a clear mention to
  24023. U>set PPP offloading to enable  and also to disable ppp receive_accm
  24024.  
  24025.  
  24026.  
  24027. U>> Any other ideas to make this stuff work as well as the old stuff
  24028. U>did?
  24029.  
  24030.  
  24031. U>Set the PPP off loading to enable
  24032.  
  24033. U>enable ppp offloading
  24034. U>that should help you a lot.
  24035.  
  24036. U>Also need to know the version of DSP code
  24037.  
  24038. U>regards
  24039. U>krish
  24040.  
  24041. U>> Thanks in advance for you help
  24042.  
  24043. U>> Mike Hamrich
  24044. U>> CIO, DrFast.Net, Inc.
  24045. U>> (216) 797-1040
  24046.  
  24047.  
  24048. U>> -
  24049. U>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24050. U>>  with "unsubscribe usr-tc" in the body of the message.
  24051. U>>  For information on digests or retrieving files and old messages
  24052. U>>  send "help" to the same address.  Do not use quotes in your
  24053. U>> message. 
  24054.  
  24055.  
  24056. U>-
  24057. U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24058. U> with "unsubscribe usr-tc" in the body of the message.
  24059. U> For information on digests or retrieving files and old messages send
  24060. U> "help" to the same address.  Do not use quotes in your message.
  24061.  
  24062. U>                                                            
  24063.  
  24064. CMPQwk 1.42 9999
  24065.  
  24066. -
  24067.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24068.  with "unsubscribe usr-tc" in the body of the message.
  24069.  For information on digests or retrieving files and old messages send
  24070.  "help" to the same address.  Do not use quotes in your message.
  24071.  
  24072.  
  24073. -------------------------------------------------------------------------------
  24074.  
  24075. From: jeff.binkley@asacomp.com (Jeff Binkley)
  24076. Subject: Re: (usr-tc) HyperARC nee
  24077. Date: 19 Mar 1999 08:45:00 -0500
  24078.  
  24079.  
  24080.  
  24081. Ricky,
  24082.  
  24083. I would tend to agree with you but I think the concept of version levels 
  24084. vs service packs/releases needs to be brought into play.  You can 
  24085. download patches for free from MS for Windows 3.1 and Windows 95, 
  24086. however you can download Windows 95 freely to install over 3.1.  Now how 
  24087. 3Com would manage this remains to be seen.  For instance a 6.0.8 user 
  24088. should be able to freely download the SR 6.0.9 but they can't.  The 
  24089. problem is if 3Com makes 6.0.9 freely downloadable without some way for 
  24090. the installation routine to verify the release levels then everyone can 
  24091. upgrae by pulling down the SR.  It's not an insurrmoutnable problem, 
  24092. just one which hasn't been addressed.
  24093.  
  24094. Jeff Binkley
  24095. ASA Network Computing
  24096.  
  24097.  
  24098. u>On Thu, 18 Mar 1999, Jeff Mcadams wrote:
  24099. u>>Gee...can I connect this back to my "3Com Problems" thread from last
  24100. u>>week or so?  Sounds like much the same situation, and screw the
  24101. u>customer >even though 3Com didn't deliver what they promised attitude
  24102. u>that we're >*still* fighting with 3Com.
  24103.  
  24104. u>No.  I got Win3.1 with my computer; does that mean Microsoft should
  24105. u>give me a free copy of 95? (or 95->98...)  He didn't buy the radius
  24106. u>server, so why should 3Com give away something they've devoted
  24107. u>resources to develop?  What kind of problems do you have with 5.5.3?
  24108.  
  24109. u>--Ricky
  24110.  
  24111.  
  24112.  
  24113. u>-
  24114. u> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24115. u> with "unsubscribe usr-tc" in the body of the message.
  24116. u> For information on digests or retrieving files and old messages send
  24117. u> "help" to the same address.  Do not use quotes in your message.
  24118.  
  24119. u>                
  24120.  
  24121. CMPQwk 1.42 9999
  24122.  
  24123. -
  24124.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24125.  with "unsubscribe usr-tc" in the body of the message.
  24126.  For information on digests or retrieving files and old messages send
  24127.  "help" to the same address.  Do not use quotes in your message.
  24128.  
  24129.  
  24130. -------------------------------------------------------------------------------
  24131.  
  24132. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  24133. Subject: RE: (usr-tc) PPP offloading and NT
  24134. Date: 19 Mar 1999 08:05:41 -0600
  24135.  
  24136.  
  24137.  
  24138. |-----Original Message-----
  24139. |From: owner-usr-tc@lists.xmission.com
  24140. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of d baud
  24141. |Sent: Friday, March 19, 1999 3:41 AM
  24142. |To: usr-tc@lists.xmission.com
  24143. |Subject: (usr-tc) PPP offloading and NT
  24144. |
  24145. |
  24146. |I re-enabled ppp offloading and disabled ppp receive_accm as it is
  24147. |recomended in the release notes of 4.1.59-6.
  24148. |After doing this, we started receiving a rash of NT people getting
  24149. |blocked at the PAP authentication.  Fortunately, this problem can be
  24150. |fixed by disabling the LCP Extensions on the NT machine.
  24151. |
  24152. |I am planning to disable ppp offloading to avoid this but I need to know
  24153. |how bad this will impact the gerneral performance for a chasis with a
  24154. |maximum of 4 DSP cards per HiperArc.
  24155. |
  24156.  
  24157. You should leave the settings as sugested in the release notes. NT has its own
  24158. problems, not the TCH. NT should have failed reguardless of the offloading
  24159. setting. If you dissable PPP offloading you may run back into the "WebRamp"/PAP
  24160. issues.
  24161.  
  24162. -M
  24163.  
  24164.  
  24165. -
  24166.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24167.  with "unsubscribe usr-tc" in the body of the message.
  24168.  For information on digests or retrieving files and old messages send
  24169.  "help" to the same address.  Do not use quotes in your message.
  24170.  
  24171.  
  24172. -------------------------------------------------------------------------------
  24173.  
  24174. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  24175. Subject: (usr-tc) modem configs
  24176. Date: 19 Mar 1999 09:19:22 -0500 (EST)
  24177.  
  24178.  
  24179. So...no comments regarding connect-with-anything modem strings?
  24180.  
  24181. Did my last message even go out on the list?
  24182.  
  24183.  
  24184.  
  24185. -
  24186.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24187.  with "unsubscribe usr-tc" in the body of the message.
  24188.  For information on digests or retrieving files and old messages send
  24189.  "help" to the same address.  Do not use quotes in your message.
  24190.  
  24191.  
  24192. -------------------------------------------------------------------------------
  24193.  
  24194. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  24195. Subject: Re: (usr-tc) RE: (USR-TC) SINCE HIPERA
  24196. Date: 19 Mar 1999 09:31:01 -0600 (CST)
  24197.  
  24198. On Fri, 19 Mar 1999, Jeff Binkley wrote:
  24199.  
  24200. > 
  24201. > 
  24202. > 
  24203. > Krish,
  24204. > 
  24205. > Note he has Preferred set to PAP which may be a problem with Quads as 
  24206. > you and I discovered the other day.
  24207. > 
  24208.  
  24209. Well he is using DSP for the most part and also he is complaing about 
  24210. speed and through put.  Disabling ppp offloading does slow down the 
  24211. throughput to a good extent.  I have not heard from him and I also 
  24212. offered to work with him to find out if he has the quad or the DSP, no 
  24213. answer from him yet.
  24214.  
  24215. thanks
  24216.  
  24217. krish
  24218.  
  24219.  
  24220. > Jeff Binkley
  24221. > ASA Network Computing
  24222. > 
  24223. > 
  24224. > U>On Thu, 18 Mar 1999, Mike Hamrich wrote:
  24225. > 
  24226. > U>> OK HiperArc with latest code 3/4/99
  24227. > 
  24228. > U>I assume that you now have HiPer arc 4.1.59 -6 code.  
  24229. > U>What is the DSP code that you have?
  24230. > 
  24231. > U>> Since the "upgrade" we are having tons of connection issues.
  24232. > U>> Couriers can't connect
  24233. > U>> Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  24234. > U>> OEM/Brown box Sportsters can't stay connected
  24235. > 
  24236. > U>> We also told owner of non X2 modem to go elsewere.
  24237. > 
  24238. > U>> We surveyed our users, 248 replied so far:
  24239. > U>> 67% say slower speed, 22% are having problems saying connected, 4%
  24240. > U>> can't connect at all, and ONLY 7%  report better connection.
  24241. > 
  24242. > U>> We have PRI lines, Set PPP offloading to no, Authenticate ANY
  24243. > U>> Preferrd PAP
  24244. > 
  24245. > U>If look at the release notes for this - There is a clear mention to
  24246. > U>set PPP offloading to enable  and also to disable ppp receive_accm
  24247. > 
  24248. > 
  24249. > 
  24250. > U>> Any other ideas to make this stuff work as well as the old stuff
  24251. > U>did?
  24252. > 
  24253. > 
  24254. > U>Set the PPP off loading to enable
  24255. > 
  24256. > U>enable ppp offloading
  24257. > U>that should help you a lot.
  24258. > 
  24259. > U>Also need to know the version of DSP code
  24260. > 
  24261. > U>regards
  24262. > U>krish
  24263. > 
  24264. > U>> Thanks in advance for you help
  24265. > 
  24266. > U>> Mike Hamrich
  24267. > U>> CIO, DrFast.Net, Inc.
  24268. > U>> (216) 797-1040
  24269. > 
  24270. > 
  24271. > U>> -
  24272. > U>>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24273. > U>>  with "unsubscribe usr-tc" in the body of the message.
  24274. > U>>  For information on digests or retrieving files and old messages
  24275. > U>>  send "help" to the same address.  Do not use quotes in your
  24276. > U>> message. 
  24277. > 
  24278. > 
  24279. > U>-
  24280. > U> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24281. > U> with "unsubscribe usr-tc" in the body of the message.
  24282. > U> For information on digests or retrieving files and old messages send
  24283. > U> "help" to the same address.  Do not use quotes in your message.
  24284. > 
  24285. > U>                                                            
  24286. > 
  24287. > CMPQwk 1.42 9999
  24288. > 
  24289. > -
  24290. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24291. >  with "unsubscribe usr-tc" in the body of the message.
  24292. >  For information on digests or retrieving files and old messages send
  24293. >  "help" to the same address.  Do not use quotes in your message.
  24294. > 
  24295.  
  24296. -
  24297.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24298.  with "unsubscribe usr-tc" in the body of the message.
  24299.  For information on digests or retrieving files and old messages send
  24300.  "help" to the same address.  Do not use quotes in your message.
  24301.  
  24302.  
  24303. -------------------------------------------------------------------------------
  24304.  
  24305. From: Randy Cosby <dcosby@infowest.com>
  24306. Subject: (usr-tc) t1/pri cards
  24307. Date: 19 Mar 1999 08:55:20 -0700 (MST)
  24308.  
  24309. Now that we're all trading our quads for HiperDSP's, what can we do with our T1 cards?  Is
  24310. there a way to use those t1 ports for frame relay?  I don't see a way to do it, but maybe
  24311. I'm missing something.  Hate to just waste good hardware.
  24312.  
  24313.  
  24314. -
  24315.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24316.  with "unsubscribe usr-tc" in the body of the message.
  24317.  For information on digests or retrieving files and old messages send
  24318.  "help" to the same address.  Do not use quotes in your message.
  24319.  
  24320.  
  24321. -------------------------------------------------------------------------------
  24322.  
  24323. From: Mike Andrews <mandrews@termfrost.org>
  24324. Subject: Re: (usr-tc) modem configs
  24325. Date: 19 Mar 1999 11:10:00 -0500 (EST)
  24326.  
  24327. Your message made it. :)  My excuse is "vacation", but I'm going to try
  24328. it later today...  thanks for the rundown, this'll be a BIG help...
  24329.  
  24330. Why disable the 2100hz answer tone?  What does this gain you?
  24331.  
  24332.  
  24333. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  24334. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  24335. getting beaten by the police, put down the video camera and come help me!"
  24336.  
  24337. On Fri, 19 Mar 1999, Lon R. Stockton, Jr. wrote:
  24338.  
  24339. > So...no comments regarding connect-with-anything modem strings?
  24340. > 
  24341. > Did my last message even go out on the list?
  24342.  
  24343.  
  24344.  
  24345. -
  24346.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24347.  with "unsubscribe usr-tc" in the body of the message.
  24348.  For information on digests or retrieving files and old messages send
  24349.  "help" to the same address.  Do not use quotes in your message.
  24350.  
  24351.  
  24352. -------------------------------------------------------------------------------
  24353.  
  24354. From: Brian <signal@shreve.net>
  24355. Subject: (usr-tc) dead arc
  24356. Date: 19 Mar 1999 10:44:12 -0600 (EST)
  24357.  
  24358. I have two arcs that when I boot them, the rn/fl light is just solid red.
  24359. I get no BOOT PROM banner at any speed.
  24360.  
  24361. I have set SW5 and tried to boot but that does not work.  What is the next
  24362. step in getting these cards to a point where I can work with them?  Any
  24363. more SW's I can set etc?
  24364.  
  24365. Brian
  24366.  
  24367.  
  24368. Brian Feeny (BF304)     signal@shreve.net   
  24369. 318-222-2638 x 109    http://www.shreve.net/~signal      
  24370. Network Administrator   ShreveNet Inc. (ASN 11881)           
  24371.  
  24372.  
  24373. -
  24374.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24375.  with "unsubscribe usr-tc" in the body of the message.
  24376.  For information on digests or retrieving files and old messages send
  24377.  "help" to the same address.  Do not use quotes in your message.
  24378.  
  24379.  
  24380. -------------------------------------------------------------------------------
  24381.  
  24382. From: Ricky Beam <jfbeam@beaker.interpath.net>
  24383. Subject: Re: (usr-tc) HyperARC nee
  24384. Date: 19 Mar 1999 12:15:28 -0500 (EST)
  24385.  
  24386. On Fri, 19 Mar 1999, Jeff Binkley wrote:
  24387. >I would tend to agree with you but I think the concept of version levels 
  24388. >vs service packs/releases needs to be brought into play.  You can 
  24389.  
  24390. Not to mention confusing...
  24391.  
  24392. >3Com would manage this remains to be seen.  For instance a 6.0.8 user 
  24393. >should be able to freely download the SR 6.0.9 but they can't.  The 
  24394. >problem is if 3Com makes 6.0.9 freely downloadable without some way for 
  24395. >the installation routine to verify the release levels then everyone can 
  24396. >upgrae by pulling down the SR.  It's not an insurrmoutnable problem, 
  24397. >just one which hasn't been addressed.
  24398.  
  24399. I have pointed that out to them before.  They need a method of "patching" the
  24400. binary files -- something like the redhat "rhmask" files...
  24401.  
  24402. I alays had someone mail me the files I had to have.  I was fortunate enough
  24403. to have source code access to SA4 and then SA6, so as soon as I'd get the
  24404. source, I didn't care what 3Com was up to anymore aside from sending bug
  24405. patches back to them (I hope they paid attention to them since the NDA
  24406. required me to destroy the source when I left Interpath.)
  24407.  
  24408. --Ricky
  24409.  
  24410.  
  24411.  
  24412. -
  24413.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24414.  with "unsubscribe usr-tc" in the body of the message.
  24415.  For information on digests or retrieving files and old messages send
  24416.  "help" to the same address.  Do not use quotes in your message.
  24417.  
  24418.  
  24419. -------------------------------------------------------------------------------
  24420.  
  24421. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  24422. Subject: Re: (usr-tc) modem configs
  24423. Date: 19 Mar 1999 12:45:23 -0500 (EST)
  24424.  
  24425.  
  24426.  
  24427. On Fri, 19 Mar 1999, Mike Andrews wrote:
  24428.  
  24429. > Your message made it. :)  My excuse is "vacation", but I'm going to try
  24430. > it later today...  thanks for the rundown, this'll be a BIG help...
  24431.  
  24432. No problem, glad to help if it indeed does. (:   But what's a 'vacation'?
  24433.  
  24434. > Why disable the 2100hz answer tone?  What does this gain you?
  24435.  
  24436. I was in a quick scan mode looking for stuff to turn off. (: According
  24437. to the dox, some older 2400 modems didn't recognize it, and it allows
  24438. v42 modems to connect more quickly. On the other hand, it doesn't say
  24439. what it's for and what I'm losing by turning it off, so more research
  24440. is indicated on that....or perchance an authoritative post from someone
  24441. here... (:
  24442.  
  24443.  
  24444.  
  24445. -
  24446.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24447.  with "unsubscribe usr-tc" in the body of the message.
  24448.  For information on digests or retrieving files and old messages send
  24449.  "help" to the same address.  Do not use quotes in your message.
  24450.  
  24451.  
  24452. -------------------------------------------------------------------------------
  24453.  
  24454. From: Jeff Mcadams <jeffm@iglou.com>
  24455. Subject: Re: (usr-tc) modem configs
  24456. Date: 19 Mar 1999 12:58:41 -0500 (EST)
  24457.  
  24458. Thus spake Lon R. Stockton, Jr.
  24459. >On Fri, 19 Mar 1999, Mike Andrews wrote:
  24460. >> Why disable the 2100hz answer tone?  What does this gain you?
  24461.  
  24462. >I was in a quick scan mode looking for stuff to turn off. (: According
  24463. >to the dox, some older 2400 modems didn't recognize it, and it allows
  24464. >v42 modems to connect more quickly. On the other hand, it doesn't say
  24465. >what it's for and what I'm losing by turning it off, so more research
  24466. >is indicated on that....or perchance an authoritative post from someone
  24467. >here... (:
  24468.  
  24469. I actually saw this mentioned recently somewhere.
  24470.  
  24471. The telephone companies use echo cancellers (sp?) in their network
  24472. to...cancel echos...(duh) so you don't hear yourself talking when you
  24473. talk on the phone.  Basically, modems take care of this
  24474. themselves...well...at least they're *supposed* to, and the telco echo
  24475. cancellers screw up the connection, so the 2100hz tone for approximately
  24476. 1 sec will turn off any echo cancellers that the telcos provide on the
  24477. lines, letting the modems do their own things in that department.
  24478. -- 
  24479. Jeff McAdams                            Email: jeffm@iglou.com
  24480. Head Network Administrator              Voice: (502) 966-3848
  24481. IgLou Internet Services                        (800) 436-4456
  24482.  
  24483. -
  24484.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24485.  with "unsubscribe usr-tc" in the body of the message.
  24486.  For information on digests or retrieving files and old messages send
  24487.  "help" to the same address.  Do not use quotes in your message.
  24488.  
  24489.  
  24490. -------------------------------------------------------------------------------
  24491.  
  24492. From: Pete Ashdown <pashdown@xmission.com>
  24493. Subject: (usr-tc) MacPPP failures on 4.1.59-6
  24494. Date: 19 Mar 1999 11:03:13 -0700 (MST)
  24495.  
  24496. We're still having numerous MacPPP failures under 4.1.59-6.  Catching your
  24497. request in advance Krish, here's the hex dump output of one such failure.
  24498. Please note that I changed the user name and password, and XX'd the hex for
  24499. the password.
  24500.  
  24501. Decode tracing started, press ESCAPE to stop; press X for hex tracing.
  24502. Tracing changed to hex dumps; press Escape to stop; press D for decode tracing.
  24503.  
  24504. Outgoing PPP Data on interface: slot:11/mod:14 
  24505.     c0 23 02 01 00 05 00                            | #              |
  24506.  
  24507.  
  24508. Outgoing PPP Data on interface: slot:11/mod:14 
  24509.     80 21 01 04 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24510.     01 15                                           |                |
  24511.  
  24512.  
  24513. Outgoing PPP Data on interface: slot:11/mod:14 
  24514.     80 21 01 05 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24515.     01 15                                           |                |
  24516.  
  24517.  
  24518. Outgoing PPP Data on interface: slot:11/mod:14 
  24519.     80 21 01 06 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24520.     01 15                                           |                |
  24521.  
  24522.  
  24523. Incoming PPP Data on interface: slot:11/mod:14 
  24524.     c0 23 01 03 00 14 08 6c 6f 73 74 63 68 6c 64 06 | #     username |
  24525.     XX XX XX XX XX XX                               |SEKRET          |
  24526.  
  24527.  
  24528. Outgoing PPP Data on interface: slot:11/mod:14 
  24529.     80 21 01 07 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24530.     01 15                                           |                |
  24531.  
  24532.  
  24533. Incoming PPP Data on interface: slot:11/mod:14 
  24534.     c0 23 01 04 00 14 08 6c 6f 73 74 63 68 6c 64 06 | #     username |
  24535.     XX XX XX XX XX XX                               |SEKRET          |
  24536.  
  24537.  
  24538. Outgoing PPP Data on interface: slot:11/mod:14 
  24539.     80 fd 01 08 00 15 12 06 00 00 00 01 11 05 00 00 |                |
  24540.     03 11 06 00 00 01 01                            |                |
  24541.  
  24542.  
  24543. Incoming PPP Data on interface: slot:11/mod:14 
  24544.     ff 03 c0 21 08 05 00 1b 80 fd 01 08 00 15 12 06 |   !            |
  24545.     00 00 00 01 11 05 00 00 03 11 06 00 00 01 01    |                |
  24546.  
  24547.  
  24548. Outgoing PPP Data on interface: slot:11/mod:14 
  24549.     80 21 01 09 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24550.     01 15                                           |                |
  24551.  
  24552.  
  24553. Incoming PPP Data on interface: slot:11/mod:14 
  24554.     ff 03 c0 21 05 06 00 04                         |   !            |
  24555.  
  24556.  
  24557. Outgoing PPP Data on interface: slot:11/mod:14 
  24558.     ff 03 c0 21 06 06 00 04                         |   !            |
  24559.  
  24560. (hangup)
  24561.  
  24562. -
  24563.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24564.  with "unsubscribe usr-tc" in the body of the message.
  24565.  For information on digests or retrieving files and old messages send
  24566.  "help" to the same address.  Do not use quotes in your message.
  24567.  
  24568.  
  24569. -------------------------------------------------------------------------------
  24570.  
  24571. From: "Matt Harper" <Matt_Harper@mw.3com.com>
  24572. Subject: Re: (usr-tc) dead arc
  24573. Date: 19 Mar 1999 12:15:12 -0600
  24574.  
  24575.  
  24576.  
  24577.  
  24578. If the HARC is not giving a BOOT PROMPT on the console prompt or a Debug Port
  24579. OKAY on the Debug Port then 1 of 4 things has been broken:
  24580.  
  24581.    If the system on power up goes from Red to green and then to Red, then your
  24582.    memory controller/DRAM DIMM is defective, try replacing the DIMM with another
  24583.    and see if the problem disappears.
  24584.    The 16C550 UART fails diagnostics.
  24585.    One of the 2 UART ports on the 2692 fails diagnostics.
  24586.    The Real-Time clock fails diagnostics.
  24587.  
  24588. The only way to find out which of these things has been broken is to set
  24589. DipSwitch 10 ON and reinsert the card.  When you do this it will perform a
  24590. complete memory test(inprogress when the LEDs rotate orange).  After it finishes
  24591. it will then test the 3 UART ports, configure the 3 UART ports and then test the
  24592. Real-Time Clock.  It uses LEDs 5 6 7(from the top) to indicate status, if any of
  24593. them go RED then it has failed diagnostics and the board is toast and must be
  24594. replaced.
  24595.  
  24596. Get a cup of coffee prior to starting this test and pay careful attention to the
  24597. LEDs because they get reset fairly fast.
  24598.  
  24599.  
  24600. -- Matt
  24601.  
  24602.  
  24603.  
  24604.  
  24605.  
  24606. Brian <signal@shreve.net> on 03/19/99 10:44:12 AM
  24607.  
  24608. Please respond to usr-tc@lists.xmission.com
  24609.  
  24610. cc:    (Matt Harper/MW/US/3Com)
  24611.  
  24612.  
  24613.  
  24614.  
  24615. I have two arcs that when I boot them, the rn/fl light is just solid red.
  24616. I get no BOOT PROM banner at any speed.
  24617.  
  24618. I have set SW5 and tried to boot but that does not work.  What is the next
  24619. step in getting these cards to a point where I can work with them?  Any
  24620. more SW's I can set etc?
  24621.  
  24622. Brian
  24623.  
  24624.  
  24625. Brian Feeny (BF304)     signal@shreve.net
  24626. 318-222-2638 x 109  http://www.shreve.net/~signal
  24627. Network Administrator   ShreveNet Inc. (ASN 11881)
  24628.  
  24629.  
  24630. -
  24631.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24632.  with "unsubscribe usr-tc" in the body of the message.
  24633.  For information on digests or retrieving files and old messages send
  24634.  "help" to the same address.  Do not use quotes in your message.
  24635.  
  24636.  
  24637.  
  24638.  
  24639.  
  24640.  
  24641.  
  24642.  
  24643. -
  24644.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24645.  with "unsubscribe usr-tc" in the body of the message.
  24646.  For information on digests or retrieving files and old messages send
  24647.  "help" to the same address.  Do not use quotes in your message.
  24648.  
  24649.  
  24650. -------------------------------------------------------------------------------
  24651.  
  24652. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  24653. Subject: Re: (usr-tc) MacPPP failures on 4.1.59-6
  24654. Date: 19 Mar 1999 12:32:30 -0600 (CST)
  24655.  
  24656. On Fri, 19 Mar 1999, Pete Ashdown wrote:
  24657.  
  24658. > We're still having numerous MacPPP failures under 4.1.59-6.  Catching your
  24659. > request in advance Krish, here's the hex dump output of one such failure.
  24660. > Please note that I changed the user name and password, and XX'd the hex for
  24661. > the password.
  24662.  
  24663. This is with DSP code ?? 
  24664. Are you also using Quad here?
  24665.  
  24666. Also is it safe to say that disabling ppp offloading does resolve this 
  24667. problem?
  24668.  
  24669. krish
  24670.  
  24671.  
  24672. > 
  24673. > Decode tracing started, press ESCAPE to stop; press X for hex tracing.
  24674. > Tracing changed to hex dumps; press Escape to stop; press D for decode tracing.
  24675. > 
  24676. > Outgoing PPP Data on interface: slot:11/mod:14 
  24677. >     c0 23 02 01 00 05 00                            | #              |
  24678. > 
  24679. > 
  24680. > Outgoing PPP Data on interface: slot:11/mod:14 
  24681. >     80 21 01 04 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24682. >     01 15                                           |                |
  24683. > 
  24684. > 
  24685. > Outgoing PPP Data on interface: slot:11/mod:14 
  24686. >     80 21 01 05 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24687. >     01 15                                           |                |
  24688. > 
  24689. > 
  24690. > Outgoing PPP Data on interface: slot:11/mod:14 
  24691. >     80 21 01 06 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24692. >     01 15                                           |                |
  24693. > 
  24694. > 
  24695. > Incoming PPP Data on interface: slot:11/mod:14 
  24696. >     c0 23 01 03 00 14 08 6c 6f 73 74 63 68 6c 64 06 | #     username |
  24697. >     XX XX XX XX XX XX                               |SEKRET          |
  24698. > 
  24699. > 
  24700. > Outgoing PPP Data on interface: slot:11/mod:14 
  24701. >     80 21 01 07 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24702. >     01 15                                           |                |
  24703. > 
  24704. > 
  24705. > Incoming PPP Data on interface: slot:11/mod:14 
  24706. >     c0 23 01 04 00 14 08 6c 6f 73 74 63 68 6c 64 06 | #     username |
  24707. >     XX XX XX XX XX XX                               |SEKRET          |
  24708. > 
  24709. > 
  24710. > Outgoing PPP Data on interface: slot:11/mod:14 
  24711. >     80 fd 01 08 00 15 12 06 00 00 00 01 11 05 00 00 |                |
  24712. >     03 11 06 00 00 01 01                            |                |
  24713. > 
  24714. > 
  24715. > Incoming PPP Data on interface: slot:11/mod:14 
  24716. >     ff 03 c0 21 08 05 00 1b 80 fd 01 08 00 15 12 06 |   !            |
  24717. >     00 00 00 01 11 05 00 00 03 11 06 00 00 01 01    |                |
  24718. > 
  24719. > 
  24720. > Outgoing PPP Data on interface: slot:11/mod:14 
  24721. >     80 21 01 09 00 10 02 06 00 2d 0f 00 03 06 a6 46 | !       -     F|
  24722. >     01 15                                           |                |
  24723. > 
  24724. > 
  24725. > Incoming PPP Data on interface: slot:11/mod:14 
  24726. >     ff 03 c0 21 05 06 00 04                         |   !            |
  24727. > 
  24728. > 
  24729. > Outgoing PPP Data on interface: slot:11/mod:14 
  24730. >     ff 03 c0 21 06 06 00 04                         |   !            |
  24731. > 
  24732. > (hangup)
  24733. > 
  24734. > -
  24735. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24736. >  with "unsubscribe usr-tc" in the body of the message.
  24737. >  For information on digests or retrieving files and old messages send
  24738. >  "help" to the same address.  Do not use quotes in your message.
  24739. > 
  24740.  
  24741. -
  24742.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24743.  with "unsubscribe usr-tc" in the body of the message.
  24744.  For information on digests or retrieving files and old messages send
  24745.  "help" to the same address.  Do not use quotes in your message.
  24746.  
  24747.  
  24748. -------------------------------------------------------------------------------
  24749.  
  24750. From: "Michael E. Ezzell" <mezzell@networkacg.com>
  24751. Subject: RE: (usr-tc) modem configs
  24752. Date: 19 Mar 1999 12:18:00 -0600
  24753.  
  24754.  
  24755.  
  24756. > -----Original Message-----
  24757. > From: Jeff Mcadams [mailto:jeffm@iglou.com]
  24758. > Sent: Friday, March 19, 1999 11:59 AM
  24759. > To: usr-tc@lists.xmission.com
  24760. > Subject: Re: (usr-tc) modem configs
  24761. > 
  24762.  
  24763. > I actually saw this mentioned recently somewhere.
  24764. > > The telephone companies use echo cancellers (sp?) in their network
  24765. > to...cancel echos...(duh) so you don't hear yourself talking when you
  24766. > talk on the phone.  Basically, modems take care of this
  24767. > themselves...well...at least they're *supposed* to, and the telco echo
  24768. > cancellers screw up the connection, so the 2100hz tone for 
  24769. > approximately
  24770. > 1 sec will turn off any echo cancellers that the telcos provide on the
  24771. > lines, letting the modems do their own things in that department.
  24772.  
  24773. This is accurate info... the echo cancellers munge the data streams by
  24774. inserting silence when an echo condition is detected... this makes sense for
  24775. speech but will kill data (or at least, make it very sick).  However, "echo
  24776. cans" are usually only deployed on long distance networks, so if you aren't
  24777. taking inbound toll or 800 calls, you probably could disable this and still
  24778. function.  Never tried it.
  24779.  
  24780. -
  24781.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24782.  with "unsubscribe usr-tc" in the body of the message.
  24783.  For information on digests or retrieving files and old messages send
  24784.  "help" to the same address.  Do not use quotes in your message.
  24785.  
  24786.  
  24787. -------------------------------------------------------------------------------
  24788.  
  24789. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  24790. Subject: (usr-tc) 2100hz answer tone
  24791. Date: 19 Mar 1999 13:25:13 -0500 (EST)
  24792.  
  24793.  
  24794. On Fri, 19 Mar 1999, Jeff Mcadams wrote:
  24795.  
  24796. > Thus spake Lon R. Stockton, Jr.
  24797. > >On Fri, 19 Mar 1999, Mike Andrews wrote:
  24798. > >> Why disable the 2100hz answer tone?  What does this gain you?
  24799. > 
  24800. > >I was in a quick scan mode looking for stuff to turn off. (: According
  24801. > >to the dox, some older 2400 modems didn't recognize it, and it allows
  24802. > >v42 modems to connect more quickly. On the other hand, it doesn't say
  24803. > >what it's for and what I'm losing by turning it off, so more research
  24804. > >is indicated on that....or perchance an authoritative post from someone
  24805. > >here... (:
  24806. > 
  24807. > I actually saw this mentioned recently somewhere.
  24808. > 
  24809. > The telephone companies use echo cancellers (sp?) in their network
  24810. > to...cancel echos...(duh) so you don't hear yourself talking when you
  24811. > talk on the phone.  Basically, modems take care of this
  24812. > themselves...well...at least they're *supposed* to, and the telco echo
  24813. > cancellers screw up the connection, so the 2100hz tone for approximately
  24814. > 1 sec will turn off any echo cancellers that the telcos provide on the
  24815. > lines, letting the modems do their own things in that department.
  24816.  
  24817. Hmmm. From the sounds of it, it's something I don't want to turn off
  24818. (it was a stretch worrying about a handful of really old 2400bps modems
  24819. anyway).
  24820.  
  24821. The faster v.42 connect is enticing tho...I wonder if the echo cancelling
  24822. is much of a factor on digital lines. I hate thinking that I'm spending
  24823. a second turning off things that don't [exist|bother_me].
  24824.  
  24825. Time to go a-searchin'...
  24826.  
  24827.  
  24828.  
  24829. -
  24830.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24831.  with "unsubscribe usr-tc" in the body of the message.
  24832.  For information on digests or retrieving files and old messages send
  24833.  "help" to the same address.  Do not use quotes in your message.
  24834.  
  24835.  
  24836. -------------------------------------------------------------------------------
  24837.  
  24838. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  24839. Subject: Re: (usr-tc) 2100hz answer tone
  24840. Date: 19 Mar 1999 13:40:22 -0500 (EST)
  24841.  
  24842.  
  24843. Yep, looks like I *don't* want to turn off the 2100hz tone for my
  24844. connect-with-almost anything init string.
  24845.  
  24846. OTOH, it looks like it could be turned off for the high-performance
  24847. init string *if* you don't have long-distance callers (and if you
  24848. don't have a telco with the echo cans deployed on their local lines).
  24849.  
  24850. Interesting info about it all is here:
  24851.  
  24852. <http://www.electric-words.com/dict/e/echocancellation.html>
  24853.  
  24854.  
  24855.  
  24856. -
  24857.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24858.  with "unsubscribe usr-tc" in the body of the message.
  24859.  For information on digests or retrieving files and old messages send
  24860.  "help" to the same address.  Do not use quotes in your message.
  24861.  
  24862.  
  24863. -------------------------------------------------------------------------------
  24864.  
  24865. From: Pete Ashdown <pashdown@xmission.com>
  24866. Subject: Re: (usr-tc) MacPPP failures on 4.1.59-6
  24867. Date: 19 Mar 1999 11:52:48 -0700 (MST)
  24868.  
  24869. Tatai SV Krishnan said once upon a time:
  24870.  
  24871. >> We're still having numerous MacPPP failures under 4.1.59-6.  Catching your
  24872. >> request in advance Krish, here's the hex dump output of one such failure.
  24873. >> Please note that I changed the user name and password, and XX'd the hex for
  24874. >> the password.
  24875. >
  24876. >This is with DSP code ?? 
  24877.  
  24878. Yes.  We're almost Quad free here.
  24879.  
  24880. >Are you also using Quad here?
  24881.  
  24882. Not in the case I sent you.
  24883.  
  24884. >Also is it safe to say that disabling ppp offloading does resolve this 
  24885. >problem?
  24886.  
  24887. I haven't tried that yet.  I thought that doing this was a "bad thing".
  24888.  
  24889. -
  24890.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24891.  with "unsubscribe usr-tc" in the body of the message.
  24892.  For information on digests or retrieving files and old messages send
  24893.  "help" to the same address.  Do not use quotes in your message.
  24894.  
  24895.  
  24896. -------------------------------------------------------------------------------
  24897.  
  24898. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  24899. Subject: Re: (usr-tc) MacPPP failures on 4.1.59-6
  24900. Date: 19 Mar 1999 13:37:46 -0600 (CST)
  24901.  
  24902. > 
  24903. > >> We're still having numerous MacPPP failures under 4.1.59-6.  Catching your
  24904. > >> request in advance Krish, here's the hex dump output of one such failure.
  24905. > >> Please note that I changed the user name and password, and XX'd the hex for
  24906. > >> the password.
  24907. > >
  24908. > >This is with DSP code ?? 
  24909. > 
  24910. > Yes.  We're almost Quad free here.
  24911. > 
  24912.  
  24913. What version of DSP are you using?
  24914.  
  24915. > >Are you also using Quad here?
  24916. > 
  24917. > Not in the case I sent you.
  24918. > 
  24919. > >Also is it safe to say that disabling ppp offloading does resolve this 
  24920. > >problem?
  24921. Disabling ppp offloading is not recommened.  PPP offloading enabled will 
  24922. have the modem hardware do the ppp framing.  The only reason I asked if 
  24923. disabling ppp offloading works is because - that would tell me who is 
  24924. causing the problem - HiPer arc or DSP.
  24925.  
  24926.  
  24927. krish
  24928.  
  24929. > 
  24930. > I haven't tried that yet.  I thought that doing this was a "bad thing".
  24931. > 
  24932. > -
  24933. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24934. >  with "unsubscribe usr-tc" in the body of the message.
  24935. >  For information on digests or retrieving files and old messages send
  24936. >  "help" to the same address.  Do not use quotes in your message.
  24937. > 
  24938.  
  24939. -
  24940.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24941.  with "unsubscribe usr-tc" in the body of the message.
  24942.  For information on digests or retrieving files and old messages send
  24943.  "help" to the same address.  Do not use quotes in your message.
  24944.  
  24945.  
  24946. -------------------------------------------------------------------------------
  24947.  
  24948. From: Pete Ashdown <pashdown@xmission.com>
  24949. Subject: Re: (usr-tc) MacPPP failures on 4.1.59-6
  24950. Date: 19 Mar 1999 14:02:03 -0700 (MST)
  24951.  
  24952. Tatai SV Krishnan said once upon a time:
  24953.  
  24954. >What version of DSP are you using?
  24955.  
  24956. 1.2.59 (reports as 1.2.60)
  24957.  
  24958. >> >Also is it safe to say that disabling ppp offloading does resolve this 
  24959. >> >problem?
  24960. >Disabling ppp offloading is not recommened.  PPP offloading enabled will 
  24961. >have the modem hardware do the ppp framing.  The only reason I asked if 
  24962. >disabling ppp offloading works is because - that would tell me who is 
  24963. >causing the problem - HiPer arc or DSP.
  24964.  
  24965. It is a bit difficult to do this, as it is on production equipment.
  24966.  
  24967. -
  24968.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24969.  with "unsubscribe usr-tc" in the body of the message.
  24970.  For information on digests or retrieving files and old messages send
  24971.  "help" to the same address.  Do not use quotes in your message.
  24972.  
  24973.  
  24974. -------------------------------------------------------------------------------
  24975.  
  24976. From: vito@aracnet.net
  24977. Subject: (usr-tc) Help file's on configing USR"S
  24978. Date: 19 Mar 1999 09:28:35 -0500
  24979.  
  24980. Can any tell me where I can find help files that tell me how to setup a USR
  24981. from the very first one that came out to the latest one.
  24982.  
  24983.  
  24984. Thanks
  24985.  
  24986. Vito
  24987.  
  24988. -
  24989.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  24990.  with "unsubscribe usr-tc" in the body of the message.
  24991.  For information on digests or retrieving files and old messages send
  24992.  "help" to the same address.  Do not use quotes in your message.
  24993.  
  24994.  
  24995. -------------------------------------------------------------------------------
  24996.  
  24997. From: Mark Lemmert <cto@athenet.net>
  24998. Subject: (usr-tc) Stack Compression on Webramp causing problems
  24999. Date: 19 Mar 1999 15:12:59 -0600 (CST)
  25000.  
  25001. I have several webramp customers that are having trouble. I've
  25002. isolated the problem with 3com and if I turn off 'stack compression'
  25003. on the webramp everything should work fine.
  25004.  
  25005. I've looked through all the webramp pdf docs and I can't find anywhere
  25006. the command or place on the web interface to set this on or off.
  25007. Does anybody know how to do this? Thanks!
  25008.  
  25009.  
  25010. -Mark Lemmert                           AthEnet Data Exchange
  25011. Chief Technical Officer                 888-919-8700
  25012.  
  25013.  
  25014.  
  25015.  
  25016. -
  25017.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25018.  with "unsubscribe usr-tc" in the body of the message.
  25019.  For information on digests or retrieving files and old messages send
  25020.  "help" to the same address.  Do not use quotes in your message.
  25021.  
  25022.  
  25023. -------------------------------------------------------------------------------
  25024.  
  25025. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  25026. Subject: Re: (usr-tc) MacPPP failures on 4.1.59-6
  25027. Date: 19 Mar 1999 15:59:42 -0600 (CST)
  25028.  
  25029. On Fri, 19 Mar 1999, Pete Ashdown wrote:
  25030.  
  25031. > 
  25032. > It is a bit difficult to do this, as it is on production equipment.
  25033.  
  25034.  
  25035. Let me setup a mac here and start dialing here to check the problem - Can 
  25036. you give me info on what modem the mac is using?  I assume that you are 
  25037. using freeppp on the mac.
  25038.  
  25039. regards
  25040.  
  25041. krish
  25042.  
  25043. > 
  25044. > -
  25045. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25046. >  with "unsubscribe usr-tc" in the body of the message.
  25047. >  For information on digests or retrieving files and old messages send
  25048. >  "help" to the same address.  Do not use quotes in your message.
  25049. > 
  25050.  
  25051. -
  25052.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25053.  with "unsubscribe usr-tc" in the body of the message.
  25054.  For information on digests or retrieving files and old messages send
  25055.  "help" to the same address.  Do not use quotes in your message.
  25056.  
  25057.  
  25058. -------------------------------------------------------------------------------
  25059.  
  25060. From: Mike Andrews <mandrews@termfrost.org>
  25061. Subject: Re: (usr-tc) modem configs
  25062. Date: 19 Mar 1999 17:25:36 -0500 (EST)
  25063.  
  25064. So far no joy...  I get a fast busy on the (new) number now, and the
  25065. failure to connect reason is logged as "invalid cause code".  Hmmmm.
  25066.  
  25067. I know DNIS is being received OK because we've been using it for other
  25068. accounting stuff for forever.  Init string is &K0S51.6=1S76.1=1S81.5=1
  25069. (without the leading AT).  Do you maybe have the leading AT on yours?  
  25070. Mdm.mib says it shouldn't be there.
  25071.  
  25072. I haven't yet had the chance to test this on Quads... only DSP's... but
  25073. the settings should be the same either way (just without the profiles).
  25074.  
  25075.  
  25076. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  25077. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  25078. getting beaten by the police, put down the video camera and come help me!"
  25079.  
  25080. On Fri, 19 Mar 1999, Lon R. Stockton, Jr. wrote:
  25081.  
  25082. > So...no comments regarding connect-with-anything modem strings?
  25083. > 
  25084. > Did my last message even go out on the list?
  25085.  
  25086.  
  25087. -
  25088.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25089.  with "unsubscribe usr-tc" in the body of the message.
  25090.  For information on digests or retrieving files and old messages send
  25091.  "help" to the same address.  Do not use quotes in your message.
  25092.  
  25093.  
  25094. -------------------------------------------------------------------------------
  25095.  
  25096. From: Ricky Beam <jfbeam@beaker.interpath.net>
  25097. Subject: Re: (usr-tc) modem configs
  25098. Date: 19 Mar 1999 21:30:07 -0500 (EST)
  25099.  
  25100. On Fri, 19 Mar 1999, Lon R. Stockton, Jr. wrote:
  25101. >On Fri, 19 Mar 1999, Mike Andrews wrote:
  25102. >> Your message made it. :)  My excuse is "vacation", but I'm going to try
  25103. >> it later today...  thanks for the rundown, this'll be a BIG help...
  25104. >
  25105. >No problem, glad to help if it indeed does. (:   But what's a 'vacation'?
  25106.  
  25107. A 'vacation' is what you call the first time away from (any) work in several
  25108. years.  [Something I was doing until too many people became aware of my
  25109. employment status... it was nice while is lasted :-)]
  25110.  
  25111. >> Why disable the 2100hz answer tone?  What does this gain you?
  25112. >
  25113. >I was in a quick scan mode looking for stuff to turn off. (: According
  25114. >to the dox, some older 2400 modems didn't recognize it, and it allows
  25115. >v42 modems to connect more quickly. On the other hand, it doesn't say
  25116. >what it's for and what I'm losing by turning it off, so more research
  25117. >is indicated on that....or perchance an authoritative post from someone
  25118. >here... (:
  25119.  
  25120. I think the answer tone is used to help the modem index the crappiness of
  25121. the phone line.  (Trick to detect padding???)
  25122.  
  25123. --Ricky
  25124.  
  25125.  
  25126.  
  25127. -
  25128.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25129.  with "unsubscribe usr-tc" in the body of the message.
  25130.  For information on digests or retrieving files and old messages send
  25131.  "help" to the same address.  Do not use quotes in your message.
  25132.  
  25133.  
  25134. -------------------------------------------------------------------------------
  25135.  
  25136. From: GTI x2 Tech <x2@apollo.gti.net>
  25137. Subject: Re: (usr-tc) second span takes down calls on first span
  25138. Date: 19 Mar 1999 23:31:17 -0500 (EST)
  25139.  
  25140.  
  25141. I had the same exact problem and it took me and Bell Atlantic 3 weeks to
  25142. figure out it was a "bad house cable" in other words a bad pair.  
  25143.  
  25144. Tell them the reason the 1st span drops it that it is causing too much
  25145. noise on the 1st circuit and causes it to drop.
  25146.  
  25147. Just have the telco change the pair that its on (if you have multiple) if
  25148. not then have them install a brand new sheilded line in from the
  25149. smartjack.
  25150.  
  25151. John
  25152.  
  25153.  
  25154. On Thu, 18 Mar 1999, Stainforth, Matthew (Sys Mgr - BrunNet) wrote:
  25155.  
  25156. > I'm currently having a problem I've never had before.  For quite a while we
  25157. > have had one active span on a dual PRI card.  This week we ordered the
  25158. > second span and attempted to put it into service.  However, the instant I
  25159. > plugged the span into the second port of the dual PRI card, it caused all
  25160. > the calls on the first span to drop.  After a few seconds, calls start
  25161. > coming in on the first span again but are dropped after a few seconds.  All
  25162. > the calls seem to drop simultaneously.  I talked to the guys at the switch
  25163. > about it and they said it looked like it was related to signalling which
  25164. > would make sense since I'm using NFAS to share the D channel between the two
  25165. > spans.  The configuration on the card looks okay and I have compared it with
  25166. > configurations on other cards I have had in service for over a year.  All
  25167. > code is up to date.  The other strange thing is the carrier and channels
  25168. > seem to come up on the second span but the DS1 terminator box that the telco
  25169. > installed indicates that AMI framing is being used.  But I thought the
  25170. > carrier wouldn't even come up if the framing was incorrect (I have it set on
  25171. > the PRI Card as b8zs, wihch is what it should be).
  25172. > 
  25173. > Error counters for the second span are through the roof according to the CLI
  25174. > on the PRI card.
  25175. > 
  25176. > Has anybody seen this before?  At this point I'm not sure if it's the line
  25177. > has been provisioned wrong by the telco or if my PRI card is bad.  In my
  25178. > experience, I thought the carrier on the ds1 wouldn't even come up if the
  25179. > line was provisioned wrong.  Any ideas?
  25180. > 
  25181. > -
  25182. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25183. >  with "unsubscribe usr-tc" in the body of the message.
  25184. >  For information on digests or retrieving files and old messages send
  25185. >  "help" to the same address.  Do not use quotes in your message.
  25186. > 
  25187.  
  25188.  
  25189. -
  25190.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25191.  with "unsubscribe usr-tc" in the body of the message.
  25192.  For information on digests or retrieving files and old messages send
  25193.  "help" to the same address.  Do not use quotes in your message.
  25194.  
  25195.  
  25196. -------------------------------------------------------------------------------
  25197.  
  25198. From: Robert Reynolds <lists@lcii.net>
  25199. Subject: Re: (usr-tc) DSP1.2.43 
  25200. Date: 20 Mar 1999 00:35:23 -0600 (EST)
  25201.  
  25202. Works great, so far...... 
  25203.  
  25204. One of my DSP's didn't take the upgrade well.  Had to pull out the NAC to
  25205. force reboot. Worked great after that.
  25206.  
  25207. On Thu, 18 Mar 1999, Robert J. Adams wrote:
  25208.  
  25209. > Hello,
  25210. > 
  25211. > Anyone tried the new 1.2.43 code yet?
  25212. > 
  25213. > -j
  25214. > 
  25215. > ---
  25216. > Robert J. Adams radams@siscom.net http://www.siscom.net
  25217. > Looking to outsource news? http://www.newshosting.com
  25218. > SISCOM Network Administration - President, SISCOM Inc.
  25219. > Phone: 937-222-8150 FAX: 937-222-8153 
  25220. > 
  25221. > 
  25222. > -
  25223. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25224. >  with "unsubscribe usr-tc" in the body of the message.
  25225. >  For information on digests or retrieving files and old messages send
  25226. >  "help" to the same address.  Do not use quotes in your message.
  25227. > 
  25228.  
  25229.  
  25230. -
  25231.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25232.  with "unsubscribe usr-tc" in the body of the message.
  25233.  For information on digests or retrieving files and old messages send
  25234.  "help" to the same address.  Do not use quotes in your message.
  25235.  
  25236.  
  25237. -------------------------------------------------------------------------------
  25238.  
  25239. From: Robert Reynolds <lists@lcii.net>
  25240. Subject: Re: (usr-tc) PRI to overflow to another telco's PRI ?
  25241. Date: 20 Mar 1999 00:49:10 -0600 (EST)
  25242.  
  25243. I *think* this is possible.  It's called trunk group overflow and the cost
  25244. here is $150 per arrangment.
  25245.  
  25246. On Fri, 19 Mar 1999, d baud wrote:
  25247.  
  25248. > I am currently trying to switch to another PRI provider, and to do a
  25249. > gradual move of all my PRIs I would need to have my old PRIs to overflow
  25250. > (when busy) to some other PRIs in another Central Office (in the same
  25251. > area code).
  25252. > The two telcos say that it is technically impossible to program this
  25253. > feature on the DMS since it is not in the same Central Office.  Could
  25254. > someone confirm if this is true ?
  25255. > 
  25256. > Also, would you say that it would be possible to have the old telco PRI
  25257. > to overflow to a centrex line in the same CO.  And then program the
  25258. > centrex line to forward calls to the phone number of the other PRI of
  25259. > the other telco ?
  25260. > 
  25261. > D Baud
  25262. > 
  25263. > -
  25264. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25265. >  with "unsubscribe usr-tc" in the body of the message.
  25266. >  For information on digests or retrieving files and old messages send
  25267. >  "help" to the same address.  Do not use quotes in your message.
  25268. > 
  25269.  
  25270.  
  25271. -
  25272.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25273.  with "unsubscribe usr-tc" in the body of the message.
  25274.  For information on digests or retrieving files and old messages send
  25275.  "help" to the same address.  Do not use quotes in your message.
  25276.  
  25277.  
  25278. -------------------------------------------------------------------------------
  25279.  
  25280. From: Stephen Amadei <amadei@dandy.net>
  25281. Subject: (usr-tc) tcview version 0.92
  25282. Date: 20 Mar 1999 02:07:03 -0500 (EST)
  25283.  
  25284.  
  25285. Just to let everybody know, I have updated my tcview script to 0.92, which
  25286. has many improvements, but keep in mind since I don't have access to some
  25287. types of Total Control equipment, I must rely on your results to improve
  25288. the script.
  25289.  
  25290. The improvements:
  25291.  
  25292.   Now should support 30 channel DSP cards as well as 24.
  25293.   Now should support older firmware.
  25294.   Now should support Netserver.
  25295.   Now it can make an educated guess if the chassis/NMC is Hiper or not.
  25296.   And most importantly, it should work with more flavors of CMU-SNMP.
  25297.  
  25298. Most people had problems with the chassis being drawn, but no LEDs
  25299. lighting up... this should be fixed by the CMU-SNMP coding change.
  25300.  
  25301. I am currently working on a readme, describing the script... which should
  25302. be online sometime tonight... but the new script itself is online
  25303. already at http://www.dandy.net/~amadei
  25304.  
  25305. Email me if you have problems, praises, spare cash... ;-)
  25306.  
  25307.                     ----Steve
  25308. Stephen Amadei
  25309. Director of MIS
  25310. Dandy Connections, Inc.
  25311. Atlantic City, NJ
  25312.  
  25313.  
  25314. -
  25315.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25316.  with "unsubscribe usr-tc" in the body of the message.
  25317.  For information on digests or retrieving files and old messages send
  25318.  "help" to the same address.  Do not use quotes in your message.
  25319.  
  25320.  
  25321. -------------------------------------------------------------------------------
  25322.  
  25323. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  25324. Subject: Re: (usr-tc) modem configs
  25325. Date: 20 Mar 1999 06:21:05 -0500 (EST)
  25326.  
  25327.  
  25328. On Fri, 19 Mar 1999, Mike Andrews wrote:
  25329.  
  25330. > I know DNIS is being received OK because we've been using it for other
  25331. > accounting stuff for forever.  Init string is &K0S51.6=1S76.1=1S81.5=1
  25332. > (without the leading AT).  Do you maybe have the leading AT on yours?  
  25333. > Mdm.mib says it shouldn't be there.
  25334.  
  25335. mib must be incorrect, I couldn't get it to work until I added the AT
  25336. prefix.
  25337.  
  25338. Speaking of problems with the docs...
  25339.  
  25340. There's an item called 'Fallback disable' (under signal converter
  25341. settings). It is either enabled or disabled. If I set it to 'enabled',
  25342. have I set the thing to enable fallbacks, or have I set it to enable
  25343. the disabling of fallbacks?
  25344.  
  25345.  
  25346.  
  25347. -
  25348.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25349.  with "unsubscribe usr-tc" in the body of the message.
  25350.  For information on digests or retrieving files and old messages send
  25351.  "help" to the same address.  Do not use quotes in your message.
  25352.  
  25353.  
  25354. -------------------------------------------------------------------------------
  25355.  
  25356. From: jeff.binkley@asacomp.com (Jeff Binkley)
  25357. Subject: (usr-tc) Modem Connection Problems
  25358. Date: 20 Mar 1999 10:19:00 -0500
  25359.  
  25360.  
  25361.  
  25362.  
  25363. Has anyone seen problems with Creative Labs DI5601 Kflex/V.90 modems Labs DI5601 Kflex/V.90 modems 
  25364. connecting to Total Control systems ?  We have a customer who's modem 
  25365. will train and train but never connect.  It shows unauthenticated in 
  25366. RADIUS.  
  25367.  
  25368. I've look on all of the 56K modem web pages and noone says much about 
  25369. this beast.  I went to www.modemblaster.com, Creative Lab's website, and 
  25370. it was useless.  No manual to even look for  init commands or anything.  
  25371. I am running 4.1.62-4 of HiPerArc code with Quads running 5.10.9 code 
  25372. across PRIs.
  25373.  
  25374.  
  25375. Thanks,
  25376.  
  25377. Jeff Binkley
  25378. ASA Network C
  25379.  
  25380. -
  25381.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25382.  with "unsubscribe usr-tc" in the body of the message.
  25383.  For information on digests or retrieving files and old messages send
  25384.  "help" to the same address.  Do not use quotes in your message.
  25385.  
  25386.  
  25387. -------------------------------------------------------------------------------
  25388.  
  25389. From: Jesse Sipprell <jss@evcom.net>
  25390. Subject: (usr-tc) HDSP "Dead Air"
  25391. Date: 20 Mar 1999 13:43:49 -0500
  25392.  
  25393. I remember reading lots about this on the list a few months back, and now I am
  25394. becoming convinced it's happening to me at one of my pops (pop is a HARC/HDSP
  25395. chassis, all PRI circuits).
  25396.  
  25397. Symptoms:
  25398.  
  25399. * Customer calls lead number and gets "nothing" or "dead air".  Customer
  25400. * retries call and occasionally gets the same thing, then suddenly symptom
  25401. * vanishes and customer is able to connect.  Test calls from our NOC
  25402. * occasionally do the same thing.  Sometimes the dead air lasts for several
  25403. * minutes, sometimes it disappears almost immediately (and of course, most of
  25404. * the time we can't reproduce it at all).
  25405.  
  25406. * The HDSP's "No Idle Modem Available" counters are incrementing, especially
  25407. * those cards that are first in the hunt group.  The increment is slow
  25408. * (and I'm beginning to feel, related).
  25409.  
  25410. All the DSP cards are set to "Round Robin."  IIRC from this list, someone once
  25411. mentioned something about the telco signaling a new call on a PRI _before_ the
  25412. HDSP has officially "released" the last modem available on a full circuit; and
  25413. thus no modems are available to take the call.
  25414.  
  25415. Any ideas on settings I can confirm/ask the telco about?  For reference, the
  25416. switch is a DMS100.
  25417.  
  25418. Thanks!
  25419.  
  25420. -- 
  25421. Jesse Sipprell
  25422. Technical Operations Director
  25423. Evolution Communications, Inc.
  25424. 800-496-4736 (ext 106)
  25425.  
  25426. * Finger jss@evcom.net for my PGP Public Key *
  25427.  
  25428. -
  25429.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25430.  with "unsubscribe usr-tc" in the body of the message.
  25431.  For information on digests or retrieving files and old messages send
  25432.  "help" to the same address.  Do not use quotes in your message.
  25433.  
  25434.  
  25435. -------------------------------------------------------------------------------
  25436.  
  25437. From: Paul Farber <farber@admin.f-tech.net>
  25438. Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  25439. Date: 20 Mar 1999 14:42:28 -0500 (EST)
  25440.  
  25441. If 4% can't connect at all, how did they fill out the survey?  Or did you
  25442. mail it to them?
  25443.  
  25444. My experience is that asking them what is going on is a bad thing.  The
  25445. connection is NEVER fast enough, the ALWAYS get disconnected, etc.
  25446.  
  25447. Check your logs to back up the data.... you may be suprised.
  25448.  
  25449. Paul D. Farber II
  25450. Farber Technology
  25451. Ph. 570-628-5303
  25452. Fax 570-628-5545
  25453. farber@admin.f-tech.net
  25454.  
  25455. On Thu, 18 Mar 1999, Mike Hamrich wrote:
  25456.  
  25457. > OK HiperArc with latest code 3/4/99
  25458. > 
  25459. > Since the "upgrade" we are having tons of connection issues.
  25460. > Couriers can't connect
  25461. > Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  25462. > OEM/Brown box Sportsters can't stay connected
  25463. > 
  25464. > We also told owner of non X2 modem to go elsewere.
  25465. > 
  25466. > We surveyed our users, 248 replied so far:
  25467. > 67% say slower speed, 22% are having problems saying connected, 4% can't
  25468. > connect at all, and ONLY 7%  report better connection.
  25469. > 
  25470. > We have PRI lines, Set PPP offloading to no, Authenticate ANY Preferrd PAP
  25471. > 
  25472. > Any other ideas to make this stuff work as well as the old stuff did?
  25473. > 
  25474. > Thanks in advance for you help
  25475. > 
  25476. > Mike Hamrich
  25477. > CIO, DrFast.Net, Inc.
  25478. > (216) 797-1040
  25479. > 
  25480. > 
  25481. > -
  25482. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25483. >  with "unsubscribe usr-tc" in the body of the message.
  25484. >  For information on digests or retrieving files and old messages send
  25485. >  "help" to the same address.  Do not use quotes in your message.
  25486. > 
  25487.  
  25488.  
  25489. -
  25490.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25491.  with "unsubscribe usr-tc" in the body of the message.
  25492.  For information on digests or retrieving files and old messages send
  25493.  "help" to the same address.  Do not use quotes in your message.
  25494.  
  25495.  
  25496. -------------------------------------------------------------------------------
  25497.  
  25498. From: Gilles Melanson <gilles@vianet.on.ca>
  25499. Subject: (usr-tc) Backup radius server w/ARC (4.1.72)
  25500. Date: 20 Mar 1999 16:02:07 -0500 (EST)
  25501.  
  25502. I've seen this fly on the mailing list in the past, but it's been a while
  25503. now.
  25504.  
  25505. If I wanted to stick a second radius server entry in the ARC, the default
  25506. behaviour is to switch to the second if the first one fails;  that switch
  25507. is permanent until the secondary goes offline for some reason.
  25508.  
  25509. What's the procedure to auth off the 2nd server ONLY IF the primary goes
  25510. down?  (ie: how do you get it to switch back to the 1st automatically)
  25511.  
  25512. Thanks.
  25513.  
  25514. --
  25515. Gilles Melanson                         ViaNet Internet Solutions
  25516. System Administrator                    128 Larch St. Suite 301
  25517. gilles@vianet.on.ca                     Sudbury, ON Canada  P3E 5J8
  25518.  
  25519. You have acquired a scroll entitled 'irk gleknow mizk'(n).--More--
  25520. This is an IBM Manual scroll.--More--
  25521. You are permanently confused.
  25522.                         -- Dave Decot
  25523.  
  25524.  
  25525. -
  25526.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25527.  with "unsubscribe usr-tc" in the body of the message.
  25528.  For information on digests or retrieving files and old messages send
  25529.  "help" to the same address.  Do not use quotes in your message.
  25530.  
  25531.  
  25532. -------------------------------------------------------------------------------
  25533.  
  25534. From: Stephen Amadei <amadei@dandy.net>
  25535. Subject: Re: (usr-tc) Backup radius server w/ARC (4.1.72)
  25536. Date: 20 Mar 1999 17:07:24 -0500 (EST)
  25537.  
  25538. On Sat, 20 Mar 1999, Gilles Melanson wrote:
  25539.  
  25540. > What's the procedure to auth off the 2nd server ONLY IF the primary goes
  25541. > down?  (ie: how do you get it to switch back to the 1st automatically)
  25542.  
  25543. I, too, anxiously await this tidbit of knowledge... temporarily killing
  25544. off the backup RADIUS server is getting old.  ;-)
  25545.  
  25546.                     ----Steve
  25547. Stephen Amadei
  25548. Director of MIS
  25549. Dandy Connections, Inc.
  25550. Atlantic City, NJ
  25551.  
  25552.  
  25553. -
  25554.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25555.  with "unsubscribe usr-tc" in the body of the message.
  25556.  For information on digests or retrieving files and old messages send
  25557.  "help" to the same address.  Do not use quotes in your message.
  25558.  
  25559.  
  25560. -------------------------------------------------------------------------------
  25561.  
  25562. From: Charles Sprickman <spork@inch.com>
  25563. Subject: Re: (usr-tc) Backup radius server w/ARC (4.1.72)
  25564. Date: 20 Mar 1999 18:43:35 -0500 (EST)
  25565.  
  25566. If I'm looking at the right setup script, this is what I have, and it
  25567. acheives the desired behaviour...
  25568.  
  25569. set accounting_backup primary first_server 10.0.0.1
  25570. set accounting_backup primary first_secret "secretsecret" 
  25571.  
  25572. set authENTICATION secondarY_serVER 10.1.0.1
  25573. set autHENTICATION secondary_secRET "secretsecret"
  25574.  
  25575. set radIUS autHENTICATION_ALGORITHM fall_THROUGH 
  25576.  
  25577. show authen
  25578. show account
  25579.  
  25580. Charles
  25581.  
  25582. -- 
  25583. =-----------------=                                        = 
  25584. | Charles Sprickman                       Internet Channel |
  25585. | INCH System Administration Team         (212)243-5200    |
  25586. | spork@inch.com                          access@inch.com  |
  25587. =                                         =----------------=
  25588.  
  25589. On Sat, 20 Mar 1999, Stephen Amadei wrote:
  25590.  
  25591. > On Sat, 20 Mar 1999, Gilles Melanson wrote:
  25592. > 
  25593. > > What's the procedure to auth off the 2nd server ONLY IF the primary goes
  25594. > > down?  (ie: how do you get it to switch back to the 1st automatically)
  25595. > 
  25596. > I, too, anxiously await this tidbit of knowledge... temporarily killing
  25597. > off the backup RADIUS server is getting old.  ;-)
  25598. > 
  25599. >                     ----Steve
  25600. > Stephen Amadei
  25601. > Director of MIS
  25602. > Dandy Connections, Inc.
  25603. > Atlantic City, NJ
  25604. > 
  25605. > 
  25606. > -
  25607. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25608. >  with "unsubscribe usr-tc" in the body of the message.
  25609. >  For information on digests or retrieving files and old messages send
  25610. >  "help" to the same address.  Do not use quotes in your message.
  25611. > 
  25612.  
  25613.  
  25614. -
  25615.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25616.  with "unsubscribe usr-tc" in the body of the message.
  25617.  For information on digests or retrieving files and old messages send
  25618.  "help" to the same address.  Do not use quotes in your message.
  25619.  
  25620.  
  25621. -------------------------------------------------------------------------------
  25622.  
  25623. From: Mike Andrews <mandrews@termfrost.org>
  25624. Subject: Re: (usr-tc) modem configs
  25625. Date: 20 Mar 1999 19:07:33 -0500 (EST)
  25626.  
  25627. On Sat, 20 Mar 1999, Lon R. Stockton, Jr. wrote:
  25628.  
  25629. > 
  25630. > On Fri, 19 Mar 1999, Mike Andrews wrote:
  25631. > 
  25632. > > I know DNIS is being received OK because we've been using it for other
  25633. > > accounting stuff for forever.  Init string is &K0S51.6=1S76.1=1S81.5=1
  25634. > > (without the leading AT).  Do you maybe have the leading AT on yours?  
  25635. > > Mdm.mib says it shouldn't be there.
  25636. > 
  25637. > mib must be incorrect, I couldn't get it to work until I added the AT
  25638. > prefix.
  25639.  
  25640. Sure enough, that took care of it.  Thanks... you just saved us a TON of
  25641. hassle (and possibly some money we were considering putting into a PM3)...
  25642.  
  25643.  
  25644. > Speaking of problems with the docs...
  25645. > 
  25646. > There's an item called 'Fallback disable' (under signal converter
  25647. > settings). It is either enabled or disabled. If I set it to 'enabled',
  25648. > have I set the thing to enable fallbacks, or have I set it to enable
  25649. > the disabling of fallbacks?
  25650.  
  25651. Heh.  I'm not sure, but I've just left that at the default.  I wouldn't
  25652. think you'd ever want to disable fallbacks..
  25653.  
  25654.  
  25655. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  25656. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  25657. getting beaten by the police, put down the video camera and come help me!"
  25658.  
  25659.  
  25660. -
  25661.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25662.  with "unsubscribe usr-tc" in the body of the message.
  25663.  For information on digests or retrieving files and old messages send
  25664.  "help" to the same address.  Do not use quotes in your message.
  25665.  
  25666.  
  25667. -------------------------------------------------------------------------------
  25668.  
  25669. From: Courtney Spencer <cospencer@mindspring.com>
  25670. Subject: Re: (usr-tc) Modem Connection Problems
  25671. Date: 21 Mar 1999 07:22:08 -0500
  25672.  
  25673. That model uses the Rockwell PCI chipset if I am correct 2.1.2.12x
  25674. Customer must use AT+MS=V90 or AT+MS=V34 to get connected.
  25675.  
  25676.  
  25677. > Has anyone seen problems with Creative Labs DI5601 Kflex/V.90 modems Labs
  25678. > DI5601 Kflex/V.90 modems
  25679. > connecting to Total Control systems ?  We have a customer who's modem
  25680. > will train and train but never connect.  It shows unauthenticated in
  25681. > RADIUS.
  25682.  
  25683. > I've look on all of the 56K modem web pages and noone says much about
  25684. > this beast.  I went to www.modemblaster.com, Creative Lab's website, and
  25685. > it was useless.  No manual to even look for  init commands or anything.
  25686. > I am running 4.1.62-4 of HiPerArc code with Quads running 5.10.9 code
  25687. > across PRIs.
  25688.  
  25689.  
  25690. > Thanks,
  25691.  
  25692. > Jeff Binkley
  25693. > ASA Network C
  25694.  
  25695. > -
  25696. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25697. >  with "unsubscribe usr-tc" in the body of the message.
  25698. >  For information on digests or retrieving files and old messages send
  25699. >  "help" to the same address.  Do not use quotes in your message.
  25700.  
  25701.  
  25702. -
  25703.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25704.  with "unsubscribe usr-tc" in the body of the message.
  25705.  For information on digests or retrieving files and old messages send
  25706.  "help" to the same address.  Do not use quotes in your message.
  25707.  
  25708.  
  25709. -------------------------------------------------------------------------------
  25710.  
  25711. From: jeff.binkley@asacomp.com (Jeff Binkley)
  25712. Subject: (usr-tc) RE: (USR-TC) MODEM CONNEC
  25713. Date: 21 Mar 1999 20:07:00 -0500
  25714.  
  25715.  
  25716.  
  25717.  
  25718.  
  25719. Thanks but no luck.  When I had the user add this, Dialup networking 
  25720. says the modem no longer responds (i.e. doesn't understand command).  I 
  25721. also tried -V90=0.  Same results.  I told them to call Creative Labs or 
  25722. take it back for a trade on another brand.  Anyone else have ideas on 
  25723. this one ?
  25724.  
  25725. Jeff
  25726.  
  25727.  
  25728. U>That model uses the Rockwell PCI chipset if I am correct 2.1.2.12x
  25729. U>Customer must use AT+MS=V90 or AT+MS=V34 to get connected.
  25730.  
  25731.  
  25732. U>> Has anyone seen problems with Creative Labs DI5601 Kflex/V.90 modems
  25733. U>> Labs DI5601 Kflex/V.90 modems
  25734. U>> connecting to Total Control systems ?  We have a customer who's
  25735. U>> modem will train and train but never connect.  It shows
  25736. U>> unauthenticated in RADIUS.
  25737.  
  25738. U>> I've look on all of the 56K modem web pages and noone says much
  25739. U>> about this beast.  I went to www.modemblaster.com, Creative Lab's
  25740. U>> website, and it was useless.  No manual to even look for  init
  25741. U>> commands or anything. I am running 4.1.62-4 of HiPerArc code with
  25742. U>> Quads running 5.10.9 code across PRIs.
  25743.  
  25744.  
  25745. U>> Thanks,
  25746.  
  25747. U>> Jeff Binkley
  25748. U>> ASA Network C
  25749.  
  25750. CMPQwk 1.42-21 9999
  25751.  
  25752.  
  25753. -
  25754.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25755.  with "unsubscribe usr-tc" in the body of the message.
  25756.  For information on digests or retrieving files and old messages send
  25757.  "help" to the same address.  Do not use quotes in your message.
  25758.  
  25759.  
  25760. -------------------------------------------------------------------------------
  25761.  
  25762. From: "Greg Owens" <gowens@magnolia-net.com>
  25763. Subject: (usr-tc) Dead modems
  25764. Date: 21 Mar 1999 20:31:03 -0600
  25765.  
  25766. We are having a problem of users dialing up and getting no response from our
  25767. Hyperarc with DSP modems. Looked in Total Control it appears that in slot 1
  25768. modem 7&8 show and "abnormal disconnect77" error for reason for call failure
  25769. and no users are able to log on to those modems. Have tried resetting the
  25770. ports, but it did no good. Any ideas!!!  Is this a modem going bad or could
  25771. a reset of the card be in order here.
  25772.         Greg Owens
  25773. Magnolia Internet Services
  25774.  
  25775.  
  25776. -
  25777.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25778.  with "unsubscribe usr-tc" in the body of the message.
  25779.  For information on digests or retrieving files and old messages send
  25780.  "help" to the same address.  Do not use quotes in your message.
  25781.  
  25782.  
  25783. -------------------------------------------------------------------------------
  25784.  
  25785. From: Robert von Bismarck <rvb@petrel.ch>
  25786. Subject: RE: (usr-tc) HDSP "Dead Air"
  25787. Date: 22 Mar 1999 11:29:28 +0100
  25788.  
  25789. Dead Air happens when one of the modems of the DSP has not recycled before
  25790. the PRI part of the HDSP acknowledges the "CALL SETUP" command from the
  25791. switch. The only method to reduce this is to set the modems to "Fixed
  25792. Assignment" and set the switch to "round-robin".
  25793. The weirdness about this is that the dead air is even Q.931 compliant.
  25794.  
  25795. Background on Q.931 if I remember everything correctly
  25796.  
  25797. When call comes in, switch sends "CALL SETUP" to equipment.
  25798. Equipment sends "CALL PROCEEDING" or "ALERT" (depends on code version in the
  25799. HDSP) within 1 second
  25800. Switch sends "CONNECT" and that's it...
  25801.  
  25802. In case of no acknowledge from the equipment, switch sends "CALL CLEAR", if
  25803. no answer, it tears down the DS0 or the DS1 (depending on the switch) and
  25804. sends alarms everywhere.
  25805.  
  25806. If you need more low-level info, check out document ETS 300 102-2 for ISDN
  25807. basic call control (http://www.etsi.org)
  25808.  
  25809. Hope this helps,
  25810.  
  25811. Robert
  25812.  
  25813. > -----Original Message-----
  25814. > From:    Jesse Sipprell [SMTP:jss@evcom.net]
  25815. > Sent:    samedi, 20. mars 1999 19:44
  25816. > To:    usr-tc@lists.xmission.com
  25817. > Subject:    (usr-tc) HDSP "Dead Air"
  25818. > 
  25819. > I remember reading lots about this on the list a few months back, and now
  25820. > I am
  25821. > becoming convinced it's happening to me at one of my pops (pop is a
  25822. > HARC/HDSP
  25823. > chassis, all PRI circuits).
  25824. > 
  25825. > Symptoms:
  25826. > 
  25827. > * Customer calls lead number and gets "nothing" or "dead air".  Customer
  25828. > * retries call and occasionally gets the same thing, then suddenly symptom
  25829. > * vanishes and customer is able to connect.  Test calls from our NOC
  25830. > * occasionally do the same thing.  Sometimes the dead air lasts for
  25831. > several
  25832. > * minutes, sometimes it disappears almost immediately (and of course, most
  25833. > of
  25834. > * the time we can't reproduce it at all).
  25835. > 
  25836. > * The HDSP's "No Idle Modem Available" counters are incrementing,
  25837. > especially
  25838. > * those cards that are first in the hunt group.  The increment is slow
  25839. > * (and I'm beginning to feel, related).
  25840. > 
  25841. > All the DSP cards are set to "Round Robin."  IIRC from this list, someone
  25842. > once
  25843. > mentioned something about the telco signaling a new call on a PRI _before_
  25844. > the
  25845. > HDSP has officially "released" the last modem available on a full circuit;
  25846. > and
  25847. > thus no modems are available to take the call.
  25848. > 
  25849. > Any ideas on settings I can confirm/ask the telco about?  For reference,
  25850. > the
  25851. > switch is a DMS100.
  25852. > 
  25853. > Thanks!
  25854. > 
  25855. > -- 
  25856. > Jesse Sipprell
  25857. > Technical Operations Director
  25858. > Evolution Communications, Inc.
  25859. > 800-496-4736 (ext 106)
  25860. > 
  25861. > * Finger jss@evcom.net for my PGP Public Key *
  25862. > 
  25863. > -
  25864. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25865. >  with "unsubscribe usr-tc" in the body of the message.
  25866. >  For information on digests or retrieving files and old messages send
  25867. >  "help" to the same address.  Do not use quotes in your message.
  25868.  
  25869. -
  25870.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25871.  with "unsubscribe usr-tc" in the body of the message.
  25872.  For information on digests or retrieving files and old messages send
  25873.  "help" to the same address.  Do not use quotes in your message.
  25874.  
  25875.  
  25876. -------------------------------------------------------------------------------
  25877.  
  25878. From: matthews <matthews@brunnet.net>
  25879. Subject: RE: (usr-tc) second span takes down calls on first span
  25880. Date: 22 Mar 1999 08:49:13 -0400
  25881.  
  25882.  
  25883. Interestingly enough, that's what the switch dudes thought at first but 
  25884. they found something more interesting first.  It seems that when you set up 
  25885. two PRI circuits with separate signalling channels, they are classified as 
  25886. separate trunk groups.  That makes sense.  When you are sharing a D channel 
  25887. with NFAS it is classified as one trunk group and the trunks have to be 
  25888. enumerated properly.  For some strange reason, it doesn't work very well 
  25889. when you enumerate the first 23 channels from 1 to 23 and then enumerate 
  25890. the trunks on the second PRI 1 to 24(as opposed to 24 to 47).  Gee. 
  25891.  Imagine that.
  25892.  
  25893. As consolation for so much wasted time, I got to go back to my boss and 
  25894. bash the telco for being stupid.  There's always a silver lining...
  25895.  
  25896. On Saturday, March 20, 1999 12:31 AM, GTI x2 Tech [SMTP:x2@apollo.gti.net] 
  25897. wrote:
  25898. >
  25899. > I had the same exact problem and it took me and Bell Atlantic 3 weeks to
  25900. > figure out it was a "bad house cable" in other words a bad pair.
  25901. >
  25902. > Tell them the reason the 1st span drops it that it is causing too much
  25903. > noise on the 1st circuit and causes it to drop.
  25904. >
  25905. > Just have the telco change the pair that its on (if you have multiple) if
  25906. > not then have them install a brand new sheilded line in from the
  25907. > smartjack.
  25908. >
  25909.  
  25910.  
  25911.  
  25912. -
  25913.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25914.  with "unsubscribe usr-tc" in the body of the message.
  25915.  For information on digests or retrieving files and old messages send
  25916.  "help" to the same address.  Do not use quotes in your message.
  25917.  
  25918.  
  25919. -------------------------------------------------------------------------------
  25920.  
  25921. From: Dale Hege <fhege@sover.net>
  25922. Subject: (usr-tc) TCM View
  25923. Date: 22 Mar 1999 10:16:25 -0500 (EST)
  25924.  
  25925.  
  25926. Does anyone know what variables TCM polls to find out if a card is to be
  25927. shown in yellow?
  25928.  
  25929. -Dale
  25930.  
  25931.  
  25932. -
  25933.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  25934.  with "unsubscribe usr-tc" in the body of the message.
  25935.  For information on digests or retrieving files and old messages send
  25936.  "help" to the same address.  Do not use quotes in your message.
  25937.  
  25938.  
  25939. -------------------------------------------------------------------------------
  25940.  
  25941. From: Brian <signal@shreve.net>
  25942. Subject: (usr-tc) breaking up of a Class C for a pop
  25943. Date: 22 Mar 1999 09:03:21 -0600 (EST)
  25944.  
  25945.  
  25946. I while back someone posted a suggestion about a way to divide a single
  25947. class C for maximum efficiency for a pop, and was wondering if anyone
  25948. remembers.  I would like to use 2 class C's, for 2 chassis, with a max of
  25949. 10 hdm's per chassis, it looks messy, but the best I can get is this,
  25950. which isn't quite enough:
  25951.  
  25952.  
  25953. 208.232.62.0/28        router, switch, arcs, nmc's
  25954.             (1 router, 1 switch, 2 nmc's, 4 arc's)
  25955.  
  25956. Hub 1    Arc 1
  25957. =============
  25958. 208.232.62.16/28    pool1    16
  25959. 208.232.62.32/27    pool2    32
  25960. 208.232.62.64/26    pool3    64
  25961. 208.232.62.128/29    pool4     8
  25962.             ------------
  25963.                  120 (23channels x 5hdms
  25964.                      needs at least 115)
  25965.  
  25966. Hub 1     Arc 2
  25967. =============
  25968. 208.232.62.136/29    pool5     8
  25969. 208.232.62.144/28    pool6   16
  25970. 208.232.62.160/27    pool7   32
  25971. 208.232.62.192/26    pool8   64
  25972.             ------------
  25973.                 120 (23channels x 5hdms 
  25974.                                      needs at least 115)
  25975.  
  25976. Hub 2     Arc 1
  25977. =============
  25978. 208.232.63.0/25        pool9    128
  25979.  
  25980. Hub 2     Arc 2
  25981. =============
  25982. 208.232.63.128/25    pool10    128
  25983.  
  25984.  
  25985. Is the above really the best way to do it, if I want to use no address
  25986. space other than the 2 /24's?  It looks ugly that many pools, but perhaps
  25987. its efficient and really a good solution, if anyone has any comments, that
  25988. would be great, or even better, a better solution would be great as well.
  25989.  
  25990. Also, can anyone see any problems with the above?
  25991.  
  25992. Brian
  25993.  
  25994.  
  25995.  
  25996. Brian Feeny (BF304)     signal@shreve.net   
  25997. 318-222-2638 x 109    http://www.shreve.net/~signal      
  25998. Network Administrator   ShreveNet Inc. (ASN 11881)           
  25999.  
  26000.  
  26001.  
  26002. -
  26003.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26004.  with "unsubscribe usr-tc" in the body of the message.
  26005.  For information on digests or retrieving files and old messages send
  26006.  "help" to the same address.  Do not use quotes in your message.
  26007.  
  26008.  
  26009. -------------------------------------------------------------------------------
  26010.  
  26011. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  26012. Subject: RE: (usr-tc) TCM View
  26013. Date: 22 Mar 1999 09:31:43 -0600
  26014.  
  26015.  
  26016.  
  26017. |-----Original Message-----
  26018. |From: owner-usr-tc@lists.xmission.com
  26019. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Dale Hege
  26020. |Sent: Monday, March 22, 1999 9:16 AM
  26021. |To: usr-tc@lists.xmission.com
  26022. |Subject: (usr-tc) TCM View
  26023. |
  26024. |
  26025. |
  26026. |Does anyone know what variables TCM polls to find out if a card is to be
  26027. |shown in yellow?
  26028. |
  26029.  
  26030. It goes yellow when it cant talk to the card. (ie no responce).
  26031.  
  26032. -M
  26033.  
  26034.  
  26035.  
  26036. -
  26037.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26038.  with "unsubscribe usr-tc" in the body of the message.
  26039.  For information on digests or retrieving files and old messages send
  26040.  "help" to the same address.  Do not use quotes in your message.
  26041.  
  26042.  
  26043. -------------------------------------------------------------------------------
  26044.  
  26045. From: Jeff Soetemans <jsoets@oxford.net>
  26046. Subject: (usr-tc) ARC Redundancy
  26047. Date: 22 Mar 1999 11:43:01 -0500
  26048.  
  26049. Is it possible for the dual arc configuration in the fully loaded DSP
  26050. chassis to back up each other in the event one arc card dies. I've heard
  26051. from one source it's not possible and another source says it's possible
  26052. if you only run 10 DSP's in the chassis.
  26053. Thanks,
  26054. Jeff
  26055.  
  26056.  
  26057. -
  26058.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26059.  with "unsubscribe usr-tc" in the body of the message.
  26060.  For information on digests or retrieving files and old messages send
  26061.  "help" to the same address.  Do not use quotes in your message.
  26062.  
  26063.  
  26064. -------------------------------------------------------------------------------
  26065.  
  26066. From: Brian <signal@shreve.net>
  26067. Subject: Re: (usr-tc) ARC Redundancy
  26068. Date: 22 Mar 1999 10:37:06 -0600 (EST)
  26069.  
  26070. On Mon, 22 Mar 1999, Jeff Soetemans wrote:
  26071.  
  26072. > Is it possible for the dual arc configuration in the fully loaded DSP
  26073. > chassis to back up each other in the event one arc card dies. I've heard
  26074. > from one source it's not possible and another source says it's possible
  26075. > if you only run 10 DSP's in the chassis.
  26076.  
  26077. I am confused on this also.  It would be great if when Arc #2 fails Arc #1
  26078. could just become the owner of all the cards in the chasis,  and press on.
  26079.  
  26080. I am not sure how IP pools would be handled though, I suppose for it to
  26081. work 100% Arc #1 would have to assume any ip pools that were handled by
  26082. arc #2.
  26083.  
  26084. brian
  26085.  
  26086.  
  26087. > Thanks,
  26088. > Jeff
  26089. > 
  26090. > 
  26091. > -
  26092. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26093. >  with "unsubscribe usr-tc" in the body of the message.
  26094. >  For information on digests or retrieving files and old messages send
  26095. >  "help" to the same address.  Do not use quotes in your message.
  26096. > 
  26097.  
  26098. Brian Feeny (BF304)     signal@shreve.net   
  26099. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26100. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26101.  
  26102.  
  26103. -
  26104.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26105.  with "unsubscribe usr-tc" in the body of the message.
  26106.  For information on digests or retrieving files and old messages send
  26107.  "help" to the same address.  Do not use quotes in your message.
  26108.  
  26109.  
  26110. -------------------------------------------------------------------------------
  26111.  
  26112. From: GTI x2 Tech <x2@apollo.gti.net>
  26113. Subject: (usr-tc) HiperArc upgrade / Livingston ORU problem
  26114. Date: 22 Mar 1999 12:27:07 -0500 (EST)
  26115.  
  26116.  
  26117.  
  26118. I just upgraded one of my TC racks with the HiperArc upgrade.  Everything
  26119. went fine except all my ISDN router users (mainly Livingston ORU's and one
  26120. Ascend 50) with subnets cant connect.  The error that they all get is
  26121. this: (from the ORU side)
  26122.  
  26123. S2: Couldn't find CHAP user HiPer
  26124.  
  26125.  
  26126. Do I have to activate something?  I have a user using Linux and his subnet
  26127. works fine.  It seems only to effect people with stand-alone ISDN routers.
  26128.  
  26129. Debug info follows.
  26130.  
  26131. TIA,
  26132.  
  26133. John
  26134.  
  26135.  
  26136.  
  26137.  
  26138. Sending LCP_CONFIGURE_REQUEST to port S2 of 25 bytes containing:
  26139. 01 01 00 19 05 06 87 2B AB F9 11 04 06 1C 12 02 13 09 03 00 C0 05 03 1F FE 
  26140.     Packet Info:  Code: 0x01, ID: 0x01, 25 bytes.
  26141.     Magic-Number [0x05], length: (6 bytes), [0x872BABF9]
  26142.     Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
  26143.         Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
  26144.     Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes)
  26145.     Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
  26146. [0x0300C005031FFE]
  26147.         Class [0x03]: IEEE 802.1 MAC Address  00 C0 05 03 1F FE 
  26148. Received LCP_CONFIGURE_REQUEST on port S2 of 26 bytes containing:
  26149. 01 01 00 1E 01 04 05 EA 03 05 C2 23 05 05 06 20 D7 29 EB 
  26150. 07 02 08 02 11 04 05 EA 13 03 00     Packet Info:  Code: 0x01, ID:
  26151. 0x01, 30 bytes.
  26152.     Maximum-Receive-Unit [0x01], length: (4 bytes) 1514 bytes [0x05EA]
  26153.     Authentication-Protocol [0x03], length: (5 bytes), Challenge
  26154. Handshake Authentication Protocol [0xC22305]
  26155.         CHAP using MD5 encryption algorithm
  26156.     Magic-Number [0x05], length: (6 bytes), [0x20D729EB]
  26157.     Protocol-Field-Compression [0x07], length: (2 bytes)
  26158.     Address-and-Control-Field-Compression [0x08], length: (2 bytes)
  26159.     Multilink-MRRU [0x11], length: (4 bytes), [0x05EA]
  26160.         Max-Receive-Reconstructed-Unit (MRRU): 1514 bytes.
  26161.     Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00]
  26162.         Class [0x00]: Null Class  Null Address
  26163. Sending LCP_CONFIGURE_ACK to port S2 of 30 bytes containing:
  26164. 02 01 00 1E 01 04 05 EA 03 05 C2 23 05 05 06 20 D7 29 EB 
  26165. 07 02 08 02 11 04 05 EA 13 03 00     Packet Info:  Code: 0x02, ID:
  26166. 0x01, 30 bytes.
  26167.     Maximum-Receive-Unit [0x01], length: (4 bytes) 1514 bytes [0x05EA]
  26168.     Authentication-Protocol [0x03], length: (5 bytes), Challenge
  26169. Handshake Authentication Protocol [0xC22305]
  26170.         CHAP using MD5 encryption algorithm
  26171.     Magic-Number [0x05], length: (6 bytes), [0x20D729EB]
  26172.     Protocol-Field-Compression [0x07], length: (2 bytes)
  26173.     Address-and-Control-Field-Compression [0x08], length: (2 bytes)
  26174.     Multilink-MRRU [0x11], length: (4 bytes), [0x05EA]
  26175.         Max-Receive-Reconstructed-Unit (MRRU): 1514 bytes.
  26176.     Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00]
  26177.         Class [0x00]: Null Class  Null Address
  26178. Received LCP_CONFIGURE_REJECT on port S2 of 2 bytes containing:
  26179. 04 01 00 06 12 02     Packet Info:  Code: 0x04, ID: 0x01, 6 bytes.
  26180.     Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes)
  26181. Sending LCP_CONFIGURE_REQUEST to port S2 of 23 bytes containing:
  26182. 01 02 00 17 05 06 87 2B AB F9 11 04 06 1C 13 09 03 00 C0 05 03 1F FE 
  26183.     Packet Info:  Code: 0x01, ID: 0x02, 23 bytes.
  26184.     Magic-Number [0x05], length: (6 bytes), [0x872BABF9]
  26185.     Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
  26186.         Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
  26187.     Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
  26188. [0x0300C005031FFE]
  26189.         Class [0x03]: IEEE 802.1 MAC Address  00 C0 05 03 1F FE 
  26190. Received LCP_CONFIGURE_ACK on port S2 of 19 bytes containing:
  26191. 02 02 00 17 05 06 87 2B AB F9 11 04 06 1C 13 09 03 00 C0 05 03 1F FE 
  26192.     Packet Info:  Code: 0x02, ID: 0x02, 23 bytes.
  26193.     Magic-Number [0x05], length: (6 bytes), [0x872BABF9]
  26194.     Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
  26195.         Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
  26196.     Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
  26197. [0x0300C005031FFE]
  26198.         Class [0x03]: IEEE 802.1 MAC Address  00 C0 05 03 1F FE
  26199. **** S2: LCP Open
  26200. Sending IPCP_CONFIGURE_REQUEST to port S2 of 10 bytes containing:
  26201. 01 01 00 0A 03 06 D0 D8 7C 81     Packet Info:  Code: 0x01, ID: 0x01, 10
  26202. bytes.
  26203.     IP-Address  [0x03], length: (6 bytes), [208.216.111.111]
  26204. Received CHAP_CONF_CHALLENGE on port S2 of 26 bytes containing:
  26205. 72 
  26206.     Packet Info:  Code: 01, ID: 02, 26 bytes.
  26207.     ValSize[0x10]: (16 bytes), Value:
  26208. [0xBA02BEFAE8AB07EBE1E4F]
  26209.     Name: HiPer [0x4869506572]
  26210. S2: Couldn't find CHAP user HiPer
  26211.  
  26212. Received LCP_PROTOCOL_REJECT on port S2 of 12 bytes containing
  26213. 08 03 00 10 80 21 01 01 00 0A 03 06 D0 D8 7C 81 
  26214.     Packet Info:  Code: 0x08, ID: 0x03, 16 bytes.
  26215.     Rejected Protocol: [0x8021], Internet Protocol Control Protocol 
  26216. 01 01 00 0A 03 06 D0 D8 7C 81     Packet Info:  Code: 0x01, ID: 0x01, 10
  26217. bytes.
  26218.     IP-Address  [0x03], length: (6 bytes), [208.216.111.111]
  26219.  
  26220.  
  26221. -
  26222.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26223.  with "unsubscribe usr-tc" in the body of the message.
  26224.  For information on digests or retrieving files and old messages send
  26225.  "help" to the same address.  Do not use quotes in your message.
  26226.  
  26227.  
  26228. -------------------------------------------------------------------------------
  26229.  
  26230. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  26231. Subject: Re: (usr-tc) HiperArc upgrade / Livingston ORU problem
  26232. Date: 22 Mar 1999 11:50:32 -0600 (CST)
  26233.  
  26234.  
  26235. > 
  26236. > 
  26237. > I just upgraded one of my TC racks with the HiperArc upgrade.  Everything
  26238. > went fine except all my ISDN router users (mainly Livingston ORU's and one
  26239. > Ascend 50) with subnets cant connect.  The error that they all get is
  26240. > this: (from the ORU side)
  26241. > 
  26242. > S2: Couldn't find CHAP user HiPer
  26243. > 
  26244.  
  26245. The portmaster is looking for the user with system password as name.  You 
  26246. have to do this.
  26247.  
  26248. On the hiper arc create a user with the system name of the portmaster and 
  26249. with a password ( say x)
  26250. on the port master create a user with the username of HiPer and the 
  26251. password (x)
  26252.  
  26253. krish
  26254.  
  26255. > 
  26256. > Do I have to activate something?  I have a user using Linux and his subnet
  26257. > works fine.  It seems only to effect people with stand-alone ISDN routers.
  26258. > 
  26259. > Debug info follows.
  26260. > 
  26261. > TIA,
  26262. > 
  26263. > John
  26264. > 
  26265. > 
  26266. > 
  26267. > 
  26268. > Sending LCP_CONFIGURE_REQUEST to port S2 of 25 bytes containing:
  26269. > 01 01 00 19 05 06 87 2B AB F9 11 04 06 1C 12 02 13 09 03 00 C0 05 03 1F FE 
  26270. >     Packet Info:  Code: 0x01, ID: 0x01, 25 bytes.
  26271. >     Magic-Number [0x05], length: (6 bytes), [0x872BABF9]
  26272. >     Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
  26273. >         Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
  26274. >     Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes)
  26275. >     Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
  26276. > [0x0300C005031FFE]
  26277. >         Class [0x03]: IEEE 802.1 MAC Address  00 C0 05 03 1F FE 
  26278. > Received LCP_CONFIGURE_REQUEST on port S2 of 26 bytes containing:
  26279. > 01 01 00 1E 01 04 05 EA 03 05 C2 23 05 05 06 20 D7 29 EB 
  26280. > 07 02 08 02 11 04 05 EA 13 03 00     Packet Info:  Code: 0x01, ID:
  26281. > 0x01, 30 bytes.
  26282. >     Maximum-Receive-Unit [0x01], length: (4 bytes) 1514 bytes [0x05EA]
  26283. >     Authentication-Protocol [0x03], length: (5 bytes), Challenge
  26284. > Handshake Authentication Protocol [0xC22305]
  26285. >         CHAP using MD5 encryption algorithm
  26286. >     Magic-Number [0x05], length: (6 bytes), [0x20D729EB]
  26287. >     Protocol-Field-Compression [0x07], length: (2 bytes)
  26288. >     Address-and-Control-Field-Compression [0x08], length: (2 bytes)
  26289. >     Multilink-MRRU [0x11], length: (4 bytes), [0x05EA]
  26290. >         Max-Receive-Reconstructed-Unit (MRRU): 1514 bytes.
  26291. >     Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00]
  26292. >         Class [0x00]: Null Class  Null Address
  26293. > Sending LCP_CONFIGURE_ACK to port S2 of 30 bytes containing:
  26294. > 02 01 00 1E 01 04 05 EA 03 05 C2 23 05 05 06 20 D7 29 EB 
  26295. > 07 02 08 02 11 04 05 EA 13 03 00     Packet Info:  Code: 0x02, ID:
  26296. > 0x01, 30 bytes.
  26297. >     Maximum-Receive-Unit [0x01], length: (4 bytes) 1514 bytes [0x05EA]
  26298. >     Authentication-Protocol [0x03], length: (5 bytes), Challenge
  26299. > Handshake Authentication Protocol [0xC22305]
  26300. >         CHAP using MD5 encryption algorithm
  26301. >     Magic-Number [0x05], length: (6 bytes), [0x20D729EB]
  26302. >     Protocol-Field-Compression [0x07], length: (2 bytes)
  26303. >     Address-and-Control-Field-Compression [0x08], length: (2 bytes)
  26304. >     Multilink-MRRU [0x11], length: (4 bytes), [0x05EA]
  26305. >         Max-Receive-Reconstructed-Unit (MRRU): 1514 bytes.
  26306. >     Multilink-Endpoint-Discriminator [0x13], length: (3 bytes), [0x00]
  26307. >         Class [0x00]: Null Class  Null Address
  26308. > Received LCP_CONFIGURE_REJECT on port S2 of 2 bytes containing:
  26309. > 04 01 00 06 12 02     Packet Info:  Code: 0x04, ID: 0x01, 6 bytes.
  26310. >     Multilink-Short-Sequence-Number-Header [0x12], length: (2 bytes)
  26311. > Sending LCP_CONFIGURE_REQUEST to port S2 of 23 bytes containing:
  26312. > 01 02 00 17 05 06 87 2B AB F9 11 04 06 1C 13 09 03 00 C0 05 03 1F FE 
  26313. >     Packet Info:  Code: 0x01, ID: 0x02, 23 bytes.
  26314. >     Magic-Number [0x05], length: (6 bytes), [0x872BABF9]
  26315. >     Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
  26316. >         Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
  26317. >     Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
  26318. > [0x0300C005031FFE]
  26319. >         Class [0x03]: IEEE 802.1 MAC Address  00 C0 05 03 1F FE 
  26320. > Received LCP_CONFIGURE_ACK on port S2 of 19 bytes containing:
  26321. > 02 02 00 17 05 06 87 2B AB F9 11 04 06 1C 13 09 03 00 C0 05 03 1F FE 
  26322. >     Packet Info:  Code: 0x02, ID: 0x02, 23 bytes.
  26323. >     Magic-Number [0x05], length: (6 bytes), [0x872BABF9]
  26324. >     Multilink-MRRU [0x11], length: (4 bytes), [0x061C]
  26325. >         Max-Receive-Reconstructed-Unit (MRRU): 1564 bytes.
  26326. >     Multilink-Endpoint-Discriminator [0x13], length: (9 bytes),
  26327. > [0x0300C005031FFE]
  26328. >         Class [0x03]: IEEE 802.1 MAC Address  00 C0 05 03 1F FE
  26329. > **** S2: LCP Open
  26330. > Sending IPCP_CONFIGURE_REQUEST to port S2 of 10 bytes containing:
  26331. > 01 01 00 0A 03 06 D0 D8 7C 81     Packet Info:  Code: 0x01, ID: 0x01, 10
  26332. > bytes.
  26333. >     IP-Address  [0x03], length: (6 bytes), [208.216.111.111]
  26334. > Received CHAP_CONF_CHALLENGE on port S2 of 26 bytes containing:
  26335. > 72 
  26336. >     Packet Info:  Code: 01, ID: 02, 26 bytes.
  26337. >     ValSize[0x10]: (16 bytes), Value:
  26338. > [0xBA02BEFAE8AB07EBE1E4F]
  26339. >     Name: HiPer [0x4869506572]
  26340. > S2: Couldn't find CHAP user HiPer
  26341. > 
  26342. > Received LCP_PROTOCOL_REJECT on port S2 of 12 bytes containing
  26343. > 08 03 00 10 80 21 01 01 00 0A 03 06 D0 D8 7C 81 
  26344. >     Packet Info:  Code: 0x08, ID: 0x03, 16 bytes.
  26345. >     Rejected Protocol: [0x8021], Internet Protocol Control Protocol 
  26346. > 01 01 00 0A 03 06 D0 D8 7C 81     Packet Info:  Code: 0x01, ID: 0x01, 10
  26347. > bytes.
  26348. >     IP-Address  [0x03], length: (6 bytes), [208.216.111.111]
  26349. > 
  26350. > 
  26351. > -
  26352. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26353. >  with "unsubscribe usr-tc" in the body of the message.
  26354. >  For information on digests or retrieving files and old messages send
  26355. >  "help" to the same address.  Do not use quotes in your message.
  26356. > 
  26357.  
  26358. -
  26359.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26360.  with "unsubscribe usr-tc" in the body of the message.
  26361.  For information on digests or retrieving files and old messages send
  26362.  "help" to the same address.  Do not use quotes in your message.
  26363.  
  26364.  
  26365. -------------------------------------------------------------------------------
  26366.  
  26367. From: David Bolen <db3l@ans.net>
  26368. Subject: Re: (usr-tc) TCM View
  26369. Date: 22 Mar 1999 15:07:15 EST
  26370.  
  26371. Dale Hege <fhege@sover.net> writes:
  26372.  
  26373. > Does anyone know what variables TCM polls to find out if a card is to be
  26374. > shown in yellow?
  26375.  
  26376. I don't have TCM source, but there are really only two likely
  26377. possibilities:
  26378.  
  26379.   * The value from querying uchasEntityOperStatus for the card level
  26380.     entity (or in the case of a quad modem card, the status for the
  26381.     individual modems - or perhaps just the first modem, since there
  26382.     is no card level manageable entity on such cards).
  26383.  
  26384.     This object reflects whether or not the NMC can communicate
  26385.     successfully to the particular entity and thus whether or not
  26386.     information can be queried or set for that entity.
  26387.  
  26388.   * The "failed" bit in the LED status query for the chassis, which
  26389.     indicates whether or not a card is operational.
  26390.  
  26391.     The most significant bit of each of the 12 nibbles (6 byte block)
  26392.     in the LED state query (uchasFrontPanelLedStates) is used for
  26393.     status information.  The first three MSBs, if set, represent that
  26394.     the slot has a card, it has been discovered, and something on it
  26395.     is failed, respectively. 
  26396.  
  26397.     So if the first two MSBs indicate presence and identification, but
  26398.     the third MSB is set, then uchasEntityOperStatus is something
  26399.     other than "operational" for at least one entity on that slot.
  26400.     You can just check the third MSB directly, since it won't be set
  26401.     if the slot is empty or not discovered.
  26402.  
  26403. If I had to bet I'd guess the LED state information is used, since
  26404. all TCM does is draw the card in yellow - it doesn't try to actually
  26405. tell you what the non-operational state is (which would require
  26406. querying the specific uchasEntityOperStatus objects for the
  26407. appropriate entities).  Also, the LED state query is faster and TCM
  26408. would already have queried it in order to draw the chassis.
  26409.  
  26410. -- David
  26411.  
  26412. /-----------------------------------------------------------------------\
  26413.  \               David Bolen              \  Internet: db3l@ans.net    /
  26414.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  26415.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  26416. \-----------------------------------------------------------------------/
  26417.  
  26418. -
  26419.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26420.  with "unsubscribe usr-tc" in the body of the message.
  26421.  For information on digests or retrieving files and old messages send
  26422.  "help" to the same address.  Do not use quotes in your message.
  26423.  
  26424.  
  26425. -------------------------------------------------------------------------------
  26426.  
  26427. From: Sean Herr <Sean@YNC.NET>
  26428. Subject: (usr-tc) Facility "IP", Level "CRITICAL"
  26429. Date: 22 Mar 1999 15:32:24 -0600
  26430.  
  26431. I am trying to assign a static IP and keep getting this error in syslogs.  I
  26432. can not find where and overlap would exist.  Can someone shed some light?
  26433. Worked fine until I stuck in a ARC.
  26434.  
  26435. At 14:19:39, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt(): Invalid
  26436. Configuration,
  26437. Address range overlap - IP address (XXX.XXX.XXX.XXX)
  26438.  
  26439. TIA
  26440.  
  26441.  
  26442. Sean Herr
  26443. @YourNET Connection, Inc.
  26444. 847-524-3900
  26445. http://www.ync.net
  26446.  
  26447. -
  26448.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26449.  with "unsubscribe usr-tc" in the body of the message.
  26450.  For information on digests or retrieving files and old messages send
  26451.  "help" to the same address.  Do not use quotes in your message.
  26452.  
  26453.  
  26454. -------------------------------------------------------------------------------
  26455.  
  26456. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  26457. Subject: Re: (usr-tc) Facility "IP", Level "CRITICAL"
  26458. Date: 22 Mar 1999 16:10:01 -0600 (CST)
  26459.  
  26460. On Mon, 22 Mar 1999, Sean Herr wrote:
  26461.  
  26462. > I am trying to assign a static IP and keep getting this error in syslogs.  I
  26463. > can not find where and overlap would exist.  Can someone shed some light?
  26464. > Worked fine until I stuck in a ARC.
  26465. > 
  26466. > At 14:19:39, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt(): Invalid
  26467. > Configuration,
  26468. > Address range overlap - IP address (XXX.XXX.XXX.XXX)
  26469. > 
  26470.  
  26471. What is the netmask you are using for this users?  Looks like you are 
  26472. giving the user a invalid netmask.
  26473.  
  26474. krish
  26475.  
  26476. > TIA
  26477. > 
  26478. > 
  26479. > Sean Herr
  26480. > @YourNET Connection, Inc.
  26481. > 847-524-3900
  26482. > http://www.ync.net
  26483. > 
  26484. > -
  26485. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26486. >  with "unsubscribe usr-tc" in the body of the message.
  26487. >  For information on digests or retrieving files and old messages send
  26488. >  "help" to the same address.  Do not use quotes in your message.
  26489. > 
  26490.  
  26491. -
  26492.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26493.  with "unsubscribe usr-tc" in the body of the message.
  26494.  For information on digests or retrieving files and old messages send
  26495.  "help" to the same address.  Do not use quotes in your message.
  26496.  
  26497.  
  26498. -------------------------------------------------------------------------------
  26499.  
  26500. From: Mike Andrews <mandrews@termfrost.org>
  26501. Subject: Re: (usr-tc) modem configs
  26502. Date: 22 Mar 1999 16:55:18 -0500 (EST)
  26503.  
  26504. On Sat, 20 Mar 1999, Lon R. Stockton, Jr. wrote:
  26505.  
  26506. > On Fri, 19 Mar 1999, Mike Andrews wrote:
  26507. > 
  26508. > > I know DNIS is being received OK because we've been using it for other
  26509. > > accounting stuff for forever.  Init string is &K0S51.6=1S76.1=1S81.5=1
  26510. > > (without the leading AT).  Do you maybe have the leading AT on yours?  
  26511. > > Mdm.mib says it shouldn't be there.
  26512. > 
  26513. > mib must be incorrect, I couldn't get it to work until I added the AT
  26514. > prefix.
  26515.  
  26516. I found the discrepancy here -- the MIB is correct for Quads.  It's wrong
  26517. for DSP's.  DSP's want the AT.  Quads don't.
  26518.  
  26519. I'm also having a problem that maybe someone else can help with here. The
  26520. above init string doesn't disable v.90/x2 correctly on the Quads. (Works
  26521. great on DSP's.)  If I call in with a Courier, it chokes during the
  26522. handshake -- it sounds as if one side is attempting x2 (not v.90) and the
  26523. other side is trying v.34.  (It dies during the line frequency probe
  26524. sequence, in other words.)  If I call in with an LT Winmodem it seems to
  26525. be more or less OK.
  26526.  
  26527. So...  What's the *correct* AT sequence to completely kill all 56K
  26528. modulations on a Quad modem and leave v.34 intact?
  26529.  
  26530.  
  26531. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  26532. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  26533. getting beaten by the police, put down the video camera and come help me!"
  26534.  
  26535.  
  26536. -
  26537.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26538.  with "unsubscribe usr-tc" in the body of the message.
  26539.  For information on digests or retrieving files and old messages send
  26540.  "help" to the same address.  Do not use quotes in your message.
  26541.  
  26542.  
  26543. -------------------------------------------------------------------------------
  26544.  
  26545. From: Abraham Aldaco <aaldaco@campus.her.itesm.mx>
  26546. Subject: (usr-tc) dhcp
  26547. Date: 22 Mar 1999 15:29:22 -0600
  26548.  
  26549. How i configure a HiperARC to assign DHCP address?  I have installed
  26550. Total Control Security and Accounting server in windows NT 4.0.
  26551.  
  26552. --
  26553. _______________________________
  26554. Ing. Abraham N. Aldaco GastΘlum
  26555. Telecomunicaciones y Redes
  26556. ITESM CSN
  26557.  
  26558.  
  26559.  
  26560. -
  26561.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26562.  with "unsubscribe usr-tc" in the body of the message.
  26563.  For information on digests or retrieving files and old messages send
  26564.  "help" to the same address.  Do not use quotes in your message.
  26565.  
  26566.  
  26567. -------------------------------------------------------------------------------
  26568.  
  26569. From: "Randy McMillan" <randy@pacinfo.com>
  26570. Subject: (usr-tc) Can you get both ANI and DNIS or do you need to choose?
  26571. Date: 22 Mar 1999 16:12:49 -0800
  26572.  
  26573. This is a multi-part message in MIME format.
  26574.  
  26575. ------=_NextPart_000_00B8_01BE747E.D47521A0
  26576. Content-Type: text/plain;
  26577.     charset="Windows-1252"
  26578. Content-Transfer-Encoding: quoted-printable
  26579.  
  26580. I was asking my telco if they could pass both ANI and DNIS digits so I =
  26581. would
  26582. have both calling station id and called station id.  This is on a T1 vs =
  26583. a
  26584. PRI.  In trying it out, it looks like it is putting the Calling Station =
  26585. ID
  26586. into the DNIS digits, and there is nothing in the ANI digits.  Do I need =
  26587. to
  26588. choose one over the other?
  26589. Also, is there a difference in capabilities between the mftones and
  26590. dtmftones setup?  Right now it is using mftones because the telco =
  26591. thought it
  26592. would work better for this.  Thanks for any info.
  26593.  
  26594. Randy McMillan
  26595. PacInfo
  26596.  
  26597.  
  26598. ------=_NextPart_000_00B8_01BE747E.D47521A0
  26599. Content-Type: text/html;
  26600.     charset="Windows-1252"
  26601. Content-Transfer-Encoding: quoted-printable
  26602.  
  26603. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
  26604. <HTML><HEAD>
  26605. <META content=3D"text/html; charset=3Dwindows-1252" =
  26606. http-equiv=3DContent-Type>
  26607. <META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR>
  26608. <STYLE></STYLE>
  26609. </HEAD>
  26610. <BODY bgColor=3D#ffffff>
  26611. <DIV><FONT face=3DArial size=3D2>I was asking my telco if they could =
  26612. pass both ANI=20
  26613. and DNIS digits so I would<BR>have both calling station id and called =
  26614. station=20
  26615. id.  This is on a T1 vs a<BR>PRI.  In trying it out, it looks =
  26616. like it=20
  26617. is putting the Calling Station ID<BR>into the DNIS digits, and there is =
  26618. nothing=20
  26619. in the ANI digits.  Do I need to<BR>choose one over the =
  26620. other?<BR>Also, is=20
  26621. there a difference in capabilities between the mftones and<BR>dtmftones=20
  26622. setup?  Right now it is using mftones because the telco thought =
  26623. it<BR>would=20
  26624. work better for this.  Thanks for any info.<BR><BR>Randy=20
  26625. McMillan<BR>PacInfo<BR></FONT></DIV></BODY></HTML>
  26626.  
  26627. ------=_NextPart_000_00B8_01BE747E.D47521A0--
  26628.  
  26629.  
  26630. -
  26631.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26632.  with "unsubscribe usr-tc" in the body of the message.
  26633.  For information on digests or retrieving files and old messages send
  26634.  "help" to the same address.  Do not use quotes in your message.
  26635.  
  26636.  
  26637. -------------------------------------------------------------------------------
  26638.  
  26639. From: Brian <signal@shreve.net>
  26640. Subject: Re: (usr-tc) Can you get both ANI and DNIS or do you need to choose?
  26641. Date: 22 Mar 1999 18:06:30 -0600 (EST)
  26642.  
  26643. On Mon, 22 Mar 1999, Randy McMillan wrote:
  26644.  
  26645. > I was asking my telco if they could pass both ANI and DNIS digits so I would
  26646. > have both calling station id and called station id.  This is on a T1 vs a
  26647. > PRI.  In trying it out, it looks like it is putting the Calling Station ID
  26648. > into the DNIS digits, and there is nothing in the ANI digits.  Do I need to
  26649. > choose one over the other?
  26650.  
  26651. no.
  26652.  
  26653. > Also, is there a difference in capabilities between the mftones and
  26654. > dtmftones setup?  Right now it is using mftones because the telco thought it
  26655. > would work better for this.  Thanks for any info.
  26656. > 
  26657. > Randy McMillan
  26658. > PacInfo
  26659. > 
  26660. > 
  26661.  
  26662. Brian Feeny (BF304)     signal@shreve.net   
  26663. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26664. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26665.  
  26666.  
  26667. -
  26668.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26669.  with "unsubscribe usr-tc" in the body of the message.
  26670.  For information on digests or retrieving files and old messages send
  26671.  "help" to the same address.  Do not use quotes in your message.
  26672.  
  26673.  
  26674. -------------------------------------------------------------------------------
  26675.  
  26676. From: Mike Andrews <mandrews@termfrost.org>
  26677. Subject: Re: (usr-tc) Can you get both ANI and DNIS or do you need to choose?
  26678. Date: 22 Mar 1999 19:50:06 -0500 (EST)
  26679.  
  26680. We get both here, but we had to whine to Bellsouth to get them to turn ANI
  26681. on (even though it's included for free per their PRI tariff).  DNIS worked
  26682. out of the box.
  26683.  
  26684.  
  26685. Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort KY
  26686. mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see me
  26687. getting beaten by the police, put down the video camera and come help me!"
  26688.  
  26689. On Mon, 22 Mar 1999, Randy McMillan wrote:
  26690.  
  26691. > I was asking my telco if they could pass both ANI and DNIS digits so I would
  26692. > have both calling station id and called station id.  This is on a T1 vs a
  26693. > PRI.  In trying it out, it looks like it is putting the Calling Station ID
  26694. > into the DNIS digits, and there is nothing in the ANI digits.  Do I need to
  26695. > choose one over the other?
  26696. > Also, is there a difference in capabilities between the mftones and
  26697. > dtmftones setup?  Right now it is using mftones because the telco thought it
  26698. > would work better for this.  Thanks for any info.
  26699. > 
  26700. > Randy McMillan
  26701. > PacInfo
  26702. > 
  26703. > 
  26704.  
  26705.  
  26706. -
  26707.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26708.  with "unsubscribe usr-tc" in the body of the message.
  26709.  For information on digests or retrieving files and old messages send
  26710.  "help" to the same address.  Do not use quotes in your message.
  26711.  
  26712.  
  26713. -------------------------------------------------------------------------------
  26714.  
  26715. From: matthews <matthews@brunnet.net>
  26716. Subject: RE: (usr-tc) Can you get both ANI and DNIS or do you need to choose?
  26717. Date: 23 Mar 1999 08:34:55 -0400
  26718.  
  26719.  
  26720. I also get both here with the exception that ANI does not come through if 
  26721. the user has an unpublished number or has disabled it with *68 or whichever 
  26722. sequence does it in your area.  I tried to pursuade the telco not to block 
  26723. ANI in those circumstances by telling them I needed them for billing 
  26724. purposes and asking what they would do if I were a long distance carrier 
  26725. and I needed to bill for calls.  They said they couldn't do it because I 
  26726. had to be an inter-lata carrier.
  26727.  
  26728. On Monday, March 22, 1999 8:50 PM, Mike Andrews 
  26729. [SMTP:mandrews@termfrost.org] wrote:
  26730. > We get both here, but we had to whine to Bellsouth to get them to turn 
  26731. ANI
  26732. > on (even though it's included for free per their PRI tariff).  DNIS 
  26733. worked
  26734. > out of the box.
  26735. >
  26736. >
  26737. > Mike Andrews (icq 6602506) - VP & Sysadmin, Digital Crescent, Frankfort 
  26738. KY
  26739. > mandrews@dcr.net -=- http://www.termfrost.org --=--=-- "If you ever see 
  26740. me
  26741. > getting beaten by the police, put down the video camera and come help 
  26742. me!"
  26743. >
  26744. > On Mon, 22 Mar 1999, Randy McMillan wrote:
  26745. >
  26746. > > I was asking my telco if they could pass both ANI and DNIS digits so I 
  26747. would
  26748. > > have both calling station id and called station id.  This is on a T1 vs 
  26749. a
  26750. > > PRI.  In trying it out, it looks like it is putting the Calling Station 
  26751. ID
  26752. > > into the DNIS digits, and there is nothing in the ANI digits.  Do I 
  26753. need to
  26754. > > choose one over the other?
  26755. > > Also, is there a difference in capabilities between the mftones and
  26756. > > dtmftones setup?  Right now it is using mftones because the telco 
  26757. thought it
  26758. > > would work better for this.  Thanks for any info.
  26759. > >
  26760. > > Randy McMillan
  26761. > > PacInfo
  26762. > >
  26763. > >
  26764. >
  26765. >
  26766. > -
  26767. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26768. >  with "unsubscribe usr-tc" in the body of the message.
  26769. >  For information on digests or retrieving files and old messages send
  26770. >  "help" to the same address.  Do not use quotes in your message.
  26771.  
  26772.  
  26773.  
  26774.  
  26775. -
  26776.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26777.  with "unsubscribe usr-tc" in the body of the message.
  26778.  For information on digests or retrieving files and old messages send
  26779.  "help" to the same address.  Do not use quotes in your message.
  26780.  
  26781.  
  26782. -------------------------------------------------------------------------------
  26783.  
  26784. From: Sean Herr <Sean@YNC.NET>
  26785. Subject: RE: (usr-tc) Facility "IP", Level "CRITICAL"
  26786. Date: 23 Mar 1999 12:13:59 -0600
  26787.  
  26788. It was a netmask issue, but now it is doing this, any idea?
  26789.  
  26790. At 11:01:34, Facility "Auth Facility", Level "COMMON":: The connection for
  26791. call id 6730, on if slot:5/mod:1 was dropped for user UNKNOWN
  26792.  
  26793. At 11:01:33, Facility "Auth Facility", Level "COMMON":: Port slot:5/mod:1
  26794. successful local authentication for user: jjohns
  26795.  
  26796. -----Original Message-----
  26797. Sent: Monday, March 22, 1999 4:10 PM
  26798. Cc: 'usr-tc@lists.xmission.com'
  26799.  
  26800.  
  26801. On Mon, 22 Mar 1999, Sean Herr wrote:
  26802.  
  26803. > I am trying to assign a static IP and keep getting this error in syslogs.
  26804. I
  26805. > can not find where and overlap would exist.  Can someone shed some light?
  26806. > Worked fine until I stuck in a ARC.
  26807. > 
  26808. > At 14:19:39, Facility "IP", Level "CRITICAL":: ip_fwd_get_opt(): Invalid
  26809. > Configuration,
  26810. > Address range overlap - IP address (XXX.XXX.XXX.XXX)
  26811. > 
  26812.  
  26813. What is the netmask you are using for this users?  Looks like you are 
  26814. giving the user a invalid netmask.
  26815.  
  26816. krish
  26817.  
  26818. > TIA
  26819. > 
  26820. > 
  26821. > Sean Herr
  26822. > @YourNET Connection, Inc.
  26823. > 847-524-3900
  26824. > http://www.ync.net
  26825. > 
  26826. > -
  26827. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26828. >  with "unsubscribe usr-tc" in the body of the message.
  26829. >  For information on digests or retrieving files and old messages send
  26830. >  "help" to the same address.  Do not use quotes in your message.
  26831. > 
  26832.  
  26833. -
  26834.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26835.  with "unsubscribe usr-tc" in the body of the message.
  26836.  For information on digests or retrieving files and old messages send
  26837.  "help" to the same address.  Do not use quotes in your message.
  26838.  
  26839. -
  26840.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26841.  with "unsubscribe usr-tc" in the body of the message.
  26842.  For information on digests or retrieving files and old messages send
  26843.  "help" to the same address.  Do not use quotes in your message.
  26844.  
  26845.  
  26846. -------------------------------------------------------------------------------
  26847.  
  26848. From: Aaron Nabil <nabil@spiritone.com>
  26849. Subject: Re: (usr-tc) Can you get both ANI and DNIS or do you need to choose?
  26850. Date: 23 Mar 1999 11:30:09 -0800 (PST)
  26851.  
  26852. Randy McMillan writes...
  26853. >I was asking my telco if they could pass both ANI and DNIS digits so I
  26854. >would have both calling station id and called station id.  This is on a
  26855. >T1 vs a PRI.
  26856.  
  26857. I usually don't answer people who won't turn off MIME when posting to 
  26858. mailing lists, but I'm in a generous mood today.
  26859.  
  26860. First off, I'm going to assume you mean CALLER-ID, not ANI.  You can't
  26861. get ANI, you can get CALLER-ID.
  26862.  
  26863. Sure, your telco can send you both, but that would be an unusual 
  26864. configuration, and it's unlikely that the order writer would be able
  26865. to convey that request correctly to the translations group.  More likely
  26866. than not, they are just going to tell you it's not possible.  If you have
  26867. a CLEC, they would be much more likely to do it for you.  The CLEC we use
  26868. can do this.
  26869.  
  26870. Other problems are going to be that CALLER-ID isn't normally sent
  26871. on a T1 as digit tones, it's sent as FSK.  So you'd have to stuff CALLER-ID
  26872. into the slot where ANI would go (if you were a long-distance carrier).  Then
  26873. you are going to need to negotiate the format, all of the KP+ST stuff, winks,
  26874. digit supression, etc.  It's unlikely you'd ever get it working without a
  26875. T1 test set capabable of monitoring the line to see what they are sending
  26876. you.  
  26877.  
  26878. -- 
  26879. Aaron Nabil
  26880.  
  26881. -
  26882.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26883.  with "unsubscribe usr-tc" in the body of the message.
  26884.  For information on digests or retrieving files and old messages send
  26885.  "help" to the same address.  Do not use quotes in your message.
  26886.  
  26887.  
  26888. -------------------------------------------------------------------------------
  26889.  
  26890. From: Ricky Beam <jfbeam@beaker.interpath.net>
  26891. Subject: RE: (usr-tc) Can you get both ANI and DNIS or do you need to choose?
  26892. Date: 23 Mar 1999 15:49:31 -0500 (EST)
  26893.  
  26894. On Tue, 23 Mar 1999, matthews wrote:
  26895. >I also get both here with the exception that ANI does not come through if 
  26896. >the user has an unpublished number or has disabled it with *68 or whichever 
  26897. >sequence does it in your area.  I tried to pursuade the telco not to block 
  26898. >ANI in those circumstances by telling them I needed them for billing 
  26899. >purposes and asking what they would do if I were a long distance carrier 
  26900. >and I needed to bill for calls.  They said they couldn't do it because I 
  26901. >had to be an inter-lata carrier.
  26902.  
  26903. Check recent FCC rulings.  There was something about disclosure of phone
  26904. numbers by ANI some time ago.  Our PBX gets ANI data but is honoring the
  26905. blocking by not reporting it to the display on the phones.
  26906.  
  26907. --Ricky
  26908.  
  26909.  
  26910.  
  26911. -
  26912.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26913.  with "unsubscribe usr-tc" in the body of the message.
  26914.  For information on digests or retrieving files and old messages send
  26915.  "help" to the same address.  Do not use quotes in your message.
  26916.  
  26917.  
  26918. -------------------------------------------------------------------------------
  26919.  
  26920. From: matthews <matthews@brunnet.net>
  26921. Subject: (usr-tc) multiple hunt groups on a single trunk group
  26922. Date: 23 Mar 1999 16:52:04 -0400
  26923.  
  26924.  
  26925. Is it typically possible to do multiple independant hunt groups within a 
  26926. single trunk group?  We would like to dedicate one channel to a customer 
  26927. who would dial a distinct phone number to get his dedicated modem.  I posed 
  26928. the question to our telco and they responded saying it was possible to 
  26929. assign a POTS number to a trunk but they could not remove it from the 
  26930. "main" hunt group.
  26931.  
  26932. I, however, have a feeling that they either aren't telling me the truth or 
  26933. they don't know.
  26934.  
  26935. Is anybody else doing anything like this?  Another scenario might be two 
  26936. distinct separate hunt groups composed of, say, 12 and 11 channels each. 
  26937.  Does anybody know if this is possible?
  26938.  
  26939. Matthew...
  26940.  
  26941.  
  26942. -
  26943.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26944.  with "unsubscribe usr-tc" in the body of the message.
  26945.  For information on digests or retrieving files and old messages send
  26946.  "help" to the same address.  Do not use quotes in your message.
  26947.  
  26948.  
  26949. -------------------------------------------------------------------------------
  26950.  
  26951. From: Brian <signal@shreve.net>
  26952. Subject: Re: (usr-tc) multiple hunt groups on a single trunk group
  26953. Date: 23 Mar 1999 14:57:37 -0600 (EST)
  26954.  
  26955. On Tue, 23 Mar 1999, matthews wrote:
  26956.  
  26957. > 
  26958. > Is it typically possible to do multiple independant hunt groups within a 
  26959. > single trunk group?  We would like to dedicate one channel to a customer 
  26960. > who would dial a distinct phone number to get his dedicated modem.  I posed 
  26961. > the question to our telco and they responded saying it was possible to 
  26962. > assign a POTS number to a trunk but they could not remove it from the 
  26963. > "main" hunt group.
  26964.  
  26965. You can assign multiple numbers to a hunt, to hunt in on.  You can put
  26966. multiple trunk groups into a hunt as well, but most switches have a limit
  26967. to the number of trunk groups per hunt (4 maybe?).
  26968.  
  26969.  
  26970.  
  26971.  
  26972. > 
  26973. > I, however, have a feeling that they either aren't telling me the truth or 
  26974. > they don't know.
  26975. > 
  26976. > Is anybody else doing anything like this?  Another scenario might be two 
  26977. > distinct separate hunt groups composed of, say, 12 and 11 channels each. 
  26978. >  Does anybody know if this is possible?
  26979. > 
  26980. > Matthew...
  26981. > 
  26982. > 
  26983. > -
  26984. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26985. >  with "unsubscribe usr-tc" in the body of the message.
  26986. >  For information on digests or retrieving files and old messages send
  26987. >  "help" to the same address.  Do not use quotes in your message.
  26988. > 
  26989.  
  26990. Brian Feeny (BF304)     signal@shreve.net   
  26991. 318-222-2638 x 109    http://www.shreve.net/~signal      
  26992. Network Administrator   ShreveNet Inc. (ASN 11881)           
  26993.  
  26994.  
  26995. -
  26996.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  26997.  with "unsubscribe usr-tc" in the body of the message.
  26998.  For information on digests or retrieving files and old messages send
  26999.  "help" to the same address.  Do not use quotes in your message.
  27000.  
  27001.  
  27002. -------------------------------------------------------------------------------
  27003.  
  27004. From: matthews <matthews@brunnet.net>
  27005. Subject: RE: (usr-tc) multiple hunt groups on a single trunk group
  27006. Date: 23 Mar 1999 17:11:20 -0400
  27007.  
  27008. On Tuesday, March 23, 1999 4:58 PM, Brian [SMTP:signal@shreve.net] wrote:
  27009. >
  27010. > You can assign multiple numbers to a hunt, to hunt in on.  You can put
  27011. > multiple trunk groups into a hunt as well, but most switches have a limit
  27012. > to the number of trunk groups per hunt (4 maybe?).
  27013. >
  27014.  
  27015. What I'd like to do is somewhat the opposite of that.  We have one "main 
  27016. number" that customers dial to get access to some 300 lines, composed of 
  27017. PRI trunk groups.  What I'd like to do is remove one of those ds0's from 
  27018. the main group, assign a POTS number to it, and give it to a customer as a 
  27019. "dedicated" line.  Telco says it's not possible...but...
  27020.  
  27021. >
  27022. >
  27023. > >
  27024. > > I, however, have a feeling that they either aren't telling me the truth 
  27025. or
  27026. > > they don't know.
  27027. > >
  27028. > > Is anybody else doing anything like this?  Another scenario might be 
  27029. two
  27030. > > distinct separate hunt groups composed of, say, 12 and 11 channels 
  27031. each.
  27032. > >  Does anybody know if this is possible?
  27033. > >
  27034. > > Matthew...
  27035. > >
  27036. > >
  27037. > > -
  27038. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27039. > >  with "unsubscribe usr-tc" in the body of the message.
  27040. > >  For information on digests or retrieving files and old messages send
  27041. > >  "help" to the same address.  Do not use quotes in your message.
  27042. > >
  27043. >
  27044. > -----------------------------------------------------
  27045. > Brian Feeny (BF304)     signal@shreve.net
  27046. > 318-222-2638 x 109    http://www.shreve.net/~signal
  27047. > Network Administrator   ShreveNet Inc. (ASN 11881)     
  27048. >
  27049. >
  27050. > -
  27051. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27052. >  with "unsubscribe usr-tc" in the body of the message.
  27053. >  For information on digests or retrieving files and old messages send
  27054. >  "help" to the same address.  Do not use quotes in your message.
  27055.  
  27056.  
  27057.  
  27058.  
  27059. -
  27060.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27061.  with "unsubscribe usr-tc" in the body of the message.
  27062.  For information on digests or retrieving files and old messages send
  27063.  "help" to the same address.  Do not use quotes in your message.
  27064.  
  27065.  
  27066. -------------------------------------------------------------------------------
  27067.  
  27068. From: Jeff Soetemans <jsoets@oxford.net>
  27069. Subject: Re: (usr-tc) multiple hunt groups on a single trunk group
  27070. Date: 23 Mar 1999 16:38:22 -0500
  27071.  
  27072.  
  27073.  
  27074. matthews wrote:
  27075.  
  27076. > Is it typically possible to do multiple independant hunt groups within a
  27077. > single trunk group?  We would like to dedicate one channel to a customer
  27078. > who would dial a distinct phone number to get his dedicated modem.  I posed
  27079. > the question to our telco and they responded saying it was possible to
  27080. > assign a POTS number to a trunk but they could not remove it from the
  27081. > "main" hunt group.
  27082. >
  27083. > I, however, have a feeling that they either aren't telling me the truth or
  27084. > they don't know.
  27085. >
  27086. > Is anybody else doing anything like this?  Another scenario might be two
  27087. > distinct separate hunt groups composed of, say, 12 and 11 channels each.
  27088. >  Does anybody know if this is possible?
  27089.  
  27090. >
  27091. > Yes, that definitely is possible. I work for an independant telco and we are
  27092. > also an ISP and we are doing the exact thing you want to do. We have
  27093. > dedicated accounts where the customer gets there own number to dial which
  27094. > gives them there own modem (the same modem each time that is associated with
  27095. > the timeslot on the incoming  T1.)  The telco needs to build a new CLLI for
  27096. > each Number and point it to a specific trunk (DTC) The DTC is what supplies
  27097. > the T1 signal to the RAS so you can point a call to any modem you want. As
  27098. > far as removing the modem from the original modem pool and using it for this
  27099. > dedicated number it's very simple, but they probably just won't want to do
  27100. > it.
  27101.  
  27102. Jeff
  27103.  
  27104.  
  27105. > Matthew...
  27106. >
  27107. > -
  27108. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27109. >  with "unsubscribe usr-tc" in the body of the message.
  27110. >  For information on digests or retrieving files and old messages send
  27111. >  "help" to the same address.  Do not use quotes in your message.
  27112.  
  27113.  
  27114. -
  27115.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27116.  with "unsubscribe usr-tc" in the body of the message.
  27117.  For information on digests or retrieving files and old messages send
  27118.  "help" to the same address.  Do not use quotes in your message.
  27119.  
  27120.  
  27121. -------------------------------------------------------------------------------
  27122.  
  27123. From: "Michael E. Ezzell" <mezzell@networkacg.com>
  27124. Subject: RE: (usr-tc) multiple hunt groups on a single trunk group
  27125. Date: 23 Mar 1999 16:00:32 -0600
  27126.  
  27127. My telco has been able to do this (with a 5E switch) ... On Three PRIs...
  27128. create four trunk groups:
  27129.  
  27130. The first 22 circuits of each PRI are all bundled into one trunk group of 66
  27131. members, yet, the D-channels are not pooled.  One telephone number hits any
  27132. of these 66 lines.
  27133.  
  27134. The 23rd B-channel of each PRI is in its own trunk group, and each one has
  27135. its own telephone number.
  27136.  
  27137. So, dialing the main number gets you the big pool, and the individual
  27138. numbers always get the single dedicated channel.
  27139.  
  27140.  
  27141.  
  27142. > -----Original Message-----
  27143. > From: matthews [mailto:matthews@brunnet.net]
  27144. > Sent: Tuesday, March 23, 1999 3:11 PM
  27145. > To: 'usr-tc@lists.xmission.com'
  27146. > Subject: RE: (usr-tc) multiple hunt groups on a single trunk group
  27147. > 
  27148. > 
  27149. > On Tuesday, March 23, 1999 4:58 PM, Brian 
  27150. > [SMTP:signal@shreve.net] wrote:
  27151. > >
  27152. > > You can assign multiple numbers to a hunt, to hunt in on.  
  27153. > You can put
  27154. > > multiple trunk groups into a hunt as well, but most 
  27155. > switches have a limit
  27156. > > to the number of trunk groups per hunt (4 maybe?).
  27157. > >
  27158. > 
  27159. > What I'd like to do is somewhat the opposite of that.  We 
  27160. > have one "main 
  27161. > number" that customers dial to get access to some 300 lines, 
  27162. > composed of 
  27163. > PRI trunk groups.  What I'd like to do is remove one of those 
  27164. > ds0's from 
  27165. > the main group, assign a POTS number to it, and give it to a 
  27166. > customer as a 
  27167. > "dedicated" line.  Telco says it's not possible...but...
  27168. > 
  27169.  
  27170. -
  27171.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27172.  with "unsubscribe usr-tc" in the body of the message.
  27173.  For information on digests or retrieving files and old messages send
  27174.  "help" to the same address.  Do not use quotes in your message.
  27175.  
  27176.  
  27177. -------------------------------------------------------------------------------
  27178.  
  27179. From: jeff.binkley@asacomp.com (Jeff Binkley)
  27180. Subject: (usr-tc) multiple hunt groups on a single trunk group
  27181. Date: 23 Mar 1999 16:48:00 -0500
  27182.  
  27183.  
  27184. -> Is it typically possible to do multiple independant hunt groups within a
  27185. -> single trunk group?  We would like to dedicate one channel to a customer who
  27186. -> would dial a distinct phone number to get his dedicated modem.  I posed the
  27187. -> question to our telco and they responded saying it was possible to assign a
  27188. -> POTS number to a trunk but they could not remove it from the "main" hunt
  27189. -> group.
  27190. ->
  27191. -> I, however, have a feeling that they either aren't telling me the truth or
  27192. -> they don't know.
  27193. ->
  27194. -> Is anybody else doing anything like this?  Another scenario might be two
  27195. -> distinct separate hunt groups composed of, say, 12 and 11 channels each.
  27196. -> Does anybody know if this is possible?
  27197.  
  27198. Yes, but you do it within the TC chassis itself.  If you are running HiPerArcs
  27199. you can use modem groups to accomplish this.  I have found it easier to do with
  27200. quads and the dual pri as opposed to the HiPerDSPs, although the new DNIS
  27201. screening may be the answer there.  We have multiple phone numbers assigned to
  27202. our hunt.  Some we use like you ask, some we use for specific functions (i.e.
  27203. 800 billing and signup servers) and others can be used to route to a specific
  27204. host (i.e. BBS etc..) or be limited to certain modems.  The trick here is
  27205. to not have the same number of modems in your main modem group as you
  27206. have incoming channels, otherwise you can't dedicate a connection. Once you
  27207. get to a certain quantity, watch the LEC want you to buy a block of numbers
  27208. instead of individual numbers.
  27209.  
  27210.  
  27211. Jeff Binkley
  27212. ASA Network Computing
  27213.  
  27214. -
  27215.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27216.  with "unsubscribe usr-tc" in the body of the message.
  27217.  For information on digests or retrieving files and old messages send
  27218.  "help" to the same address.  Do not use quotes in your message.
  27219.  
  27220.  
  27221. -------------------------------------------------------------------------------
  27222.  
  27223. From: Brian <signal@shreve.net>
  27224. Subject: (usr-tc) NFAS on HDM's
  27225. Date: 23 Mar 1999 17:04:43 -0600 (EST)
  27226.  
  27227.  
  27228. Ok, our telco screwed up an order we had for 12 PRI's and gave us:
  27229.  
  27230. PRI 1        23B+D
  27231. PRI 2-12    24B
  27232.  
  27233. So I will have to run NFAS for a week or so until they can reconfigure.
  27234.  
  27235. I did not see any info on NFAS in my dated HDM documentation.  Please
  27236. don't tell me the HDM's cannot do NFAS :).
  27237.  
  27238. Usually, with NFAS, their is like an NFAS ID that you give each PRI to
  27239. tell it where the D channel is at.  Is this just the slot number of the
  27240. SPAN that has a D channel?  Or is this some sort of code you get from the
  27241. telco?
  27242.  
  27243. Thanks.
  27244.  
  27245. Brian
  27246.  
  27247.  
  27248. Brian Feeny (BF304)     signal@shreve.net   
  27249. 318-222-2638 x 109    http://www.shreve.net/~signal      
  27250. Network Administrator   ShreveNet Inc. (ASN 11881)           
  27251.  
  27252.  
  27253. -
  27254.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27255.  with "unsubscribe usr-tc" in the body of the message.
  27256.  For information on digests or retrieving files and old messages send
  27257.  "help" to the same address.  Do not use quotes in your message.
  27258.  
  27259.  
  27260. -------------------------------------------------------------------------------
  27261.  
  27262. From: Stephen Amadei <amadei@mail.dandy.net>
  27263. Subject: Re: (usr-tc) NFAS on HDM's
  27264. Date: 23 Mar 1999 19:08:35 -0500 (EST)
  27265.  
  27266. On Tue, 23 Mar 1999, Brian wrote:
  27267.  
  27268. > So I will have to run NFAS for a week or so until they can reconfigure.
  27269. > 
  27270. > I did not see any info on NFAS in my dated HDM documentation.  Please
  27271. > don't tell me the HDM's cannot do NFAS :).
  27272. > 
  27273. > Usually, with NFAS, their is like an NFAS ID that you give each PRI to
  27274. > tell it where the D channel is at.  Is this just the slot number of the
  27275. > SPAN that has a D channel?  Or is this some sort of code you get from the
  27276. > telco?
  27277.  
  27278. The Total Control doesn't support NFAS.  It is did, I'd used it on all my
  27279. PRIs... (well, except the first... ;-) )
  27280.  
  27281.                     ----Steve
  27282. Stephen Amadei
  27283. Director of MIS
  27284. Dandy Connections, Inc.
  27285. Atlantic City, NJ
  27286.  
  27287.  
  27288. -
  27289.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27290.  with "unsubscribe usr-tc" in the body of the message.
  27291.  For information on digests or retrieving files and old messages send
  27292.  "help" to the same address.  Do not use quotes in your message.
  27293.  
  27294.  
  27295. -------------------------------------------------------------------------------
  27296.  
  27297. From: MegaZone <megazone@megazone.org>
  27298. Subject: Re: (usr-tc) NFAS on HDM's
  27299. Date: 23 Mar 1999 15:48:55 -0800 (PST)
  27300.  
  27301. Once upon a time Brian shaped the electrons to say...
  27302. >Ok, our telco screwed up an order we had for 12 PRI's and gave us:
  27303. >
  27304. >PRI 1        23B+D
  27305. >PRI 2-12    24B
  27306. >
  27307. >So I will have to run NFAS for a week or so until they can reconfigure.
  27308. >
  27309. >I did not see any info on NFAS in my dated HDM documentation.  Please
  27310. >don't tell me the HDM's cannot do NFAS :).
  27311.  
  27312. The HDMs do not do NFAS yet.
  27313.  
  27314. -MZ
  27315. -- 
  27316. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  27317. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  27318. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  27319. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  27320. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  27321.  
  27322. -
  27323.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27324.  with "unsubscribe usr-tc" in the body of the message.
  27325.  For information on digests or retrieving files and old messages send
  27326.  "help" to the same address.  Do not use quotes in your message.
  27327.  
  27328.  
  27329. -------------------------------------------------------------------------------
  27330.  
  27331. From: Aaron Nabil <nabil@spiritone.com>
  27332. Subject: Re: (usr-tc) multiple hunt groups on a single trunk group
  27333. Date: 23 Mar 1999 16:23:13 -0800 (PST)
  27334.  
  27335. Michael E. Ezzell writes...
  27336. >My telco has been able to do this (with a 5E switch) ... On Three PRIs...
  27337. >create four trunk groups:
  27338. >
  27339. >The first 22 circuits of each PRI are all bundled into one trunk group of 66
  27340. >members, yet, the D-channels are not pooled.  One telephone number hits any
  27341. >of these 66 lines.
  27342. >
  27343. >The 23rd B-channel of each PRI is in its own trunk group, and each one has
  27344. >its own telephone number.
  27345. >
  27346. >So, dialing the main number gets you the big pool, and the individual
  27347. >numbers always get the single dedicated channel.
  27348.  
  27349. We do somthing simliar with both our US WEST and CLEC lines.  Our pools
  27350. are like -XX00, which  points to one big trunk group which contains all of our
  27351. lines.  The -XX01, -XX02, to XX0n numbers point to trunk groups which only
  27352. contain the trunks present on any particular T1.  Makes testing much 
  27353. easier, I can't imagine not having our lines set up this way.
  27354.  
  27355. If you switch isn't limited in how many trunk groups can be in a hunt group, 
  27356. you could just string the small trunk groups together.  Although it takes
  27357. a bit more explaining in the ordering process, I'd suggest that it's better 
  27358. if you can put them into two separate trunk groups as described.
  27359.  
  27360. With the CLEC, we also have different hunting on both.  If you call the XX00
  27361. main number, the calls are distributed sequentially across all of the
  27362. trunks in the group so the chassis fill evenly and distribute the load.  If 
  27363. you call the XX01 number it's just normal LO to HI fill limited to those
  27364. 23 or 24 trunks.
  27365.  
  27366.  
  27367. -- 
  27368. Aaron Nabil
  27369.  
  27370. -
  27371.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27372.  with "unsubscribe usr-tc" in the body of the message.
  27373.  For information on digests or retrieving files and old messages send
  27374.  "help" to the same address.  Do not use quotes in your message.
  27375.  
  27376.  
  27377. -------------------------------------------------------------------------------
  27378.  
  27379. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  27380. Subject: Re: (usr-tc) NFAS on HDM's
  27381. Date: 23 Mar 1999 19:45:25 -0600 (CST)
  27382.  
  27383. On Tue, 23 Mar 1999, Brian wrote:
  27384.  
  27385. > 
  27386. > Ok, our telco screwed up an order we had for 12 PRI's and gave us:
  27387. > 
  27388. > PRI 1        23B+D
  27389. > PRI 2-12    24B
  27390. > 
  27391. > So I will have to run NFAS for a week or so until they can reconfigure.
  27392. > 
  27393. > I did not see any info on NFAS in my dated HDM documentation.  Please
  27394. > don't tell me the HDM's cannot do NFAS :).
  27395. > 
  27396.  
  27397. Currently the release code of HDM do not support NFAS.  The NFAS code for 
  27398. DSP is in beta.  You can if you wish try the beta code.
  27399.  
  27400. krish
  27401.  
  27402.  
  27403. > Usually, with NFAS, their is like an NFAS ID that you give each PRI to
  27404. > tell it where the D channel is at.  Is this just the slot number of the
  27405. > SPAN that has a D channel?  Or is this some sort of code you get from the
  27406. > telco?
  27407. > 
  27408. > Thanks.
  27409. > 
  27410. > Brian
  27411. > 
  27412. > 
  27413. > -----------------------------------------------------
  27414. > Brian Feeny (BF304)     signal@shreve.net   
  27415. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  27416. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  27417. > 
  27418. > 
  27419. > -
  27420. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27421. >  with "unsubscribe usr-tc" in the body of the message.
  27422. >  For information on digests or retrieving files and old messages send
  27423. >  "help" to the same address.  Do not use quotes in your message.
  27424. > 
  27425.  
  27426. -
  27427.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27428.  with "unsubscribe usr-tc" in the body of the message.
  27429.  For information on digests or retrieving files and old messages send
  27430.  "help" to the same address.  Do not use quotes in your message.
  27431.  
  27432.  
  27433. -------------------------------------------------------------------------------
  27434.  
  27435. From: zip-usrtc@ran.zipcon.net
  27436. Subject: (usr-tc) Buying 1st USR-TC
  27437. Date: 23 Mar 1999 19:08:00 -0800
  27438.  
  27439. I'm about to purchase my first USR TC (HiPer bundle) and have been
  27440. contemplating the support issue.  I've read that the USR boxes generate
  27441. a lot of heat and have a higher failure rate than most other access
  27442. servers.  Is there a consensus among list members on whether or not to
  27443. purchase the support contract?  Thanks, Dan
  27444.  
  27445. -
  27446.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27447.  with "unsubscribe usr-tc" in the body of the message.
  27448.  For information on digests or retrieving files and old messages send
  27449.  "help" to the same address.  Do not use quotes in your message.
  27450.  
  27451.  
  27452. -------------------------------------------------------------------------------
  27453.  
  27454. From: Brian <signal@shreve.net>
  27455. Subject: Re: (usr-tc) NFAS on HDM's
  27456. Date: 23 Mar 1999 21:05:40 -0600 (EST)
  27457.  
  27458. On Tue, 23 Mar 1999, Tatai SV Krishnan wrote:
  27459.  
  27460. > On Tue, 23 Mar 1999, Brian wrote:
  27461. > 
  27462. > > 
  27463. > > Ok, our telco screwed up an order we had for 12 PRI's and gave us:
  27464. > > 
  27465. > > PRI 1        23B+D
  27466. > > PRI 2-12    24B
  27467. > > 
  27468. > > So I will have to run NFAS for a week or so until they can reconfigure.
  27469. > > 
  27470. > > I did not see any info on NFAS in my dated HDM documentation.  Please
  27471. > > don't tell me the HDM's cannot do NFAS :).
  27472. > > 
  27473. > 
  27474. > Currently the release code of HDM do not support NFAS.  The NFAS code for 
  27475. > DSP is in beta.  You can if you wish try the beta code.
  27476.  
  27477. Ok, I will find out but I don't think we want to go this route, since we
  27478. will be reloading a new codebase after they fix the circuits.  Thanks for
  27479. the info though thats good to know.
  27480.  
  27481.  
  27482. > 
  27483. > krish
  27484. > 
  27485. > 
  27486. > > Usually, with NFAS, their is like an NFAS ID that you give each PRI to
  27487. > > tell it where the D channel is at.  Is this just the slot number of the
  27488. > > SPAN that has a D channel?  Or is this some sort of code you get from the
  27489. > > telco?
  27490. > > 
  27491. > > Thanks.
  27492. > > 
  27493. > > Brian
  27494. > > 
  27495. > > 
  27496. > > -----------------------------------------------------
  27497. > > Brian Feeny (BF304)     signal@shreve.net   
  27498. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  27499. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  27500. > > 
  27501. > > 
  27502. > > -
  27503. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27504. > >  with "unsubscribe usr-tc" in the body of the message.
  27505. > >  For information on digests or retrieving files and old messages send
  27506. > >  "help" to the same address.  Do not use quotes in your message.
  27507. > > 
  27508. > 
  27509.  
  27510. Brian Feeny (BF304)     signal@shreve.net   
  27511. 318-222-2638 x 109    http://www.shreve.net/~signal      
  27512. Network Administrator   ShreveNet Inc. (ASN 11881)           
  27513.  
  27514.  
  27515. -
  27516.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27517.  with "unsubscribe usr-tc" in the body of the message.
  27518.  For information on digests or retrieving files and old messages send
  27519.  "help" to the same address.  Do not use quotes in your message.
  27520.  
  27521.  
  27522. -------------------------------------------------------------------------------
  27523.  
  27524. From: Bryan Wann <bwann@cwis.net>
  27525. Subject: Re: (usr-tc) Buying 1st USR-TC
  27526. Date: 23 Mar 1999 21:35:33 -0600 (CST)
  27527.  
  27528. On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote:
  27529.  
  27530. > I'm about to purchase my first USR TC (HiPer bundle) and have been
  27531. > contemplating the support issue.  I've read that the USR boxes generate
  27532. > a lot of heat and have a higher failure rate than most other access
  27533. > servers.  Is there a consensus among list members on whether or not to
  27534. > purchase the support contract?  Thanks, Dan
  27535.  
  27536. Congrats.. I love our HiPer setup, buying two more racks in next 2 months.
  27537.  
  27538. It may be worthwhile for the first chassis.. that way you can get access
  27539. to code revisions.  Past 2 DSP releases have been 'free' but who knows how
  27540. long that will last.  
  27541.  
  27542. wrt heat, the HiPer DSPs run a lot cooler than a bunch of quads from what
  27543. I have seen.  
  27544.  
  27545. I don't have enough TC racks nor do I have very long term experience (we
  27546. put our first HiPer into service in Janurary), so I can't comment on
  27547. "higher failure rate".  I have had only one problem with our HiPer ARC,
  27548. where the flash was either corrupted or just plain lost it, had to
  27549. re-upload it... haven't done a proper post-mortem to find out why tho.
  27550.  
  27551.  
  27552.  
  27553.  
  27554. ---
  27555. Bryan Wann        bwann@cwis.net    
  27556. CWIS Internet Services    http://www.cwis.net 918-967-2858
  27557.  
  27558. Give a man a fish, he eats for a day;
  27559. Teach a man to fish, he eats for a lifetime;
  27560. Enlighten him further, and he opens a chain of seafood restaurants
  27561.  
  27562.  
  27563. -
  27564.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27565.  with "unsubscribe usr-tc" in the body of the message.
  27566.  For information on digests or retrieving files and old messages send
  27567.  "help" to the same address.  Do not use quotes in your message.
  27568.  
  27569.  
  27570. -------------------------------------------------------------------------------
  27571.  
  27572. From: "Brian A. Burgmeier" <brianb@ntwrld.com>
  27573. Subject: (usr-tc) Modems
  27574. Date: 23 Mar 1999 21:06:49 -0700
  27575.  
  27576. Could someone recommend a decent low cost v90 modem that works well with USR
  27577. Total Control HiPer Arcs?  Where can I find them and how much?  We need 100+
  27578. modems for a promo we are doing.
  27579.  
  27580. Thanks-Brian
  27581.  
  27582.  
  27583. -
  27584.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27585.  with "unsubscribe usr-tc" in the body of the message.
  27586.  For information on digests or retrieving files and old messages send
  27587.  "help" to the same address.  Do not use quotes in your message.
  27588.  
  27589.  
  27590. -------------------------------------------------------------------------------
  27591.  
  27592. From: Jeff Mcadams <jeffm@iglou.com>
  27593. Subject: Re: (usr-tc) NFAS on HDM's
  27594. Date: 23 Mar 1999 23:00:57 -0500 (EST)
  27595.  
  27596. Thus spake Brian
  27597. >Ok, our telco screwed up an order we had for 12 PRI's and gave us:
  27598.  
  27599. >PRI 1        23B+D
  27600. >PRI 2-12    24B
  27601.  
  27602. >So I will have to run NFAS for a week or so until they can reconfigure.
  27603.  
  27604. >I did not see any info on NFAS in my dated HDM documentation.  Please
  27605. >don't tell me the HDM's cannot do NFAS :).
  27606.  
  27607. OK, I won't tell you that...but that will leave this message pretty much
  27608. devoid of much content.  :)
  27609.  
  27610. >Usually, with NFAS, their is like an NFAS ID that you give each PRI to
  27611. >tell it where the D channel is at.  Is this just the slot number of the
  27612. >SPAN that has a D channel?  Or is this some sort of code you get from the
  27613. >telco?
  27614.  
  27615. You would assign each PRI a facility number, and the facility number
  27616. would be used in the call setup information on the D channel along with
  27617. the timeslot of that facility, indicating to the receiving unit which
  27618. span and timeslot the call is on, rather than with facility associated
  27619. signaling, where the span is already known, just the span.
  27620. -- 
  27621. Jeff McAdams                            Email: jeffm@iglou.com
  27622. Head Network Administrator              Voice: (502) 966-3848
  27623. IgLou Internet Services                        (800) 436-4456
  27624.  
  27625. -
  27626.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27627.  with "unsubscribe usr-tc" in the body of the message.
  27628.  For information on digests or retrieving files and old messages send
  27629.  "help" to the same address.  Do not use quotes in your message.
  27630.  
  27631.  
  27632. -------------------------------------------------------------------------------
  27633.  
  27634. From: Jeff Mcadams <jeffm@iglou.com>
  27635. Subject: Re: (usr-tc) NFAS on HDM's
  27636. Date: 23 Mar 1999 23:02:14 -0500 (EST)
  27637.  
  27638. Thus spake Stephen Amadei
  27639. >On Tue, 23 Mar 1999, Brian wrote:
  27640. >> So I will have to run NFAS for a week or so until they can reconfigure.
  27641. >> 
  27642. >> I did not see any info on NFAS in my dated HDM documentation.  Please
  27643. >> don't tell me the HDM's cannot do NFAS :).
  27644. >> 
  27645. >> Usually, with NFAS, their is like an NFAS ID that you give each PRI to
  27646. >> tell it where the D channel is at.  Is this just the slot number of the
  27647. >> SPAN that has a D channel?  Or is this some sort of code you get from the
  27648. >> telco?
  27649.  
  27650. >The Total Control doesn't support NFAS.  It is did, I'd used it on all my
  27651. >PRIs... (well, except the first... ;-) )
  27652.  
  27653. Well, that's not *entirely* true, as the dual-pri cards will do NFAS
  27654. between the two PRI's on the card itself...nothing at this time in TC's
  27655. will do cross-card NFAS or certainly cross-chassis.
  27656. -- 
  27657. Jeff McAdams                            Email: jeffm@iglou.com
  27658. Head Network Administrator              Voice: (502) 966-3848
  27659. IgLou Internet Services                        (800) 436-4456
  27660.  
  27661. -
  27662.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27663.  with "unsubscribe usr-tc" in the body of the message.
  27664.  For information on digests or retrieving files and old messages send
  27665.  "help" to the same address.  Do not use quotes in your message.
  27666.  
  27667.  
  27668. -------------------------------------------------------------------------------
  27669.  
  27670. From: Jeff Mcadams <jeffm@iglou.com>
  27671. Subject: Re: (usr-tc) Buying 1st USR-TC
  27672. Date: 23 Mar 1999 23:04:20 -0500 (EST)
  27673.  
  27674. Thus spake zip-usrtc@ran.zipcon.net
  27675. >Is there a consensus among list members on whether or not to
  27676. >purchase the support contract?
  27677.  
  27678. For a single chassis, you're probably ok.  When you start getting
  27679. bigger, and want to only support selected equipment...sorry 'bout your
  27680. luck.
  27681.  
  27682. 3Com's support contracts have to be about the *worst* abomination I've
  27683. ever seen.  The restrictions that are put on them are insane, and the
  27684. pricing is even worse, if that's possible.
  27685. -- 
  27686. Jeff McAdams                            Email: jeffm@iglou.com
  27687. Head Network Administrator              Voice: (502) 966-3848
  27688. IgLou Internet Services                        (800) 436-4456
  27689.  
  27690. -
  27691.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27692.  with "unsubscribe usr-tc" in the body of the message.
  27693.  For information on digests or retrieving files and old messages send
  27694.  "help" to the same address.  Do not use quotes in your message.
  27695.  
  27696.  
  27697. -------------------------------------------------------------------------------
  27698.  
  27699. From: Charles Sprickman <spork@inch.com>
  27700. Subject: Re: (usr-tc) Buying 1st USR-TC
  27701. Date: 23 Mar 1999 23:06:46 -0500 (EST)
  27702.  
  27703. FWIW, out of seven chassis, we've averaged at least one failure in each.
  27704. Most common were the quads.  We also had a bad chassis, bad DSP
  27705. (wacked-out flash), and two toasted NMC cards.  This is all in a
  27706. climate-controlled telco environment.  As for heat, they aren't too bad
  27707. really.  PSI colos some TNTs near us, and the exhaust feels like a hair
  27708. dryer on low.  Ours run from 21 to 27 degrees celsius, 27 being the top
  27709. of the rack.  We're right next to a big Liebert chiller.
  27710.  
  27711. As for the contract, forget about the support.  This list is the best
  27712. you'll find.  Get a good reseller (Source was good at replacing early
  27713. failures).  With the quads, it was easy to handle losing a card or two,
  27714. it's a bit more of a gamble with the new high density stuff...
  27715.  
  27716. Good Luck,
  27717.  
  27718. Charles
  27719.  
  27720. -- 
  27721. =-----------------=                                        = 
  27722. | Charles Sprickman                       Internet Channel |
  27723. | INCH System Administration Team         (212)243-5200    |
  27724. | spork@inch.com                          access@inch.com  |
  27725. =                                         =----------------=
  27726.  
  27727. On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote:
  27728.  
  27729. > I'm about to purchase my first USR TC (HiPer bundle) and have been
  27730. > contemplating the support issue.  I've read that the USR boxes generate
  27731. > a lot of heat and have a higher failure rate than most other access
  27732. > servers.  Is there a consensus among list members on whether or not to
  27733. > purchase the support contract?  Thanks, Dan
  27734. > 
  27735. > -
  27736. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27737. >  with "unsubscribe usr-tc" in the body of the message.
  27738. >  For information on digests or retrieving files and old messages send
  27739. >  "help" to the same address.  Do not use quotes in your message.
  27740. > 
  27741.  
  27742.  
  27743. -
  27744.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27745.  with "unsubscribe usr-tc" in the body of the message.
  27746.  For information on digests or retrieving files and old messages send
  27747.  "help" to the same address.  Do not use quotes in your message.
  27748.  
  27749.  
  27750. -------------------------------------------------------------------------------
  27751.  
  27752. From: Ricky Beam <jfbeam@beaker.interpath.net>
  27753. Subject: Re: (usr-tc) NFAS on HDM's
  27754. Date: 23 Mar 1999 23:24:13 -0500 (EST)
  27755.  
  27756. On Tue, 23 Mar 1999, Stephen Amadei wrote:
  27757. >The Total Control doesn't support NFAS.  It is did, I'd used it on all my
  27758. >PRIs... (well, except the first... ;-) )
  27759.  
  27760. The Dual PRI has always had NFAS (on that card anyway.)  The released HDSP
  27761. doesn't have NFAS, however, it's in beta if you're brave :-)
  27762.  
  27763. --Ricky
  27764.  
  27765.  
  27766.  
  27767. -
  27768.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27769.  with "unsubscribe usr-tc" in the body of the message.
  27770.  For information on digests or retrieving files and old messages send
  27771.  "help" to the same address.  Do not use quotes in your message.
  27772.  
  27773.  
  27774. -------------------------------------------------------------------------------
  27775.  
  27776. From: Ricky Beam <jfbeam@beaker.interpath.net>
  27777. Subject: Re: (usr-tc) Buying 1st USR-TC
  27778. Date: 23 Mar 1999 23:34:05 -0500 (EST)
  27779.  
  27780. On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote:
  27781. >I'm about to purchase my first USR TC (HiPer bundle) and have been
  27782. >contemplating the support issue.  I've read that the USR boxes generate
  27783. >a lot of heat and have a higher failure rate than most other access
  27784. >servers.  Is there a consensus among list members on whether or not to
  27785. >purchase the support contract?  Thanks, Dan
  27786.  
  27787. I've never seen that to be true... one rack with 7 full quad modem chassis.
  27788. (They were literally touching each other.)  The air intake was 68dF and out
  27789. at the top was 74dF.  They were those racks with the integrated fan tray and
  27790. 90% the modems in the entire rack were active for hours.
  27791.  
  27792. I've never had much of a failure rate out of the hardware.  A few modem cards
  27793. have failed.  One netserver failed.  T1 NICs are a different story -- damned
  27794. lightening.  (over a period of two years.)
  27795.  
  27796. --Ricky
  27797.  
  27798.  
  27799.  
  27800. -
  27801.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27802.  with "unsubscribe usr-tc" in the body of the message.
  27803.  For information on digests or retrieving files and old messages send
  27804.  "help" to the same address.  Do not use quotes in your message.
  27805.  
  27806.  
  27807. -------------------------------------------------------------------------------
  27808.  
  27809. From: Ricky Beam <jfbeam@beaker.interpath.net>
  27810. Subject: Re: (usr-tc) Buying 1st USR-TC
  27811. Date: 23 Mar 1999 23:41:11 -0500 (EST)
  27812.  
  27813. On Tue, 23 Mar 1999, Bryan Wann wrote:
  27814. >On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote:
  27815. >It may be worthwhile for the first chassis.. that way you can get access
  27816. >to code revisions.  Past 2 DSP releases have been 'free' but who knows how
  27817. >long that will last.  
  27818.  
  27819. You idiot.  That's why the support contracts are so [bleep] expensive. 3Com
  27820. isn't that stupid either; if you have more than one chassis, you have to
  27821. buy support for all of them.
  27822.  
  27823. As for contracts, pay for the software support contract.  The hardware is
  27824. more than stable enough to deal with the "factory" warantee (takes awhile
  27825. to get the broken stuff replaced) or "per incedent" for things no longer
  27826. under warantee.  (I even got a netserver replaced one week after they
  27827. discontinued the netserver... for free -- it was still under factory
  27828. warantee.)
  27829.  
  27830. >"higher failure rate".  I have had only one problem with our HiPer ARC,
  27831. >where the flash was either corrupted or just plain lost it, had to
  27832. >re-upload it... haven't done a proper post-mortem to find out why tho.
  27833.  
  27834. And that's easy enough to reflash assuming you have a "bulk configuration"
  27835. file around somewhere.
  27836.  
  27837. --Ricky
  27838.  
  27839.  
  27840.  
  27841. -
  27842.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27843.  with "unsubscribe usr-tc" in the body of the message.
  27844.  For information on digests or retrieving files and old messages send
  27845.  "help" to the same address.  Do not use quotes in your message.
  27846.  
  27847.  
  27848. -------------------------------------------------------------------------------
  27849.  
  27850. From: Robert Reynolds <lists@lcii.net>
  27851. Subject: Re: (usr-tc) Buying 1st USR-TC
  27852. Date: 24 Mar 1999 00:17:51 -0600 (EST)
  27853.  
  27854. On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote:
  27855.  
  27856. > I'm about to purchase my first USR TC (HiPer bundle) and have been
  27857. > contemplating the support issue.  I've read that the USR boxes generate
  27858. > a lot of heat and have a higher failure rate than most other access
  27859. > servers.  Is there a consensus among list members on whether or not to
  27860. > purchase the support contract?  Thanks, Dan
  27861.  
  27862. I've had good luck with our HiPer's.  I bought 2 of the 48 port bundels
  27863. just so I would have a spare NMC and ARC card.  Nice to have 2 power
  27864. supplies as well.  As for heat, I haven't noticed it.  Mine runs at a
  27865. constant 70-73 degress.  They are noisy, but I don't sit in the same room
  27866. with them.
  27867.  
  27868. As for support.  It comes with 1 yr of free support and software updates I
  27869. believe.  I've never called their support anyway, I hear rumors it isn't
  27870. that great but I can't say for sure since I've never called.
  27871.  
  27872. Do yourself a favor and buy it from Source Technology.  It'll come with a
  27873. nice cheat sheet on getting it up and running.  I had mine up and running
  27874. in 15-20 minutes with their documentation.  They also have their own tech
  27875. support should you ever need it. I've called their tech support two times
  27876. with a few simple questions and they called me back within 30 minutes each
  27877. time I believe.  Probably woulda been quicker had I been completly down.
  27878. Their prices are good as well.
  27879.  
  27880. For the money I don't think you can beat a HiPer. Only thing it lacks at
  27881. the moment I really want is OSPF and BACP. I know OSPF should be out soon,
  27882. anyone heard about BACP?
  27883.  
  27884.  
  27885. -
  27886.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27887.  with "unsubscribe usr-tc" in the body of the message.
  27888.  For information on digests or retrieving files and old messages send
  27889.  "help" to the same address.  Do not use quotes in your message.
  27890.  
  27891.  
  27892. -------------------------------------------------------------------------------
  27893.  
  27894. From: Paul Farber <farber@admin.f-tech.net>
  27895. Subject: (usr-tc) Filters
  27896. Date: 24 Mar 1999 01:11:46 -0500 (EST)
  27897.  
  27898. Hello all, 
  27899.  
  27900. I find myself in need of setting up some filters on a TC chassis w/5
  27901. Dsp's.
  27902.  
  27903. Our boarder router is configured to filter packets not
  27904. originating/destined for the network, but I find myself logging packets
  27905. from the ARC card that users have set up to randomly ping an IP to keep
  27906. the link alive.
  27907.  
  27908. I've looked at the filter syntax and would like a simple example to
  27909. clarify.
  27910.  
  27911. Basically I need an input filter that will pass only packets coming
  27912. from/to IP's that the PPP connections use.  There is one large pool that
  27913. goes from .100 to .230, the NMC/ARC card is .98 and .99 respectivly.
  27914.  
  27915. How can I filter that range without specific ACCEPT / DENY lines for each
  27916. IP?
  27917.  
  27918. Thanks.
  27919.  
  27920. Paul D. Farber II
  27921. Farber Technology
  27922. Ph. 570-628-5303
  27923. Fax 570-628-5545
  27924. farber@admin.f-tech.net
  27925.  
  27926.  
  27927. -
  27928.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27929.  with "unsubscribe usr-tc" in the body of the message.
  27930.  For information on digests or retrieving files and old messages send
  27931.  "help" to the same address.  Do not use quotes in your message.
  27932.  
  27933.  
  27934. -------------------------------------------------------------------------------
  27935.  
  27936. From: Stephen Amadei <amadei@mail.dandy.net>
  27937. Subject: Re: (usr-tc) NFAS on HDM's
  27938. Date: 24 Mar 1999 02:13:00 -0500 (EST)
  27939.  
  27940. On Tue, 23 Mar 1999, Ricky Beam wrote:
  27941.  
  27942. > On Tue, 23 Mar 1999, Stephen Amadei wrote:
  27943. > >The Total Control doesn't support NFAS.  It is did, I'd used it on all my
  27944. > >PRIs... (well, except the first... ;-) )
  27945. > 
  27946. > The Dual PRI has always had NFAS (on that card anyway.)  The released HDSP
  27947. > doesn't have NFAS, however, it's in beta if you're brave :-)
  27948.  
  27949. Cripes... I would have really liked to have known that... but everyone I
  27950. talked to told me the TC couldn't do NFAS at all... good to heard it will
  27951. be available on the DSP.  But beta?   No thanks...  I deal with enough
  27952. beta stuff on PCs, let alone 10K worth of dialup equipment... ;-)
  27953.  
  27954.                     ----Steve
  27955. Stephen Amadei
  27956. Director of MIS
  27957. Dandy Connections, Inc.
  27958. Atlantic City, NJ
  27959.  
  27960.  
  27961. -
  27962.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  27963.  with "unsubscribe usr-tc" in the body of the message.
  27964.  For information on digests or retrieving files and old messages send
  27965.  "help" to the same address.  Do not use quotes in your message.
  27966.  
  27967.  
  27968. -------------------------------------------------------------------------------
  27969.  
  27970. From: Mike Andrews <mandrews@termfrost.org>
  27971. Subject: (usr-tc) Disabling x2+v.90 on Quads using AT commands
  27972. Date: 24 Mar 1999 02:08:34 -0500 (EST)
  27973.  
  27974. I'll try this again...  can someone either
  27975.  
  27976. 1) Get me a copy of the output of "ATS$" executed on a Quad?  
  27977. I tried getting it via the ARC (set swi inter slot:x/mod:x at "ats$") but
  27978. it doesn't return the entire thing -- just the first half of so.  Looks
  27979. like it's too big for a buffer somewhere.
  27980.  
  27981. 2) Give me some hints as to the right settings for the S76 and S81
  27982. registers to completely kill x2 and v.90 on a Quad?  On a DSP,
  27983. S76.1=1S81.5=1 does it.  On a Quad, this does kill v.90, but it leaves
  27984. some part of x2 enabled, and 3com modems calling in don't connect -- it
  27985. sounds like one side is trying to do x2 and the other side is trying to do
  27986. v.34, and the handshake gets stuck.  (Probably a bug in the Quads?)  The
  27987. firmware release notes don't document these registers very well...
  27988.  
  27989. This is for the DNIS-based reconfiguration trick discussed earlier, which
  27990. is why I don't just use SNMP or TCM to do it...
  27991.  
  27992.  
  27993. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  27994. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  27995. Microsoft operating system is like a dog without a brick tied to its head."
  27996.  
  27997.  
  27998. -
  27999.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28000.  with "unsubscribe usr-tc" in the body of the message.
  28001.  For information on digests or retrieving files and old messages send
  28002.  "help" to the same address.  Do not use quotes in your message.
  28003.  
  28004.  
  28005. -------------------------------------------------------------------------------
  28006.  
  28007. From: "Russ Miescke" <russm@powerweb.net>
  28008. Subject: (usr-tc) Netserver Freeze
  28009. Date: 24 Mar 1999 02:09:03 -0600
  28010.  
  28011. I have a Total Control box with my last remaining Netserver card running 12
  28012. quad modems.  This box is mostly ISDN customers.  I am having a problem over
  28013. the last two days with the system "freezing" up.  This seems to happen once
  28014. or twice per day.  Customers connected to the box will see things slow down,
  28015. then stop.  Only a reboot will fix the problem.  I am running the latest
  28016. code in all cards.  This has run without a problem for several month.  I
  28017. have not touched it at all.  Any ideas?
  28018.  
  28019. Russ Miescke
  28020. Power Web Connect
  28021. russm@powerweb.net
  28022.  
  28023.  
  28024.  
  28025. -
  28026.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28027.  with "unsubscribe usr-tc" in the body of the message.
  28028.  For information on digests or retrieving files and old messages send
  28029.  "help" to the same address.  Do not use quotes in your message.
  28030.  
  28031.  
  28032. -------------------------------------------------------------------------------
  28033.  
  28034. From: K Mitchell <mitch@keyconn.net>
  28035. Subject: Re: (usr-tc) Buying 1st USR-TC
  28036. Date: 24 Mar 1999 10:26:51 -0500
  28037.  
  28038. At 07:08 PM 3/23/99 -0800, zip-usrtc@ran.zipcon.net wrote:
  28039. >I'm about to purchase my first USR TC (HiPer bundle) and have been
  28040. >contemplating the support issue.  I've read that the USR boxes generate
  28041. >a lot of heat and have a higher failure rate than most other access
  28042. >servers.  Is there a consensus among list members on whether or not to
  28043. >purchase the support contract?  Thanks, Dan
  28044.  
  28045.   I've had a HiPer chassis for almost a year now and have been pleased
  28046. overall with it. As for heat, I believe that earlier TC hardware did have a
  28047. heat problem, but it hasn't been an issue with the HiPer. It has an
  28048. integral fan tray with 9 or 12 fans that keeps it from going higher than 10
  28049. degrees or so above room temp. It's a bit loud, but I normally sit about 2
  28050. feet from it and I'm not deaf yet  :)
  28051.   I've had no failure issues at all from 1 NMC, 1 ARC, 2 DSP and will be
  28052. picking up a 3rd DSP shortly.
  28053.   I would buy it from someone like Source Technologies(888-765-5758)
  28054. instead of direct. Talk to John DeDonato and tell him I sent ya. Thier
  28055. price is likely about the cheapest you'll find and the support is better
  28056. than 3Com's. I wouldn't buy the support contract, just software upgrades.
  28057. Even at $300 per incident, w/o the contract, you won't need it much and
  28058. will save money over the TCAP contract.
  28059.  
  28060. Kirk
  28061.  
  28062.  
  28063.  
  28064. Kirk Mitchell-General Manager     sysadmin@keyconn.net
  28065. Keystone Connect                http://www.keyconn.net
  28066. Altoona, PA   814-941-5000         We Unlock the World
  28067.  
  28068.  
  28069. -
  28070.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28071.  with "unsubscribe usr-tc" in the body of the message.
  28072.  For information on digests or retrieving files and old messages send
  28073.  "help" to the same address.  Do not use quotes in your message.
  28074.  
  28075.  
  28076. -------------------------------------------------------------------------------
  28077.  
  28078. From: Brian Elfert <brian@citilink.com>
  28079. Subject: Re: (usr-tc) Buying 1st USR-TC
  28080. Date: 24 Mar 1999 10:15:08 -0600 (CST)
  28081.  
  28082.  
  28083.  
  28084. On Wed, 24 Mar 1999, K Mitchell wrote:
  28085.  
  28086. >   I've had a HiPer chassis for almost a year now and have been pleased
  28087. > overall with it. As for heat, I believe that earlier TC hardware did have a
  28088. > heat problem, but it hasn't been an issue with the HiPer. It has an
  28089. > integral fan tray with 9 or 12 fans that keeps it from going higher than 10
  28090. > degrees or so above room temp. It's a bit loud, but I normally sit about 2
  28091.  
  28092. The heat problem isn't a problem with the units getting too hot.  The
  28093. problem is simply the amount of heat generated by the units.
  28094.  
  28095. You simply should not need 12 fans to keep a NAS cool.  I have 4 of the
  28096. quad modem racks, and the temperature 18" from the rack is 78F even
  28097. though I have the A/C at 65F and the A/C blows directly towards that rack.
  28098.  
  28099. The rest of the room stays around 67F.
  28100.  
  28101. Brian
  28102.  
  28103.  
  28104. -
  28105.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28106.  with "unsubscribe usr-tc" in the body of the message.
  28107.  For information on digests or retrieving files and old messages send
  28108.  "help" to the same address.  Do not use quotes in your message.
  28109.  
  28110.  
  28111. -------------------------------------------------------------------------------
  28112.  
  28113. From: Robert von Bismarck <rvb@petrel.ch>
  28114. Subject: (usr-tc) RED alarm on HDSP but it still works
  28115. Date: 24 Mar 1999 18:31:13 +0100
  28116.  
  28117. Guys,
  28118.  
  28119. I've got a funny one here, I'm frankly lost, 3Com is stumped, and the telco
  28120. is of no help :
  28121.  
  28122. I set up a new chassis (HiperDSP 1.2.5 and ARC 4.1.59) in a remote POP. The
  28123. telco checked the lines and foudn them ready to take up the service.
  28124. We put the plug in (was some hell to find out the RJ-45 wall jacks were
  28125. cabled funny, but it works) and we got the RN/FL light on, the CAR light
  28126. off, the ALM light red, the LPBK/D-ALM light off and FAULT is off.
  28127.  
  28128. in TCM monitoring I've got this that is different from the other chassis' I
  28129. have :
  28130.  
  28131. Physical state :
  28132.  
  28133. psF3Fc2LossOfSignal(3)
  28134.  
  28135. Line Status :
  28136.  
  28137. dsx1XmtFarEndLOF (4) = Near end sending LOF Indication
  28138. dsx1LossOfFrame (32) = Near end LOF (Red Alarm)
  28139.  
  28140. This looks weird, USR tells me that with a RED alarm it won't work, but it
  28141. definitely does, and customers are happy.
  28142.  
  28143. What could it be ? defect PRI cables ? bad provisioning ? bad setup ? bad
  28144. weather ? 
  28145.  
  28146. I'm open to any suggestions as long as it's not "TC's are lousy, buy Ascend
  28147. or Livingston..."
  28148.  
  28149. Thanks for any replies,
  28150.  
  28151. Robert
  28152.     
  28153.  
  28154.  
  28155. -
  28156.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28157.  with "unsubscribe usr-tc" in the body of the message.
  28158.  For information on digests or retrieving files and old messages send
  28159.  "help" to the same address.  Do not use quotes in your message.
  28160.  
  28161.  
  28162. -------------------------------------------------------------------------------
  28163.  
  28164. From: Bryan Wann <bwann@cwis.net>
  28165. Subject: Re: (usr-tc) Buying 1st USR-TC
  28166. Date: 24 Mar 1999 11:43:56 -0600 (CST)
  28167.  
  28168. On Tue, 23 Mar 1999, Ricky Beam wrote:
  28169.  
  28170. > On Tue, 23 Mar 1999, Bryan Wann wrote:
  28171. > >On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote:
  28172. > >It may be worthwhile for the first chassis.. that way you can get access
  28173. > >to code revisions.  Past 2 DSP releases have been 'free' but who knows how
  28174. > >long that will last.  
  28175. > 
  28176. > You idiot.  
  28177.  
  28178. Thank you!
  28179.  
  28180.  
  28181. > That's why the support contracts are so [bleep] expensive. 3Com isn't
  28182. > that stupid either; if you have more than one chassis, you have to buy
  28183. > support for all of them.
  28184.  
  28185. Since I am an idiot, care to expound on this a bit?  Are the support
  28186. contracts so bloody expensive because USR knows it is an extra source of
  28187. revenue, or because they know some people may buy one support contract to
  28188. leech upgrades for multiple racks?
  28189.  
  28190.  
  28191.  
  28192. ---
  28193. Bryan Wann        bwann@cwis.net    
  28194. CWIS Internet Services    http://www.cwis.net 918-967-2858
  28195.  
  28196. Give a man a fish, he eats for a day;
  28197. Teach a man to fish, he eats for a lifetime;
  28198. Enlighten him further, and he opens a chain of seafood restaurants
  28199.  
  28200.  
  28201.  
  28202. -
  28203.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28204.  with "unsubscribe usr-tc" in the body of the message.
  28205.  For information on digests or retrieving files and old messages send
  28206.  "help" to the same address.  Do not use quotes in your message.
  28207.  
  28208.  
  28209. -------------------------------------------------------------------------------
  28210.  
  28211. From: Ronald Kushner <ron@glis.net>
  28212. Subject: NAS heat. Was RE: (usr-tc) Buying 1st USR-TC
  28213. Date: 24 Mar 1999 12:49:02 -0500
  28214.  
  28215.  
  28216.  
  28217. Brian Elfert wrote:
  28218. > 
  28219. > On Wed, 24 Mar 1999, K Mitchell wrote:
  28220. > 
  28221. > >   I've had a HiPer chassis for almost a year now and have been pleased
  28222. > > overall with it. As for heat, I believe that earlier TC hardware did have a
  28223. > > heat problem, but it hasn't been an issue with the HiPer. It has an
  28224. > > integral fan tray with 9 or 12 fans that keeps it from going higher than 10
  28225. > > degrees or so above room temp. It's a bit loud, but I normally sit about 2
  28226. > 
  28227. > The heat problem isn't a problem with the units getting too hot.  The
  28228. > problem is simply the amount of heat generated by the units.
  28229.  
  28230. Everything except the PortMasters generate a ton of heat. I never really
  28231. took the temperature of a PM3, but it strikes me from being around them that
  28232. they run somewhat cooler. Everything else is like a frickin blow drier, the
  28233. Max 4000 series, the Max 6000 series, the Max TNT, the Cisco AS5200 units,
  28234. the Cisco AS5800 blast furnace, the Bay Networks 5000 chassis.. I've seen
  28235. them all. You can fry your fishstick if you stand in front of a 8' rack full
  28236. of AS5200's too long. At least the TC's blow the heat upwards, instead of in
  28237. your face. It's weird when you feel radiant heat off the front of a Bay
  28238. Networks 5000 chassis full of 5399s. 
  28239.  
  28240. Does anyone have any data on how much heat is generated by each type of RAC? 
  28241.  
  28242. -Ron
  28243. GLISnet, Inc.
  28244. +1 810/939.9885
  28245.  
  28246. -
  28247.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28248.  with "unsubscribe usr-tc" in the body of the message.
  28249.  For information on digests or retrieving files and old messages send
  28250.  "help" to the same address.  Do not use quotes in your message.
  28251.  
  28252.  
  28253. -------------------------------------------------------------------------------
  28254.  
  28255. From: matthews <matthews@brunnet.net>
  28256. Subject: RE: (usr-tc) RED alarm on HDSP but it still works
  28257. Date: 24 Mar 1999 13:47:26 -0400
  28258.  
  28259. On Wednesday, March 24, 1999 1:31 PM, Robert von Bismarck 
  28260. [SMTP:rvb@petrel.ch] wrote:
  28261. > Physical state :
  28262. > psF3Fc2LossOfSignal(3)
  28263. > Line Status :
  28264. > dsx1XmtFarEndLOF (4) = Near end sending LOF Indication
  28265. > dsx1LossOfFrame (32) = Near end LOF (Red Alarm)
  28266. > This looks weird, USR tells me that with a RED alarm it won't work, but 
  28267. it
  28268. > definitely does, and customers are happy.
  28269. > What could it be ? defect PRI cables ? bad provisioning ? bad setup ? bad
  28270. > weather ?
  28271.  
  28272. What do you see for errors at the span level?  I recently set up a second 
  28273. span on a dual PRI card and, once I had it working, noticed CRC errors and 
  28274. errored seconds were skyrocketing.  Calls were coming in normally as far as 
  28275. I could tell and the customers were happy.  As it turned out, at some point 
  28276. in the circuit the telco had not set it for B8ZS as it should have been. 
  28277.  As soon as they had corrected that, the errors dropped to nil.  This was 
  28278. on a dual pri card and there were no warning lights on it at all but DSPs 
  28279. might react differently.
  28280.  
  28281. It's one thing to check.
  28282.  
  28283. Matthew
  28284.  
  28285.  
  28286. -
  28287.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28288.  with "unsubscribe usr-tc" in the body of the message.
  28289.  For information on digests or retrieving files and old messages send
  28290.  "help" to the same address.  Do not use quotes in your message.
  28291.  
  28292.  
  28293. -------------------------------------------------------------------------------
  28294.  
  28295. From: Paul Farber <farber@admin.f-tech.net>
  28296. Subject: Re: (usr-tc) Buying 1st USR-TC
  28297. Date: 24 Mar 1999 13:07:48 -0500 (EST)
  28298.  
  28299. I would NEVER do that!  I like paying for software 7 times!  I like to be
  28300. on hold... plus I get to pay for the wonderful MUSAK they use!  More ..
  28301. please more!
  28302.  
  28303. Lets hope they don't figure out what a dongle is or encrypt software to
  28304. work with only burned in serial numbers.. that would suck!
  28305.  
  28306. Paul D. Farber II
  28307. Farber Technology
  28308. Ph. 570-628-5303
  28309. Fax 570-628-5545
  28310. farber@admin.f-tech.net
  28311.  
  28312. On Wed, 24 Mar 1999, Bryan Wann wrote:
  28313.  
  28314. > On Tue, 23 Mar 1999, Ricky Beam wrote:
  28315. > 
  28316. > > On Tue, 23 Mar 1999, Bryan Wann wrote:
  28317. > > >On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote:
  28318. > > >It may be worthwhile for the first chassis.. that way you can get access
  28319. > > >to code revisions.  Past 2 DSP releases have been 'free' but who knows how
  28320. > > >long that will last.  
  28321. > > 
  28322. > > You idiot.  
  28323. > 
  28324. > Thank you!
  28325. > 
  28326. > 
  28327. > > That's why the support contracts are so [bleep] expensive. 3Com isn't
  28328. > > that stupid either; if you have more than one chassis, you have to buy
  28329. > > support for all of them.
  28330. > 
  28331. > Since I am an idiot, care to expound on this a bit?  Are the support
  28332. > contracts so bloody expensive because USR knows it is an extra source of
  28333. > revenue, or because they know some people may buy one support contract to
  28334. > leech upgrades for multiple racks?
  28335. > 
  28336. > 
  28337. > 
  28338. > ---
  28339. > Bryan Wann        bwann@cwis.net    
  28340. > CWIS Internet Services    http://www.cwis.net 918-967-2858
  28341. > 
  28342. > Give a man a fish, he eats for a day;
  28343. > Teach a man to fish, he eats for a lifetime;
  28344. > Enlighten him further, and he opens a chain of seafood restaurants
  28345. > 
  28346. > 
  28347. > 
  28348. > -
  28349. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28350. >  with "unsubscribe usr-tc" in the body of the message.
  28351. >  For information on digests or retrieving files and old messages send
  28352. >  "help" to the same address.  Do not use quotes in your message.
  28353. > 
  28354.  
  28355.  
  28356. -
  28357.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28358.  with "unsubscribe usr-tc" in the body of the message.
  28359.  For information on digests or retrieving files and old messages send
  28360.  "help" to the same address.  Do not use quotes in your message.
  28361.  
  28362.  
  28363. -------------------------------------------------------------------------------
  28364.  
  28365. From: Jeff Mcadams <jeffm@iglou.com>
  28366. Subject: Re: (usr-tc) Buying 1st USR-TC
  28367. Date: 24 Mar 1999 13:17:38 -0500 (EST)
  28368.  
  28369. Thus spake Bryan Wann
  28370. >On Tue, 23 Mar 1999, Ricky Beam wrote:
  28371. >> That's why the support contracts are so [bleep] expensive. 3Com isn't
  28372. >> that stupid either; if you have more than one chassis, you have to buy
  28373. >> support for all of them.
  28374.  
  28375. >Since I am an idiot, care to expound on this a bit?  Are the support
  28376. >contracts so bloody expensive because USR knows it is an extra source of
  28377. >revenue, or because they know some people may buy one support contract to
  28378. >leech upgrades for multiple racks?
  28379.  
  28380. Well, considering that their equipment has serial numbers on it, I have
  28381. to assume that they're "so bloody expensive" because 3Com/USR knows it
  28382. is an extra source of revenue...that would be also consistent with their
  28383. attitudes towards other issues (check in the archives for the thread
  28384. "3Coms problems" or something along those lines.
  28385. -- 
  28386. Jeff McAdams                            Email: jeffm@iglou.com
  28387. Head Network Administrator              Voice: (502) 966-3848
  28388. IgLou Internet Services                        (800) 436-4456
  28389.  
  28390. -
  28391.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28392.  with "unsubscribe usr-tc" in the body of the message.
  28393.  For information on digests or retrieving files and old messages send
  28394.  "help" to the same address.  Do not use quotes in your message.
  28395.  
  28396.  
  28397. -------------------------------------------------------------------------------
  28398.  
  28399. From: "Marcelo _" <xyo@hotmail.com>
  28400. Subject: (usr-tc) Cable hardware
  28401. Date: 24 Mar 1999 05:36:29 PST
  28402.  
  28403.  
  28404.  
  28405. Is it possible to termite cable users on a DSP TC? I mean, supposing I 
  28406. have free slot on a Hiper chassis, can I plug the cards for cable?
  28407.  
  28408. It was not clear on 3com page, how can I set up a chassis to cable 
  28409. connections. Which boards are necessary? And how many connections could 
  28410. be supported?
  28411.  
  28412. TIA
  28413.  
  28414.  
  28415. Get Your Private, Free Email at http://www.hotmail.com
  28416.  
  28417. -
  28418.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28419.  with "unsubscribe usr-tc" in the body of the message.
  28420.  For information on digests or retrieving files and old messages send
  28421.  "help" to the same address.  Do not use quotes in your message.
  28422.  
  28423.  
  28424. -------------------------------------------------------------------------------
  28425.  
  28426. From: "Jack Singer" <jsinger@aaacars.com>
  28427. Subject: Re: (usr-tc) Buying 1st USR-TC
  28428. Date: 24 Mar 1999 07:17:28 -0500
  28429.  
  28430. We own over 20 TC units, never had a contract or a failure.
  28431.  
  28432. Jack.
  28433.  
  28434. zip-usrtc@ran.zipcon.net wrote:
  28435.  
  28436. > I'm about to purchase my first USR TC (HiPer bundle) and have been
  28437. > contemplating the support issue.  I've read that the USR boxes generate
  28438. > a lot of heat and have a higher failure rate than most other access
  28439. > servers.  Is there a consensus among list members on whether or not to
  28440. > purchase the support contract?  Thanks, Dan
  28441. >
  28442. > -
  28443. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28444. >  with "unsubscribe usr-tc" in the body of the message.
  28445. >  For information on digests or retrieving files and old messages send
  28446. >  "help" to the same address.  Do not use quotes in your message.
  28447.  
  28448. -
  28449.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28450.  with "unsubscribe usr-tc" in the body of the message.
  28451.  For information on digests or retrieving files and old messages send
  28452.  "help" to the same address.  Do not use quotes in your message.
  28453.  
  28454.  
  28455. -------------------------------------------------------------------------------
  28456.  
  28457. From: "Mike Hamrich" <mikeh@drfast.net>
  28458. Subject: Re: (usr-tc) PPP offloading and NT
  28459. Date: 21 Mar 1999 23:08:05 -0500
  28460.  
  28461. >Re-enabled ppp offloading and disabled ppp receive_accm as it is
  28462. >|recomended in the release notes of 4.1.59-6.
  28463. >|After doing this, we started receiving a rash of NT people getting
  28464. >|blocked at the PAP authentication.  Fortunately, this problem can >|fixed
  28465. by disabling the LCP Extensions on the NT machine.
  28466.  
  28467. Just LCP or do you have to turn off compression and header cmp also? With
  28468. offloading disable we did seem to fix the NT users gripes.
  28469. >You should leave the settings as sugested in the release notes. NT >has its
  28470. own problems, not the TCH. NT should have failed >reguardless of the
  28471. offloading setting. If you dissable PPP offloading >you may run back into
  28472. the "WebRamp"/PAP
  28473.  
  28474. When users that were OK with NT and  old Netserver based TCH have to be
  28475. called in mass to make changes. It is TCH problem, and what do you do about
  28476. webramps? Is there anyway to make the Hiperarc's works at least as good
  28477. netserver base TCH's
  28478.  
  28479. -
  28480.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28481.  with "unsubscribe usr-tc" in the body of the message.
  28482.  For information on digests or retrieving files and old messages send
  28483.  "help" to the same address.  Do not use quotes in your message.
  28484.  
  28485.  
  28486. -------------------------------------------------------------------------------
  28487.  
  28488. From: "Mike Hamrich" <mikeh@drfast.net>
  28489. Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  28490. Date: 21 Mar 1999 23:13:07 -0500
  28491.  
  28492. Blake, before you did the upgrade how did you have the NMC set to answer
  28493. ISDN calls, on the Quads or the Netserver?
  28494. -----Original Message-----
  28495.  
  28496.  
  28497. >ARC 4.1.59-6
  28498. >DSP 1.2.43
  28499. >
  28500. >The only thing we having problems with are ISDN calls.  Analog
  28501. >current link transmit rates are anywhere from 14,400 to 53,300.
  28502. >But i haven't seen a single ISDN call get established and pass
  28503. >data. mon ppp, and mon radius show nothing - "li co"  will show
  28504. >the modem being tied up but after about 10 seconds it drops.  I
  28505. >had a few ISDN customers connected with 4.1.59 and 1.2.59 but
  28506. >as soon as I upgraded the DSP to 1.2.43 things went downhill.
  28507. >
  28508. >[1 hour goes by]
  28509. >
  28510. >and at 7:30 my pager goes nuts saying that all our dedicated
  28511. >ISDN customers are back up.  during this time i have been
  28512. >gathering statistics from the incomplete ISDN calls and then
  28513. >many dedicated customers with ISDN devices from many different
  28514. >vendors begin working again without any intervention from me.
  28515. >Ah! and everything came back up about the same time last night!
  28516. >
  28517. >WHAT THE HELL??!?!?!
  28518. >
  28519. >any similar experiences? TELCO sabotage?
  28520. >
  28521. >blake
  28522. >
  28523. >
  28524. >> -----Original Message-----
  28525. >> From: Mike Hamrich [mailto:mhamrich@drfast.net]
  28526. >> Sent: Thursday, March 18, 1999 7:21 PM
  28527. >> To: usr-tc@lists.xmission.com
  28528. >> Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  28529. >>
  28530. >>
  28531. >> OK HiperArc with latest code 3/4/99
  28532. >>
  28533. >> Since the "upgrade" we are having tons of connection issues.
  28534. >> Couriers can't connect
  28535. >> Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  28536. >> OEM/Brown box Sportsters can't stay connected
  28537. >>
  28538. >> We also told owner of non X2 modem to go elsewere.
  28539. >>
  28540. >> We surveyed our users, 248 replied so far:
  28541. >> 67% say slower speed, 22% are having problems saying
  28542. >> connected, 4% can't
  28543. >> connect at all, and ONLY 7%  report better connection.
  28544. >>
  28545. >> We have PRI lines, Set PPP offloading to no, Authenticate ANY
  28546. >> Preferrd PAP
  28547. >>
  28548. >> Any other ideas to make this stuff work as well as the old stuff did?
  28549. >>
  28550. >> Thanks in advance for you help
  28551. >>
  28552. >> Mike Hamrich
  28553. >> CIO, DrFast.Net, Inc.
  28554. >> (216) 797-1040
  28555. >>
  28556. >>
  28557. >> -
  28558. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28559. >>  with "unsubscribe usr-tc" in the body of the message.
  28560. >>  For information on digests or retrieving files and old messages send
  28561. >>  "help" to the same address.  Do not use quotes in your message.
  28562. >>
  28563. >
  28564. >-
  28565. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28566. > with "unsubscribe usr-tc" in the body of the message.
  28567. > For information on digests or retrieving files and old messages send
  28568. > "help" to the same address.  Do not use quotes in your message.
  28569.  
  28570. -
  28571.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28572.  with "unsubscribe usr-tc" in the body of the message.
  28573.  For information on digests or retrieving files and old messages send
  28574.  "help" to the same address.  Do not use quotes in your message.
  28575.  
  28576.  
  28577. -------------------------------------------------------------------------------
  28578.  
  28579. From: "Mike Hamrich" <mikeh@drfast.net>
  28580. Subject: Re: (usr-tc) RE: (USR-TC) SINCE HIPERA
  28581. Date: 21 Mar 1999 22:48:24 -0500
  28582.  
  28583. ----Original Message-----
  28584.  
  28585.  
  28586. >On Fri, 19 Mar 1999, Jeff Binkley wrote:
  28587. >> Krish,
  28588. >> Note he has Preferred set to PAP which may be a problem with >quads as
  28589. you and  I discovered the other day.
  28590.  
  28591. We only have Quads installed
  28592.  
  28593. >Well he is using DSP for the most part and also he is complaing >about
  28594. speed and through put.  Disabling ppp offloading does slow
  28595.  
  28596. No DSP installed yet, only the quads
  28597.  
  28598. >  I have not heard from him and I also offered to work with him to find
  28599. >out if he has the quad or the DSP, no answer from him yet.
  28600.  
  28601. Thank you very much about offer.
  28602. Sorry been out with Kidney stone. Im not complaing about throughput, users
  28603. report slower initial connect rate then with old Netserver/X2 modem code
  28604. though. I just need to set things up so they do not get dissconnected. Im
  28605. sure it's a setting on our side or a telco issue.
  28606.  
  28607. Will set PPP enable and the accm like you said.
  28608.  
  28609. Is it possible that our TC Chassi is too old to handle this upgrade? It's 2
  28610. years old, has combination of Quad analog and digital cards.
  28611.  
  28612. -
  28613.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28614.  with "unsubscribe usr-tc" in the body of the message.
  28615.  For information on digests or retrieving files and old messages send
  28616.  "help" to the same address.  Do not use quotes in your message.
  28617.  
  28618.  
  28619. -------------------------------------------------------------------------------
  28620.  
  28621. From: "Mike Hamrich" <mikeh@drfast.net>
  28622. Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  28623. Date: 21 Mar 1999 22:21:31 -0500
  28624.  
  28625. Users that could not connect were ask the questions on the phone in between
  28626. the threats to leave us.
  28627.  
  28628. Most of these clients have been with us over  2 years, and the logs back up
  28629. that this "upgrade" is the worst thing we have done. Is anyone running this
  28630. stuff sucessfully? If so it must be something with our setup or the Telco.
  28631.  
  28632.  You are right, only negatives will fill out survey online, and the logs
  28633. show that the ones that can stay connected do achive 6-22K faster than they
  28634. think.
  28635. -----Original Message-----
  28636.  
  28637.  
  28638. >If 4% can't connect at all, how did they fill out the survey?  Or did you
  28639. >mail it to them?
  28640. >
  28641. >My experience is that asking them what is going on is a bad thing.  The
  28642. >connection is NEVER fast enough, the ALWAYS get disconnected, etc.
  28643. >
  28644. >Check your logs to back up the data.... you may be suprised.
  28645. >
  28646. >Paul D. Farber II
  28647. >Farber Technology
  28648. >Ph. 570-628-5303
  28649. >Fax 570-628-5545
  28650. >farber@admin.f-tech.net
  28651. >
  28652. >On Thu, 18 Mar 1999, Mike Hamrich wrote:
  28653. >
  28654. >> OK HiperArc with latest code 3/4/99
  28655. >>
  28656. >> Since the "upgrade" we are having tons of connection issues.
  28657. >> Couriers can't connect
  28658. >> Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  28659. >> OEM/Brown box Sportsters can't stay connected
  28660. >>
  28661. >> We also told owner of non X2 modem to go elsewere.
  28662. >>
  28663. >> We surveyed our users, 248 replied so far:
  28664. >> 67% say slower speed, 22% are having problems saying connected, 4% can't
  28665. >> connect at all, and ONLY 7%  report better connection.
  28666. >>
  28667. >> We have PRI lines, Set PPP offloading to no, Authenticate ANY Preferrd
  28668. PAP
  28669. >>
  28670. >> Any other ideas to make this stuff work as well as the old stuff did?
  28671. >>
  28672. >> Thanks in advance for you help
  28673. >>
  28674. >> Mike Hamrich
  28675. >> CIO, DrFast.Net, Inc.
  28676. >> (216) 797-1040
  28677. >>
  28678. >>
  28679. >> -
  28680. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28681. >>  with "unsubscribe usr-tc" in the body of the message.
  28682. >>  For information on digests or retrieving files and old messages send
  28683. >>  "help" to the same address.  Do not use quotes in your message.
  28684. >>
  28685. >
  28686. >
  28687. >-
  28688. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28689. > with "unsubscribe usr-tc" in the body of the message.
  28690. > For information on digests or retrieving files and old messages send
  28691. > "help" to the same address.  Do not use quotes in your message.
  28692.  
  28693. -
  28694.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28695.  with "unsubscribe usr-tc" in the body of the message.
  28696.  For information on digests or retrieving files and old messages send
  28697.  "help" to the same address.  Do not use quotes in your message.
  28698.  
  28699.  
  28700. -------------------------------------------------------------------------------
  28701.  
  28702. From: "Randy McMillan" <randy@pacinfo.com>
  28703. Subject: Re: (usr-tc) Disabling x2+v.90 on Quads using AT commands
  28704. Date: 24 Mar 1999 11:56:05 -0800
  28705.  
  28706. We have the quad modems, and I have tried "S76.1=1S76.2=1S81.5=1" for the
  28707. string to turn off v.90 and "S76.1=0S76.2=0S81.5=0" for the default DNIS
  28708. init string. and so far that seems to work for my tests.  I hope it works
  28709. for my users...   I haven't tried to add &K0 S51.6=1 or s27.3=1.
  28710.  
  28711. Randy McMillan
  28712.  
  28713. ----- Original Message -----
  28714. Sent: Tuesday, March 23, 1999 11:08 PM
  28715.  
  28716.  
  28717. > I'll try this again...  can someone either
  28718. >
  28719. > 1) Get me a copy of the output of "ATS$" executed on a Quad?
  28720. > I tried getting it via the ARC (set swi inter slot:x/mod:x at "ats$") but
  28721. > it doesn't return the entire thing -- just the first half of so.  Looks
  28722. > like it's too big for a buffer somewhere.
  28723. >
  28724. > 2) Give me some hints as to the right settings for the S76 and S81
  28725. > registers to completely kill x2 and v.90 on a Quad?  On a DSP,
  28726. > S76.1=1S81.5=1 does it.  On a Quad, this does kill v.90, but it leaves
  28727. > some part of x2 enabled, and 3com modems calling in don't connect -- it
  28728. > sounds like one side is trying to do x2 and the other side is trying to do
  28729. > v.34, and the handshake gets stuck.  (Probably a bug in the Quads?)  The
  28730. > firmware release notes don't document these registers very well...
  28731. >
  28732. > This is for the DNIS-based reconfiguration trick discussed earlier, which
  28733. > is why I don't just use SNMP or TCM to do it...
  28734. >
  28735. >
  28736. > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort
  28737. KY
  28738. > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without
  28739. a
  28740. > Microsoft operating system is like a dog without a brick tied to its
  28741. head."
  28742. >
  28743. >
  28744. > -
  28745. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28746. >  with "unsubscribe usr-tc" in the body of the message.
  28747. >  For information on digests or retrieving files and old messages send
  28748. >  "help" to the same address.  Do not use quotes in your message.
  28749. >
  28750.  
  28751.  
  28752. -
  28753.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28754.  with "unsubscribe usr-tc" in the body of the message.
  28755.  For information on digests or retrieving files and old messages send
  28756.  "help" to the same address.  Do not use quotes in your message.
  28757.  
  28758.  
  28759. -------------------------------------------------------------------------------
  28760.  
  28761. From: Sean Herr <Sean@YNC.NET>
  28762. Subject: (usr-tc) Level "CRITICAL":: Deactivating Timer Fired on interface:
  28763. Date: 24 Mar 1999 14:16:48 -0600
  28764.  
  28765. I have just noticed this error is syslogs, it seems to reset the whole card.
  28766. Though I was imagining things, first the card was full, next it was empty??
  28767.  
  28768. At 20:40:00, Facility "Driver", Level "CRITICAL":: Deactivating Timer Fired
  28769. on interface: slot:15/mod:16
  28770.  
  28771.  
  28772. Sean Herr
  28773.  
  28774. -
  28775.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28776.  with "unsubscribe usr-tc" in the body of the message.
  28777.  For information on digests or retrieving files and old messages send
  28778.  "help" to the same address.  Do not use quotes in your message.
  28779.  
  28780.  
  28781. -------------------------------------------------------------------------------
  28782.  
  28783. From: Ricky Beam <jfbeam@beaker.interpath.net>
  28784. Subject: Re: (usr-tc) Buying 1st USR-TC
  28785. Date: 24 Mar 1999 15:23:06 -0500 (EST)
  28786.  
  28787. On Wed, 24 Mar 1999, Bryan Wann wrote:
  28788. >On Tue, 23 Mar 1999, Ricky Beam wrote:
  28789. >> On Tue, 23 Mar 1999, Bryan Wann wrote:
  28790. >> >On 23 Mar 1999 zip-usrtc@ran.zipcon.net wrote:
  28791. >> >It may be worthwhile for the first chassis.. that way you can get access
  28792. >> >to code revisions.  Past 2 DSP releases have been 'free' but who knows how
  28793. >> >long that will last.  
  28794. >> 
  28795. >> You idiot.  
  28796. >
  28797. >Thank you!
  28798.  
  28799. You're welcome.
  28800.  
  28801. >> That's why the support contracts are so [bleep] expensive. 3Com isn't
  28802. >> that stupid either; if you have more than one chassis, you have to buy
  28803. >> support for all of them.
  28804. >
  28805. >Since I am an idiot, care to expound on this a bit?  Are the support
  28806. >contracts so bloody expensive because USR knows it is an extra source of
  28807. >revenue, or because they know some people may buy one support contract to
  28808. >leech upgrades for multiple racks?
  28809.  
  28810. Both.  It costs 3Com money to develop the software and people were stealing
  28811. money from them by buying one contract and putting that code on more than
  28812. one chassis.
  28813.  
  28814. Do you really want to see 3Com wiring serial number checks in the code to
  28815. prevent you from loading code on a card that isn't under a software support
  28816. contract?  I certainly don't want to see that level complexity.  And I'm
  28817. certain no one wants to have to enter enable codes on every card in their
  28818. network -- the X2 crap drove me mad with only 47 chassis.
  28819.  
  28820. Try to pull that stunt with Cisco...  3Com has to make money somehow. IMO,
  28821. they aren't charging enough for the hardware itself -- the TC hardware is,
  28822. by far, much cheaper than competing hardware.
  28823.  
  28824. --Ricky
  28825.  
  28826. PS: If you want "free" code updates, participate in the beta program and
  28827.     actually give some feedback.  You'll have access to the code before it
  28828.     becomes "release" and you have the chance to get things fixed before
  28829.     it's too late.  You're providing a service to 3Com and vice versa.
  28830.  
  28831.  
  28832.  
  28833. -
  28834.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28835.  with "unsubscribe usr-tc" in the body of the message.
  28836.  For information on digests or retrieving files and old messages send
  28837.  "help" to the same address.  Do not use quotes in your message.
  28838.  
  28839.  
  28840. -------------------------------------------------------------------------------
  28841.  
  28842. From: ROC Services <rocsoft@itol.com>
  28843. Subject: (usr-tc) PPP Get Option Rejected (long)
  28844. Date: 24 Mar 1999 16:38:09 -0600 (CST)
  28845.  
  28846. I've got a problem with users fairly frequently getting disconnected
  28847. immediately after performing PAP, with this message getting syslogged:
  28848.  
  28849. Mar 24 16:00:28 gb-hiper At 22:00:28, Facility "Auth Facility", Level
  28850. "COMMON":: Port slot:4/mod:9 successful RADIUS authentication
  28851. for user: Pxxxxxxxxx
  28852.  
  28853. Mar 24 16:00:28 gb-hiper At 22:00:28, Facility "PPP", Level "UNUSUAL"::
  28854. ../../src/ppp_main.c: PPP Get Option Rejected, (bad status).
  28855.  
  28856. They can usually get connected on the second try.  There doesn't seem to
  28857. be a pattern to the slot/mod numbers -- they're more or less random
  28858. throughout the group.  We've got one where they get this every time, but
  28859. they're an ISDN customer with what I think may be a misconfigured router.
  28860. The others are analog dialups.
  28861.  
  28862. A 'mon ppp' on one of these connection shows the ARC sending a PAP
  28863. auth-ack and then nothing after that.  In our RADIUS server's log I can
  28864. see the auth request and ack, but no accounting records.  Logging of
  28865. unauthenticated calls isn't enabled on this box.
  28866.  
  28867. Any info would be appreciated.  If this is an RTFM issue, someone please
  28868. indicate which FM.  I suspect it's not, though, as this just started
  28869. happening relatively recently.
  28870.  
  28871. [versions]
  28872. HARC 4.1.59-6
  28873. DSP 1.2.43 and 1.2.59, some on PRI some on channelized.
  28874. Livingston RADIUS 2.0.1, soon to be Cistron RADIUS.
  28875.  
  28876. [relevant config stuff]
  28877. PPP offloading:                           ENABLED
  28878. Send Accounting for PPP Abnormal Disc:    DISABLED
  28879. PPP Address Field Compression:            ENABLED
  28880. PPP Protocol Field Compression:           ENABLED
  28881. PPP Multilink PPP:                        ENABLED
  28882. PPP BACP and BAP:                         DISABLED
  28883. PPP Bap Hunt Group Phone Number:
  28884. PPP Receive ACCM:                         DISABLE
  28885.  
  28886. [mon PPP]
  28887. Outgoing PPP Data on interface: slot:4/mod:9
  28888.     LCP        CFG_REQ           MRU            05 ea
  28889.                                  ASYNC_MAP      00 00 00 00
  28890.                                  AUTH_TYPE      c0 23
  28891.                                  MAGIC_NUM      50 8a b1 9b
  28892.                                  PROTO_COMP
  28893.                                  AC_COMP
  28894.                                  MPP_MRRU       05 ea
  28895.                                  MPP_ENDPTID    00
  28896.  
  28897. Incoming PPP Data on interface: slot:4/mod:9
  28898.     LCP        CFG_REQ           ASYNC_MAP      00 0a 00 00
  28899.                                  MAGIC_NUM      00 01 1a 04
  28900.                                  PROTO_COMP
  28901.                                  AC_COMP
  28902.                                  CALLBACK       06
  28903.  
  28904. Outgoing PPP Data on interface: slot:4/mod:9
  28905.     LCP        CFG_REJ           CALLBACK       06
  28906.  
  28907. Incoming PPP Data on interface: slot:4/mod:9
  28908.     LCP        CFG_REJ           MPP_MRRU       05 ea
  28909.                                  MPP_ENDPTID    00
  28910.  
  28911. Outgoing PPP Data on interface: slot:4/mod:9
  28912.     LCP        CFG_REQ           MRU            05 ea
  28913.                                  ASYNC_MAP      00 00 00 00
  28914.                                  AUTH_TYPE      c0 23
  28915.                                  MAGIC_NUM      50 8a b1 9b
  28916.                                  PROTO_COMP
  28917.                                  AC_COMP
  28918.  
  28919. Incoming PPP Data on interface: slot:4/mod:9
  28920.     LCP        CFG_REQ           ASYNC_MAP      00 0a 00 00
  28921.                                  MAGIC_NUM      00 01 1a 04
  28922.                                  PROTO_COMP
  28923.                                  AC_COMP
  28924.  
  28925. Outgoing PPP Data on interface: slot:4/mod:9
  28926.     LCP        CFG_ACK           ASYNC_MAP      00 0a 00 00
  28927.                                  MAGIC_NUM      00 01 1a 04
  28928.                                  PROTO_COMP
  28929.                                  AC_COMP
  28930.  
  28931. Incoming PPP Data on interface: slot:4/mod:9
  28932.     LCP        CFG_ACK           MRU            05 ea
  28933.                                  ASYNC_MAP      00 00 00 00
  28934.                                  AUTH_TYPE      c0 23
  28935.                                  MAGIC_NUM      50 8a b1 9b
  28936.                                  PROTO_COMP
  28937.                                  AC_COMP
  28938.  
  28939. Incoming PPP Data on interface: slot:4/mod:9
  28940.     PAP        REQUEST           USERNAME = Pxxxxxxxx
  28941.                                  PASSWORD = yyyyyyyyy
  28942. Outgoing PPP Data on interface: slot:4/mod:9
  28943.     PAP        ACK               ....Tracing the current/next session;
  28944. Escape to stop...
  28945. Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
  28946.  
  28947.  
  28948.  
  28949. -
  28950.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28951.  with "unsubscribe usr-tc" in the body of the message.
  28952.  For information on digests or retrieving files and old messages send
  28953.  "help" to the same address.  Do not use quotes in your message.
  28954.  
  28955.  
  28956. -------------------------------------------------------------------------------
  28957.  
  28958. From: Robert Reynolds <lists@lcii.net>
  28959. Subject: (usr-tc) Fast busy problem
  28960. Date: 24 Mar 1999 17:42:42 -0600 (EST)
  28961.  
  28962. I upgraded to DSP 1.2.43 & HiPer ARC 4.1.59-6 last week.  There are 4 DSP
  28963. cards in this box.  Monday, when the first two spans filled up I would get
  28964. fast busies.  I noticed I was getting Invalid Channel ID errors so I took
  28965. the span out of service and it rooled over to the fourth span fine.
  28966. When I put the card back in service it started working after
  28967. about 2 minutes.  I did notice a loopback/d-channel alarm during that 
  28968. 2 minutes but then all was well. Today the fourth span had the same
  28969. problem.  The first 3 spans filled up fine then fast busy signals. I reset
  28970. the card on the fourth span then all was well.
  28971.  
  28972. These are all PRI's.
  28973.  
  28974. Anyone else notice this problem?
  28975.  
  28976.  
  28977. -
  28978.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  28979.  with "unsubscribe usr-tc" in the body of the message.
  28980.  For information on digests or retrieving files and old messages send
  28981.  "help" to the same address.  Do not use quotes in your message.
  28982.  
  28983.  
  28984. -------------------------------------------------------------------------------
  28985.  
  28986. From: jeff.binkley@asacomp.com (Jeff Binkley)
  28987. Subject: Re: (usr-tc) RE: (USR-TC)
  28988. Date: 24 Mar 1999 17:55:00 -0500
  28989.  
  28990.  
  28991.  
  28992.  
  28993.  
  28994. Ok, that's the problem.  Krish and I found out that with 4.1.59-6 and 
  28995. Quads, you must not have the Preferred protocol set to PAP.  Change it 
  28996. to DEFAULT or get off of 4.1.59-6 and Quads.  We are staying at 4.1.62-4 
  28997. for Quad racks.  Krish can elaborate more on the bug if you wish.
  28998.  
  28999.  
  29000. Jeff Binkley
  29001. ASA Network Computing
  29002.  
  29003.  
  29004. u>----Original Message-----
  29005.  
  29006.  
  29007. u>>On Fri, 19 Mar 1999, Jeff Binkley wrote:
  29008. u>>> Krish,
  29009. u>>> Note he has Preferred set to PAP which may be a problem with >quads
  29010. u>as you and  I discovered the other day.
  29011.  
  29012. u>We only have Quads installed
  29013.  
  29014. u>>Well he is using DSP for the most part and also he is complaing
  29015. u>>about speed and through put.  Disabling ppp offloading does slow
  29016.  
  29017. u>No DSP installed yet, only the quads
  29018.  
  29019. CMPQwk 1.42-21 9999
  29020.  
  29021.  
  29022. -
  29023.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29024.  with "unsubscribe usr-tc" in the body of the message.
  29025.  For information on digests or retrieving files and old messages send
  29026.  "help" to the same address.  Do not use quotes in your message.
  29027.  
  29028.  
  29029. -------------------------------------------------------------------------------
  29030.  
  29031. From: MegaZone <megazone@megazone.org>
  29032. Subject: Re: (usr-tc) Buying 1st USR-TC
  29033. Date: 24 Mar 1999 15:02:09 -0800 (PST)
  29034.  
  29035. Once upon a time Ricky Beam shaped the electrons to say...
  29036. >Both.  It costs 3Com money to develop the software and people were stealing
  29037. >money from them by buying one contract and putting that code on more than
  29038. >one chassis.
  29039.  
  29040. Funny that other vendors can give away OS upgrades for free, and they
  29041. aren't goign bankrupt.  And are even charging per port prices in the same
  29042. range as 3Com.  And then they give you free support, free management tools...
  29043.  
  29044. Gosh, I never knew 3Com was so poorly run they need to make money on software
  29045. on top of everything else.
  29046.  
  29047. >Do you really want to see 3Com wiring serial number checks in the code to
  29048. >prevent you from loading code on a card that isn't under a software support
  29049.  
  29050. I'd like to see them give the upgrades away - but that might mean respecting
  29051. the customers and responding to the market.  So I won't hold my breath.
  29052.  
  29053. >they aren't charging enough for the hardware itself -- the TC hardware is,
  29054. >by far, much cheaper than competing hardware.
  29055.  
  29056. Much cheaper?  Not that I've seen.  Depending on the reseller, specials,
  29057. etc, you can find other vendors' gear for less.  And prices across the
  29058. board continue to decline.
  29059.  
  29060. 3Com charges for just about everything.
  29061.  
  29062. >PS: If you want "free" code updates, participate in the beta program and
  29063. >    actually give some feedback.  You'll have access to the code before it
  29064.  
  29065. Or buy from another vendor...
  29066.  
  29067. Have you seen the latest (free) PM-4 open release? Jesus is it loaded.
  29068. <URL:ftp://ftp.livingston.com/pub/le/doc/release/release41b14.txt> - free.
  29069. The PM-4 itself is still pricey, but fairly new and prices are dropping.
  29070.  
  29071. I've also seen the notes for 3.9, but that isn't public yet.  Equally
  29072. loaded, equally free.  And there will be a build for the PM-2 - of course
  29073. if the PM-2 were 3Com it wou;d be 'obsolete' and 'discontinued' and you'd
  29074. be told to 'upgrade' for any 'fix'...  Oh, did I get sarcasm on you?
  29075.  
  29076. -MZ
  29077. -- 
  29078. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  29079. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  29080. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  29081. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  29082. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  29083.  
  29084. -
  29085.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29086.  with "unsubscribe usr-tc" in the body of the message.
  29087.  For information on digests or retrieving files and old messages send
  29088.  "help" to the same address.  Do not use quotes in your message.
  29089.  
  29090.  
  29091. -------------------------------------------------------------------------------
  29092.  
  29093. From: Dan Hollis <goemon@sasami.anime.net>
  29094. Subject: Re: (usr-tc) Buying 1st USR-TC
  29095. Date: 24 Mar 1999 15:16:59 -0800 (PST)
  29096.  
  29097. On Wed, 24 Mar 1999, MegaZone wrote:
  29098. > Gosh, I never knew 3Com was so poorly run they need to make money on software
  29099. > on top of everything else.
  29100.  
  29101. Does this mean Cisco is badly run?
  29102.  
  29103. > >Do you really want to see 3Com wiring serial number checks in the code to
  29104. > >prevent you from loading code on a card that isn't under a software support
  29105. > I'd like to see them give the upgrades away - but that might mean respecting
  29106. > the customers and responding to the market.  So I won't hold my breath.
  29107.  
  29108. Responding to the market. Hm. Then why did it take Lucent so long to
  29109. support RIPv2. And why does it feel like Lucent is giving users the finger
  29110. with the RIPv2 release. Eg "heres your RIPv2, you freaking lamers"
  29111.  
  29112. -Dan
  29113.  
  29114.  
  29115. -
  29116.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29117.  with "unsubscribe usr-tc" in the body of the message.
  29118.  For information on digests or retrieving files and old messages send
  29119.  "help" to the same address.  Do not use quotes in your message.
  29120.  
  29121.  
  29122. -------------------------------------------------------------------------------
  29123.  
  29124. From: Jeff Mcadams <jeffm@iglou.com>
  29125. Subject: Re: (usr-tc) Buying 1st USR-TC
  29126. Date: 24 Mar 1999 18:16:48 -0500 (EST)
  29127.  
  29128. Thus spake MegaZone
  29129. >Gosh, I never knew 3Com was so poorly run they need to make money on software
  29130. >on top of everything else.
  29131.  
  29132. You haven't been watching them much have you?
  29133. >I'd like to see them give the upgrades away - but that might mean
  29134. >respecting the customers and responding to the market.  So I won't hold
  29135. >my breath.
  29136.  
  29137. Heh, yeah, respecting the customer...that'll be the day.
  29138.  
  29139. >>they aren't charging enough for the hardware itself -- the TC hardware is,
  29140. >>by far, much cheaper than competing hardware.
  29141.  
  29142. >Much cheaper?  Not that I've seen.  Depending on the reseller, specials,
  29143. >etc, you can find other vendors' gear for less.  And prices across the
  29144. >board continue to decline.
  29145.  
  29146. I kinda wondered about that comment too....we haven't seen that its much
  29147. cheaper per port than much else, and sometimes more expensive.
  29148.  
  29149. >3Com charges for just about everything.
  29150.  
  29151. "just about?"  *ponders trying to think of something that they don't
  29152. charge for in normal circumstances*
  29153.  
  29154. >>PS: If you want "free" code updates, participate in the beta program and
  29155. >>    actually give some feedback.  You'll have access to the code before it
  29156.  
  29157. That's assuming they even acknowledge your request to be a part of the
  29158. Beta process...hasn't happened yet for me.
  29159.  
  29160. >And there will be a build for the PM-2 - of course if the PM-2 were
  29161. >3Com it wou;d be 'obsolete' and 'discontinued' and you'd be told to
  29162. >'upgrade' for any 'fix'...  Oh, did I get sarcasm on you?
  29163.  
  29164. Not any that would be noticed in all of my own.  :)
  29165. -- 
  29166. Jeff McAdams                            Email: jeffm@iglou.com
  29167. Head Network Administrator              Voice: (502) 966-3848
  29168. IgLou Internet Services                        (800) 436-4456
  29169.  
  29170. -
  29171.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29172.  with "unsubscribe usr-tc" in the body of the message.
  29173.  For information on digests or retrieving files and old messages send
  29174.  "help" to the same address.  Do not use quotes in your message.
  29175.  
  29176.  
  29177. -------------------------------------------------------------------------------
  29178.  
  29179. From: <vanhalen@coredcs.com>
  29180. Subject: (usr-tc) Assistance Needed Help!!!!
  29181. Date: 24 Mar 1999 17:31:11 -0600 (CST)
  29182.  
  29183. Hello-
  29184.  
  29185. I'm trying to reprovision our isdn box(netserver with quads) here with
  29186. different ip's and move the range down.  In other words, it was
  29187. xxx.xxx.47.240 with a size of 12. I tried to move it to xxx.xxx.47.225
  29188. with the same size of 12.  I did this with the 'set assigned
  29189. xxx.xxx.47.225' command and did a save all and reboot.  Upon reboot anyone
  29190. who dials into the box with the box cannot get out nor can I ping them.  A
  29191. traceroute shows that the router knows what box to send it to but it just
  29192. never gets there.
  29193.  
  29194. traceroute to xxx.xxx.47.232), 30 hops max,
  29195. 40 byte packets
  29196.  1  xxx.xxx.xxx.2  1.998 ms  2.128 ms  2.377 ms
  29197.  2  xxx.xxx.xxx.4  3.746 ms  2.979 ms  3.567 ms
  29198.  3  xxx.xxx.46.8  7.153 ms  6.639 ms  7.037 ms <--this is the isdn box
  29199.  4  * * *   
  29200.  
  29201.  
  29202.  
  29203. Whatever more info is needed, i.e. show global or whatever, I can give.
  29204.  
  29205. Any help is appreciated.
  29206.  
  29207. Steve
  29208.  
  29209.  
  29210. -
  29211.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29212.  with "unsubscribe usr-tc" in the body of the message.
  29213.  For information on digests or retrieving files and old messages send
  29214.  "help" to the same address.  Do not use quotes in your message.
  29215.  
  29216.  
  29217. -------------------------------------------------------------------------------
  29218.  
  29219. From: MegaZone <megazone@megazone.org>
  29220. Subject: Re: NAS heat. Was RE: (usr-tc) Buying 1st USR-TC
  29221. Date: 24 Mar 1999 15:32:49 -0800 (PST)
  29222.  
  29223. Once upon a time Ronald Kushner shaped the electrons to say...
  29224. >Everything except the PortMasters generate a ton of heat. I never really
  29225. >took the temperature of a PM3, but it strikes me from being around them that
  29226.  
  29227. You can yank the fan on a PM-3 and it won't die.  People have had dead fans
  29228. and thought they were temperature activated since they were never on. :-)
  29229.  
  29230. >they run somewhat cooler. Everything else is like a frickin blow drier, the
  29231. >Max 4000 series, the Max 6000 series, the Max TNT, the Cisco AS5200 units,
  29232.  
  29233. The MAX 6000 is definitely better than the MAX 4000 - and the 4000 with
  29234. the newer digital modems is WAY better than the old analog modem cards. 
  29235. A full MAX 4000 with 72 analog modems could *burn* you.  They've been known
  29236. to meltdown and some have caught fire.
  29237.  
  29238. >the Cisco AS5800 blast furnace, the Bay Networks 5000 chassis.. I've seen
  29239. >them all. You can fry your fishstick if you stand in front of a 8' rack full
  29240. >of AS5200's too long. At least the TC's blow the heat upwards, instead of in
  29241.  
  29242. Actually this is not a good thing.  I've talked to people with racks of
  29243. TCs where the heat at the top (and this was with quads, I am aware that
  29244. DSPs are better) was enough to melt plastic items into goo.  One guy laid a
  29245. 3-ring binder down while doing something and had it melt, drooping over the
  29246. rack.  You make a chiminey.
  29247.  
  29248. You *want* front to back airflow.  Racks are mounted next to each other,
  29249. and gear in the rack is above.  So side to side - MAX - airflow cooks
  29250. the next rack over.  Also, many racks have sides now, not good.  Top to
  29251. bottom airflow - TC - creates the chiminey.
  29252.  
  29253. Telco quality gear will have front to back flow.  Or, if it is taller,
  29254. will be lower front to upper rear.  The former is like the AS5300 or
  29255. PM-3, the latter is like the CVX-1800 or PM-4.  This way the exhaust from
  29256. one unit will *never* feed into the intake of another.
  29257.  
  29258. >your face. It's weird when you feel radiant heat off the front of a Bay
  29259. >Networks 5000 chassis full of 5399s. 
  29260.  
  29261. Yeah - I stood infront of a loaded 5000MSX and was very surprised.  Even
  29262. with the exhaust in back the thing was hot enough to radiate heat out the
  29263. front.
  29264.  
  29265. >Does anyone have any data on how much heat is generated by each type of RAC? 
  29266.  
  29267. Look for the Watts consumed and you can turn that into BTU.
  29268.  
  29269. A PM-3 is 20Watts + .8 Watts a modem (dsp).  Actually it is less, they
  29270. budgeted high.  It is more like .5-6W a modem.  Say 60W for a 50 modem
  29271. unit.  A PM-4's *max* consumption is 800W - that's what the power supplies
  29272. can give it.  (3 400W supplies, N+1).  But it is something less than that,
  29273. even full.
  29274.  
  29275. Jesus - get this, a MAX6000 with 6x16 modem cards has a draw of 225W!
  29276. Minimum - no modem cards - is 80W!  That's more than a loaded PM-3.
  29277.  
  29278. HiPer - a T1 DSP is 24W (E1 is 26W), Router card is 31W, not sure on the 
  29279. network management card.  But it is 5A and the DSP is 5.4A - so let's use
  29280. 22W for example.  Now, a loaded unit is listed by 3Com as 14 DSPs, 2 
  29281. routers, and one NMC - so about 420W.
  29282.  
  29283. I obtained all figures from the respective vendor's website.
  29284.  
  29285. -MZ
  29286. -- 
  29287. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  29288. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  29289. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  29290. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  29291. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  29292.  
  29293. -
  29294.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29295.  with "unsubscribe usr-tc" in the body of the message.
  29296.  For information on digests or retrieving files and old messages send
  29297.  "help" to the same address.  Do not use quotes in your message.
  29298.  
  29299.  
  29300. -------------------------------------------------------------------------------
  29301.  
  29302. From: MegaZone <megazone@megazone.org>
  29303. Subject: Re: (usr-tc) Buying 1st USR-TC
  29304. Date: 24 Mar 1999 15:41:41 -0800 (PST)
  29305.  
  29306. Once upon a time Dan Hollis shaped the electrons to say...
  29307. >On Wed, 24 Mar 1999, MegaZone wrote:
  29308. >>Gosh, I never knew 3Com was so poorly run they need to make money on software
  29309. >>on top of everything else.
  29310. >Does this mean Cisco is badly run?
  29311.  
  29312. I do think they are a bit inefficient.
  29313.  
  29314. >Responding to the market. Hm. Then why did it take Lucent so long to
  29315. >support RIPv2. And why does it feel like Lucent is giving users the finger
  29316. >with the RIPv2 release. Eg "heres your RIPv2, you freaking lamers"
  29317.  
  29318. All through the time I worked there RIPv2 had little demand, since I'm
  29319. still in touch with folks there it is pretty much the same.  The demand
  29320. was always for *a* VLSM/CIDR protocol.  A lot of people said RIPv2 because
  29321. of bad experiences with Ascend OSPF, or complexity on Cisco, etc.  When
  29322. Livingston released OSPF and people actually tried it and found it easy to
  29323. use, well, request for RIPv2 all but dried up.  I mean it - requests for
  29324. it dropped right off the radar.  Had demand remained it would have shipped -
  29325. the guy who did OSPF and BGP also did RIPv2.  In fact, he did it *first* to
  29326. get warmed up.  
  29327.  
  29328. I'm given to understand the reason it is being added now is more for
  29329. marketing - people have checkboxes and look for RIPv2.  Also, they are
  29330. getting PM-4s into users who have Ascend gear and are using RIPv2 because
  29331. of OSPF trouble, replacing TCs where users are RIPv2 because they don't
  29332. have OSPF in the first place, etc.  As they take more marketshare the
  29333. need for RIPv2 just to be able to replace other vendors' lame HW has
  29334. increased.
  29335.  
  29336. OSPF will still be the recommended protocol.  RIPv2 will be there if someone
  29337. just has to have it - but isn't going to be trumpted.  It *is* lame.  I
  29338. wouldn't be surprised if they added it because of some big customer saying
  29339. they'd buy PMs if they did.  Seeing as they've had the code on the shelf
  29340. for a few years it wouldn't be a big investment to land a deal.  But I know
  29341. from talking to the engineers that no one really believes RIPv2 is worth it
  29342. on its own merits.
  29343.  
  29344. -MZ
  29345. -- 
  29346. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  29347. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  29348. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  29349. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  29350. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  29351.  
  29352. -
  29353.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29354.  with "unsubscribe usr-tc" in the body of the message.
  29355.  For information on digests or retrieving files and old messages send
  29356.  "help" to the same address.  Do not use quotes in your message.
  29357.  
  29358.  
  29359. -------------------------------------------------------------------------------
  29360.  
  29361. From: Paul Farber <farber@admin.f-tech.net>
  29362. Subject: Re: (usr-tc) Fast busy problem
  29363. Date: 24 Mar 1999 18:56:09 -0500 (EST)
  29364.  
  29365. Ask the telco to check the translations for your hunt groups.  Bell got me
  29366. 3 times on that.
  29367.  
  29368. Paul D. Farber II
  29369. Farber Technology
  29370. Ph. 570-628-5303
  29371. Fax 570-628-5545
  29372. farber@admin.f-tech.net
  29373.  
  29374. On Wed, 24 Mar 1999, Robert Reynolds wrote:
  29375.  
  29376. > I upgraded to DSP 1.2.43 & HiPer ARC 4.1.59-6 last week.  There are 4 DSP
  29377. > cards in this box.  Monday, when the first two spans filled up I would get
  29378. > fast busies.  I noticed I was getting Invalid Channel ID errors so I took
  29379. > the span out of service and it rooled over to the fourth span fine.
  29380. > When I put the card back in service it started working after
  29381. > about 2 minutes.  I did notice a loopback/d-channel alarm during that 
  29382. > 2 minutes but then all was well. Today the fourth span had the same
  29383. > problem.  The first 3 spans filled up fine then fast busy signals. I reset
  29384. > the card on the fourth span then all was well.
  29385. > 
  29386. > These are all PRI's.
  29387. > 
  29388. > Anyone else notice this problem?
  29389. > 
  29390. > 
  29391. > -
  29392. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29393. >  with "unsubscribe usr-tc" in the body of the message.
  29394. >  For information on digests or retrieving files and old messages send
  29395. >  "help" to the same address.  Do not use quotes in your message.
  29396. > 
  29397.  
  29398.  
  29399. -
  29400.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29401.  with "unsubscribe usr-tc" in the body of the message.
  29402.  For information on digests or retrieving files and old messages send
  29403.  "help" to the same address.  Do not use quotes in your message.
  29404.  
  29405.  
  29406. -------------------------------------------------------------------------------
  29407.  
  29408. From: Paul Farber <farber@admin.f-tech.net>
  29409. Subject: Re: (usr-tc) Assistance Needed Help!!!!
  29410. Date: 24 Mar 1999 19:01:02 -0500 (EST)
  29411.  
  29412. Just a guess.. its on a different network?  You box is on network 46 while
  29413. your modems are on network 47 (assuming a class c and no further
  29414. subnetting).
  29415.  
  29416. Paul D. Farber II
  29417. Farber Technology
  29418. Ph. 570-628-5303
  29419. Fax 570-628-5545
  29420. farber@admin.f-tech.net
  29421.  
  29422. On Wed, 24 Mar 1999 vanhalen@coredcs.com wrote:
  29423.  
  29424. > Hello-
  29425. > 
  29426. > I'm trying to reprovision our isdn box(netserver with quads) here with
  29427. > different ip's and move the range down.  In other words, it was
  29428. > xxx.xxx.47.240 with a size of 12. I tried to move it to xxx.xxx.47.225
  29429. > with the same size of 12.  I did this with the 'set assigned
  29430. > xxx.xxx.47.225' command and did a save all and reboot.  Upon reboot anyone
  29431. > who dials into the box with the box cannot get out nor can I ping them.  A
  29432. > traceroute shows that the router knows what box to send it to but it just
  29433. > never gets there.
  29434. > 
  29435. > traceroute to xxx.xxx.47.232), 30 hops max,
  29436. > 40 byte packets
  29437. >  1  xxx.xxx.xxx.2  1.998 ms  2.128 ms  2.377 ms
  29438. >  2  xxx.xxx.xxx.4  3.746 ms  2.979 ms  3.567 ms
  29439. >  3  xxx.xxx.46.8  7.153 ms  6.639 ms  7.037 ms <--this is the isdn box
  29440. >  4  * * *   
  29441. > 
  29442. > 
  29443. > 
  29444. > Whatever more info is needed, i.e. show global or whatever, I can give.
  29445. > 
  29446. > Any help is appreciated.
  29447. > 
  29448. > Steve
  29449. > 
  29450. > 
  29451. > -
  29452. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29453. >  with "unsubscribe usr-tc" in the body of the message.
  29454. >  For information on digests or retrieving files and old messages send
  29455. >  "help" to the same address.  Do not use quotes in your message.
  29456. > 
  29457.  
  29458.  
  29459. -
  29460.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29461.  with "unsubscribe usr-tc" in the body of the message.
  29462.  For information on digests or retrieving files and old messages send
  29463.  "help" to the same address.  Do not use quotes in your message.
  29464.  
  29465.  
  29466. -------------------------------------------------------------------------------
  29467.  
  29468. From: Robert Reynolds <lists@lcii.net>
  29469. Subject: Re: (usr-tc) Fast busy problem
  29470. Date: 24 Mar 1999 18:56:01 -0600 (EST)
  29471.  
  29472. Did that yesterday, all was well.
  29473.  
  29474. On Wed, 24 Mar 1999, Paul Farber wrote:
  29475.  
  29476. > Ask the telco to check the translations for your hunt groups.  Bell got me
  29477. > 3 times on that.
  29478. > 
  29479. > Paul D. Farber II
  29480. > Farber Technology
  29481. > Ph. 570-628-5303
  29482. > Fax 570-628-5545
  29483. > farber@admin.f-tech.net
  29484. > 
  29485. > On Wed, 24 Mar 1999, Robert Reynolds wrote:
  29486. > 
  29487. > > I upgraded to DSP 1.2.43 & HiPer ARC 4.1.59-6 last week.  There are 4 DSP
  29488. > > cards in this box.  Monday, when the first two spans filled up I would get
  29489. > > fast busies.  I noticed I was getting Invalid Channel ID errors so I took
  29490. > > the span out of service and it rooled over to the fourth span fine.
  29491. > > When I put the card back in service it started working after
  29492. > > about 2 minutes.  I did notice a loopback/d-channel alarm during that 
  29493. > > 2 minutes but then all was well. Today the fourth span had the same
  29494. > > problem.  The first 3 spans filled up fine then fast busy signals. I reset
  29495. > > the card on the fourth span then all was well.
  29496. > > 
  29497. > > These are all PRI's.
  29498. > > 
  29499. > > Anyone else notice this problem?
  29500. > > 
  29501. > > 
  29502. > > -
  29503. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29504. > >  with "unsubscribe usr-tc" in the body of the message.
  29505. > >  For information on digests or retrieving files and old messages send
  29506. > >  "help" to the same address.  Do not use quotes in your message.
  29507. > > 
  29508. > 
  29509. > 
  29510. > -
  29511. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29512. >  with "unsubscribe usr-tc" in the body of the message.
  29513. >  For information on digests or retrieving files and old messages send
  29514. >  "help" to the same address.  Do not use quotes in your message.
  29515. > 
  29516.  
  29517.  
  29518. -
  29519.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29520.  with "unsubscribe usr-tc" in the body of the message.
  29521.  For information on digests or retrieving files and old messages send
  29522.  "help" to the same address.  Do not use quotes in your message.
  29523.  
  29524.  
  29525. -------------------------------------------------------------------------------
  29526.  
  29527. From: Dan Hollis <goemon@sasami.anime.net>
  29528. Subject: Re: (usr-tc) Buying 1st USR-TC
  29529. Date: 24 Mar 1999 16:17:18 -0800 (PST)
  29530.  
  29531. On Wed, 24 Mar 1999, MegaZone wrote:
  29532. > OSPF will still be the recommended protocol.  RIPv2 will be there if someone
  29533. > just has to have it - but isn't going to be trumpted.  It *is* lame.
  29534.  
  29535. Any lamer than doing RIPv1 but not RIPv2? I never understood this. How
  29536. long does it take to do a RIPv2 implementation from a RIPv1 one? A day or
  29537. two max? Why Livingston blew it off for *years*, in favor of the long
  29538. development time of a far more complex protocol, Ill never understand.
  29539.  
  29540. > I wouldn't be surprised if they added it because of some big customer
  29541. > saying they'd buy PMs if they did.  Seeing as they've had the code on
  29542. > the shelf for a few years it wouldn't be a big investment to land a
  29543. > deal.  But I know from talking to the engineers that no one really
  29544. > believes RIPv2 is worth it on its own merits.
  29545.  
  29546. Its all about interoperability with the lowest common denominator.
  29547. Apparently Livingston/Lucent couldnt be bothered with that. Or maybe the
  29548. pointy haired ones were too closely involved in micromanaging development.
  29549. In any case I think it was a mistake to overlook the lowest common
  29550. denominator for so long.
  29551.  
  29552. -Dan
  29553.  
  29554.  
  29555. -
  29556.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29557.  with "unsubscribe usr-tc" in the body of the message.
  29558.  For information on digests or retrieving files and old messages send
  29559.  "help" to the same address.  Do not use quotes in your message.
  29560.  
  29561.  
  29562. -------------------------------------------------------------------------------
  29563.  
  29564. From: Blake Fithen <fithen@NetworksPlus.com>
  29565. Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  29566. Date: 24 Mar 1999 18:40:29 -0600
  29567.  
  29568. We (me/TELCO) isolated and verified the problem down to
  29569. not enough TELCO infrastructure trunks between there and
  29570. here.  TELCO problem.
  29571.  
  29572. blake
  29573.  
  29574. > -----Original Message-----
  29575. > From: Mike Hamrich [mailto:mikeh@drfast.net]
  29576. > Sent: Sunday, March 21, 1999 10:13 PM
  29577. > To: usr-tc@lists.xmission.com
  29578. > Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  29579. > 
  29580. > 
  29581. > Blake, before you did the upgrade how did you have the NMC 
  29582. > set to answer
  29583. > ISDN calls, on the Quads or the Netserver?
  29584. > -----Original Message-----
  29585. > From: Blake Fithen <fithen@NetworksPlus.com>
  29586. > To: 'usr-tc@lists.xmission.com' <usr-tc@lists.xmission.com>
  29587. > Date: Thursday, March 18, 1999 9:11 PM
  29588. > Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  29589. > 
  29590. > 
  29591. > >ARC 4.1.59-6
  29592. > >DSP 1.2.43
  29593. > >
  29594. > >The only thing we having problems with are ISDN calls.  Analog
  29595. > >current link transmit rates are anywhere from 14,400 to 53,300.
  29596. > >But i haven't seen a single ISDN call get established and pass
  29597. > >data. mon ppp, and mon radius show nothing - "li co"  will show
  29598. > >the modem being tied up but after about 10 seconds it drops.  I
  29599. > >had a few ISDN customers connected with 4.1.59 and 1.2.59 but
  29600. > >as soon as I upgraded the DSP to 1.2.43 things went downhill.
  29601. > >
  29602. > >[1 hour goes by]
  29603. > >
  29604. > >and at 7:30 my pager goes nuts saying that all our dedicated
  29605. > >ISDN customers are back up.  during this time i have been
  29606. > >gathering statistics from the incomplete ISDN calls and then
  29607. > >many dedicated customers with ISDN devices from many different
  29608. > >vendors begin working again without any intervention from me.
  29609. > >Ah! and everything came back up about the same time last night!
  29610. > >
  29611. > >WHAT THE HELL??!?!?!
  29612. > >
  29613. > >any similar experiences? TELCO sabotage?
  29614. > >
  29615. > >blake
  29616. > >
  29617. > >
  29618. > >> -----Original Message-----
  29619. > >> From: Mike Hamrich [mailto:mhamrich@drfast.net]
  29620. > >> Sent: Thursday, March 18, 1999 7:21 PM
  29621. > >> To: usr-tc@lists.xmission.com
  29622. > >> Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  29623. > >>
  29624. > >>
  29625. > >> OK HiperArc with latest code 3/4/99
  29626. > >>
  29627. > >> Since the "upgrade" we are having tons of connection issues.
  29628. > >> Couriers can't connect
  29629. > >> Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  29630. > >> OEM/Brown box Sportsters can't stay connected
  29631. > >>
  29632. > >> We also told owner of non X2 modem to go elsewere.
  29633. > >>
  29634. > >> We surveyed our users, 248 replied so far:
  29635. > >> 67% say slower speed, 22% are having problems saying
  29636. > >> connected, 4% can't
  29637. > >> connect at all, and ONLY 7%  report better connection.
  29638. > >>
  29639. > >> We have PRI lines, Set PPP offloading to no, Authenticate ANY
  29640. > >> Preferrd PAP
  29641. > >>
  29642. > >> Any other ideas to make this stuff work as well as the old 
  29643. > stuff did?
  29644. > >>
  29645. > >> Thanks in advance for you help
  29646. > >>
  29647. > >> Mike Hamrich
  29648. > >> CIO, DrFast.Net, Inc.
  29649. > >> (216) 797-1040
  29650. > >>
  29651. > >>
  29652. > >> -
  29653. > >>  To unsubscribe to usr-tc, send an email to 
  29654. > "majordomo@xmission.com"
  29655. > >>  with "unsubscribe usr-tc" in the body of the message.
  29656. > >>  For information on digests or retrieving files and old 
  29657. > messages send
  29658. > >>  "help" to the same address.  Do not use quotes in your message.
  29659. > >>
  29660. > >
  29661. > >-
  29662. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29663. > > with "unsubscribe usr-tc" in the body of the message.
  29664. > > For information on digests or retrieving files and old messages send
  29665. > > "help" to the same address.  Do not use quotes in your message.
  29666. > 
  29667. > -
  29668. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29669. >  with "unsubscribe usr-tc" in the body of the message.
  29670. >  For information on digests or retrieving files and old messages send
  29671. >  "help" to the same address.  Do not use quotes in your message.
  29672. > 
  29673.  
  29674. -
  29675.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29676.  with "unsubscribe usr-tc" in the body of the message.
  29677.  For information on digests or retrieving files and old messages send
  29678.  "help" to the same address.  Do not use quotes in your message.
  29679.  
  29680.  
  29681. -------------------------------------------------------------------------------
  29682.  
  29683. From: Blake Fithen <fithen@NetworksPlus.com>
  29684. Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  29685. Date: 24 Mar 1999 18:46:11 -0600
  29686.  
  29687. P.S.  everything else seems to be going pretty good with this specific 
  29688. firmware revision. (ARC 4.1.59-6, DSP 1.2.43)
  29689.  
  29690. blake
  29691.  
  29692. > -----Original Message-----
  29693. > From: Blake Fithen [mailto:fithen@NetworksPlus.com]
  29694. > Sent: Wednesday, March 24, 1999 6:40 PM
  29695. > To: 'usr-tc@lists.xmission.com'
  29696. > Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  29697. > 
  29698. > 
  29699. > We (me/TELCO) isolated and verified the problem down to
  29700. > not enough TELCO infrastructure trunks between there and
  29701. > here.  TELCO problem.
  29702. > 
  29703. > blake
  29704. > 
  29705. > > -----Original Message-----
  29706. > > From: Mike Hamrich [mailto:mikeh@drfast.net]
  29707. > > Sent: Sunday, March 21, 1999 10:13 PM
  29708. > > To: usr-tc@lists.xmission.com
  29709. > > Subject: Re: (usr-tc) Since HiperArc "upgrade" Couriers 
  29710. > can't connect
  29711. > > 
  29712. > > 
  29713. > > Blake, before you did the upgrade how did you have the NMC 
  29714. > > set to answer
  29715. > > ISDN calls, on the Quads or the Netserver?
  29716. > > -----Original Message-----
  29717. > > From: Blake Fithen <fithen@NetworksPlus.com>
  29718. > > To: 'usr-tc@lists.xmission.com' <usr-tc@lists.xmission.com>
  29719. > > Date: Thursday, March 18, 1999 9:11 PM
  29720. > > Subject: RE: (usr-tc) Since HiperArc "upgrade" Couriers 
  29721. > can't connect
  29722. > > 
  29723. > > 
  29724. > > >ARC 4.1.59-6
  29725. > > >DSP 1.2.43
  29726. > > >
  29727. > > >The only thing we having problems with are ISDN calls.  Analog
  29728. > > >current link transmit rates are anywhere from 14,400 to 53,300.
  29729. > > >But i haven't seen a single ISDN call get established and pass
  29730. > > >data. mon ppp, and mon radius show nothing - "li co"  will show
  29731. > > >the modem being tied up but after about 10 seconds it drops.  I
  29732. > > >had a few ISDN customers connected with 4.1.59 and 1.2.59 but
  29733. > > >as soon as I upgraded the DSP to 1.2.43 things went downhill.
  29734. > > >
  29735. > > >[1 hour goes by]
  29736. > > >
  29737. > > >and at 7:30 my pager goes nuts saying that all our dedicated
  29738. > > >ISDN customers are back up.  during this time i have been
  29739. > > >gathering statistics from the incomplete ISDN calls and then
  29740. > > >many dedicated customers with ISDN devices from many different
  29741. > > >vendors begin working again without any intervention from me.
  29742. > > >Ah! and everything came back up about the same time last night!
  29743. > > >
  29744. > > >WHAT THE HELL??!?!?!
  29745. > > >
  29746. > > >any similar experiences? TELCO sabotage?
  29747. > > >
  29748. > > >blake
  29749. > > >
  29750. > > >
  29751. > > >> -----Original Message-----
  29752. > > >> From: Mike Hamrich [mailto:mhamrich@drfast.net]
  29753. > > >> Sent: Thursday, March 18, 1999 7:21 PM
  29754. > > >> To: usr-tc@lists.xmission.com
  29755. > > >> Subject: (usr-tc) Since HiperArc "upgrade" Couriers can't connect
  29756. > > >>
  29757. > > >>
  29758. > > >> OK HiperArc with latest code 3/4/99
  29759. > > >>
  29760. > > >> Since the "upgrade" we are having tons of connection issues.
  29761. > > >> Couriers can't connect
  29762. > > >> Owners of Sporsters flashed with Feb '99 v.90 code connect slower
  29763. > > >> OEM/Brown box Sportsters can't stay connected
  29764. > > >>
  29765. > > >> We also told owner of non X2 modem to go elsewere.
  29766. > > >>
  29767. > > >> We surveyed our users, 248 replied so far:
  29768. > > >> 67% say slower speed, 22% are having problems saying
  29769. > > >> connected, 4% can't
  29770. > > >> connect at all, and ONLY 7%  report better connection.
  29771. > > >>
  29772. > > >> We have PRI lines, Set PPP offloading to no, Authenticate ANY
  29773. > > >> Preferrd PAP
  29774. > > >>
  29775. > > >> Any other ideas to make this stuff work as well as the old 
  29776. > > stuff did?
  29777. > > >>
  29778. > > >> Thanks in advance for you help
  29779. > > >>
  29780. > > >> Mike Hamrich
  29781. > > >> CIO, DrFast.Net, Inc.
  29782. > > >> (216) 797-1040
  29783. > > >>
  29784. > > >>
  29785. > > >> -
  29786. > > >>  To unsubscribe to usr-tc, send an email to 
  29787. > > "majordomo@xmission.com"
  29788. > > >>  with "unsubscribe usr-tc" in the body of the message.
  29789. > > >>  For information on digests or retrieving files and old 
  29790. > > messages send
  29791. > > >>  "help" to the same address.  Do not use quotes in your message.
  29792. > > >>
  29793. > > >
  29794. > > >-
  29795. > > > To unsubscribe to usr-tc, send an email to 
  29796. > "majordomo@xmission.com"
  29797. > > > with "unsubscribe usr-tc" in the body of the message.
  29798. > > > For information on digests or retrieving files and old 
  29799. > messages send
  29800. > > > "help" to the same address.  Do not use quotes in your message.
  29801. > > 
  29802. > > -
  29803. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29804. > >  with "unsubscribe usr-tc" in the body of the message.
  29805. > >  For information on digests or retrieving files and old 
  29806. > messages send
  29807. > >  "help" to the same address.  Do not use quotes in your message.
  29808. > > 
  29809. > 
  29810. > -
  29811. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29812. >  with "unsubscribe usr-tc" in the body of the message.
  29813. >  For information on digests or retrieving files and old messages send
  29814. >  "help" to the same address.  Do not use quotes in your message.
  29815. > 
  29816.  
  29817. -
  29818.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29819.  with "unsubscribe usr-tc" in the body of the message.
  29820.  For information on digests or retrieving files and old messages send
  29821.  "help" to the same address.  Do not use quotes in your message.
  29822.  
  29823.  
  29824. -------------------------------------------------------------------------------
  29825.  
  29826. From: "Randy McMillan" <randy@pacinfo.com>
  29827. Subject: Re: (usr-tc) Please elaborate on hiper/quad modem problem.
  29828. Date: 24 Mar 1999 17:49:32 -0800
  29829.  
  29830. Can someone elaborate on the problem with the Hiper 4.1.59-6 code and quad
  29831. modems.  We are setting up a couple of chassis like that.  They seem to work
  29832. OK when we are testing it with one modem in use.  Although we are having
  29833. some problems with our telco, and want to rule out a hiper/quad problem.
  29834.  
  29835. We have T1's
  29836. ppp authentication any
  29837. ppp authentication_preference PAP
  29838. ppp offloading enabled
  29839. ppp Receive ACCM disabled
  29840.  
  29841. When the authentication_preference was CHAP, it didn't authenticate for me.
  29842. Should I be having problems? and what sort?  Also, I don't think I saw
  29843. 4.1.62-4 on the USR web site. Thanks.
  29844.  
  29845. Randy McMillan
  29846. PacInfo
  29847.  
  29848. ----- Original Message -----
  29849. Sent: Wednesday, March 24, 1999 2:55 PM
  29850.  
  29851.  
  29852. >
  29853. >
  29854. >
  29855. >
  29856. > Ok, that's the problem.  Krish and I found out that with 4.1.59-6 and
  29857. > Quads, you must not have the Preferred protocol set to PAP.  Change it
  29858. > to DEFAULT or get off of 4.1.59-6 and Quads.  We are staying at 4.1.62-4
  29859. > for Quad racks.  Krish can elaborate more on the bug if you wish.
  29860. >
  29861. >
  29862. > Jeff Binkley
  29863. > ASA Network Computing
  29864. >
  29865. >
  29866. > u>----Original Message-----
  29867. >
  29868. >
  29869. > u>>On Fri, 19 Mar 1999, Jeff Binkley wrote:
  29870. > u>>> Krish,
  29871. > u>>> Note he has Preferred set to PAP which may be a problem with >quads
  29872. > u>as you and  I discovered the other day.
  29873. >
  29874. > u>We only have Quads installed
  29875. >
  29876. > u>>Well he is using DSP for the most part and also he is complaing
  29877. > u>>about speed and through put.  Disabling ppp offloading does slow
  29878. >
  29879. > u>No DSP installed yet, only the quads
  29880. >
  29881. > CMPQwk 1.42-21 9999
  29882. >
  29883. >
  29884. > -
  29885. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29886. >  with "unsubscribe usr-tc" in the body of the message.
  29887. >  For information on digests or retrieving files and old messages send
  29888. >  "help" to the same address.  Do not use quotes in your message.
  29889. >
  29890.  
  29891.  
  29892. -
  29893.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29894.  with "unsubscribe usr-tc" in the body of the message.
  29895.  For information on digests or retrieving files and old messages send
  29896.  "help" to the same address.  Do not use quotes in your message.
  29897.  
  29898.  
  29899. -------------------------------------------------------------------------------
  29900.  
  29901. From: Brian <signal@shreve.net>
  29902. Subject: (usr-tc) Best HDM/ARC mix
  29903. Date: 24 Mar 1999 20:05:10 -0600 (EST)
  29904.  
  29905.  
  29906. What are you all finding as the best code set to be on right now?  We run:
  29907.  
  29908. ARC: 4.1.59-1
  29909. HDM: 1.2.60
  29910.  
  29911. And are pretty happy with it, but feel alot of modems should be connecting
  29912. better etc.
  29913.  
  29914. Has anyone used the above codeset, and then moved on to something they
  29915. found even better?  If so what code?
  29916.  
  29917. Brian
  29918.  
  29919.  
  29920. Brian Feeny (BF304)     signal@shreve.net   
  29921. 318-222-2638 x 109    http://www.shreve.net/~signal      
  29922. Network Administrator   ShreveNet Inc. (ASN 11881)           
  29923.  
  29924.  
  29925. -
  29926.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  29927.  with "unsubscribe usr-tc" in the body of the message.
  29928.  For information on digests or retrieving files and old messages send
  29929.  "help" to the same address.  Do not use quotes in your message.
  29930.  
  29931.  
  29932. -------------------------------------------------------------------------------
  29933.  
  29934. From: pferraro@wna-linknet.com
  29935. Subject: Re: (usr-tc) Please elaborate on hiper/quad modem problem.
  29936. Date: 24 Mar 1999 22:39:43 -0500 (EST)
  29937.  
  29938.  
  29939.     I too would like to know about this!  We currently run 4.1.72-7 on
  29940. th equad rack and have not experienced any real problems.  We run 4.1.59-1
  29941. on the rack with DSPs running  1.2.60  We plan to upgrade both racks next
  29942. week and want to be absolutely SURE we won't have any difficulties. Want
  29943. to move to 4.1.59-6 on both HiperArcs and 1.2.43 for the DSPs!
  29944.  
  29945. ==============================================================================
  29946. Phillip Ferraro                WorldNet Access, Inc
  29947. pferraro@wna-linknet.com    Onslow County's PREMIER InterNet Service 
  29948. Voice (910) 346-0835            824 Gumbranch Square, Suite R3
  29949. FAX   (910) 455-1933             Jacksonville, Nc  28540-6269
  29950. ==============================================================================
  29951.  
  29952. On Wed, 24 Mar 1999, Randy McMillan wrote:
  29953.  
  29954. > Can someone elaborate on the problem with the Hiper 4.1.59-6 code and quad
  29955. > modems.  We are setting up a couple of chassis like that.  They seem to work
  29956. > OK when we are testing it with one modem in use.  Although we are having
  29957. > some problems with our telco, and want to rule out a hiper/quad problem.
  29958. > 
  29959. > We have T1's
  29960. > ppp authentication any
  29961. > ppp authentication_preference PAP
  29962. > ppp offloading enabled
  29963. > ppp Receive ACCM disabled
  29964. > 
  29965. > When the authentication_preference was CHAP, it didn't authenticate for me.
  29966. > Should I be having problems? and what sort?  Also, I don't think I saw
  29967. > 4.1.62-4 on the USR web site. Thanks.
  29968. > 
  29969. > Randy McMillan
  29970. > PacInfo
  29971. > 
  29972. > ----- Original Message -----
  29973. > From: Jeff Binkley <jeff.binkley@asacomp.com>
  29974. > To: <usr-tc@lists.xmission.com>
  29975. > Sent: Wednesday, March 24, 1999 2:55 PM
  29976. > Subject: Re: (usr-tc) RE: (USR-TC)
  29977. > 
  29978. > 
  29979. > >
  29980. > >
  29981. > >
  29982. > >
  29983. > > Ok, that's the problem.  Krish and I found out that with 4.1.59-6 and
  29984. > > Quads, you must not have the Preferred protocol set to PAP.  Change it
  29985. > > to DEFAULT or get off of 4.1.59-6 and Quads.  We are staying at 4.1.62-4
  29986. > > for Quad racks.  Krish can elaborate more on the bug if you wish.
  29987. > >
  29988. > >
  29989. > > Jeff Binkley
  29990. > > ASA Network Computing
  29991. > >
  29992. > >
  29993. > > u>----Original Message-----
  29994. > >
  29995. > >
  29996. > > u>>On Fri, 19 Mar 1999, Jeff Binkley wrote:
  29997. > > u>>> Krish,
  29998. > > u>>> Note he has Preferred set to PAP which may be a problem with >quads
  29999. > > u>as you and  I discovered the other day.
  30000. > >
  30001. > > u>We only have Quads installed
  30002. > >
  30003. > > u>>Well he is using DSP for the most part and also he is complaing
  30004. > > u>>about speed and through put.  Disabling ppp offloading does slow
  30005. > >
  30006. > > u>No DSP installed yet, only the quads
  30007. > >
  30008. > > CMPQwk 1.42-21 9999
  30009. > >
  30010. > >
  30011. > > -
  30012. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30013. > >  with "unsubscribe usr-tc" in the body of the message.
  30014. > >  For information on digests or retrieving files and old messages send
  30015. > >  "help" to the same address.  Do not use quotes in your message.
  30016. > >
  30017. > 
  30018. > 
  30019. > -
  30020. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30021. >  with "unsubscribe usr-tc" in the body of the message.
  30022. >  For information on digests or retrieving files and old messages send
  30023. >  "help" to the same address.  Do not use quotes in your message.
  30024. > 
  30025.  
  30026.  
  30027.  
  30028. -
  30029.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30030.  with "unsubscribe usr-tc" in the body of the message.
  30031.  For information on digests or retrieving files and old messages send
  30032.  "help" to the same address.  Do not use quotes in your message.
  30033.  
  30034.  
  30035. -------------------------------------------------------------------------------
  30036.  
  30037. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  30038. Subject: Re: (usr-tc) Please elaborate on hiper/quad modem problem.
  30039. Date: 24 Mar 1999 22:11:55 -0600 (CST)
  30040.  
  30041. On Wed, 24 Mar 1999, Randy McMillan wrote:
  30042.  
  30043. > Can someone elaborate on the problem with the Hiper 4.1.59-6 code and quad
  30044. > modems.  We are setting up a couple of chassis like that.  They seem to work
  30045. > OK when we are testing it with one modem in use.  Although we are having
  30046. > some problems with our telco, and want to rule out a hiper/quad problem.
  30047. > 
  30048.  
  30049. Quad and HiPer arc have no problems.  There is a know issue with broken 
  30050. Webramp code.  Per Webramp 1.0.6 code should solve the issues, but there 
  30051. are issues still from what we see.  
  30052. With Webramp chap works fine but PAP does not.  If you disable ppp 
  30053. offloading on the hiper arc both pap and chap work fine with Quad modems.
  30054.  
  30055. This is the issue. 
  30056.  
  30057.  
  30058. krish
  30059.  
  30060. > We have T1's
  30061. > ppp authentication any
  30062. > ppp authentication_preference PAP
  30063. > ppp offloading enabled
  30064. > ppp Receive ACCM disabled
  30065. > 
  30066. > When the authentication_preference was CHAP, it didn't authenticate for me.
  30067. > Should I be having problems? and what sort?  Also, I don't think I saw
  30068. > 4.1.62-4 on the USR web site. Thanks.
  30069. > 
  30070. > Randy McMillan
  30071. > PacInfo
  30072. > 
  30073. > ----- Original Message -----
  30074. > From: Jeff Binkley <jeff.binkley@asacomp.com>
  30075. > To: <usr-tc@lists.xmission.com>
  30076. > Sent: Wednesday, March 24, 1999 2:55 PM
  30077. > Subject: Re: (usr-tc) RE: (USR-TC)
  30078. > 
  30079. > 
  30080. > >
  30081. > >
  30082. > >
  30083. > >
  30084. > > Ok, that's the problem.  Krish and I found out that with 4.1.59-6 and
  30085. > > Quads, you must not have the Preferred protocol set to PAP.  Change it
  30086. > > to DEFAULT or get off of 4.1.59-6 and Quads.  We are staying at 4.1.62-4
  30087. > > for Quad racks.  Krish can elaborate more on the bug if you wish.
  30088. > >
  30089. > >
  30090. > > Jeff Binkley
  30091. > > ASA Network Computing
  30092. > >
  30093. > >
  30094. > > u>----Original Message-----
  30095. > >
  30096. > >
  30097. > > u>>On Fri, 19 Mar 1999, Jeff Binkley wrote:
  30098. > > u>>> Krish,
  30099. > > u>>> Note he has Preferred set to PAP which may be a problem with >quads
  30100. > > u>as you and  I discovered the other day.
  30101. > >
  30102. > > u>We only have Quads installed
  30103. > >
  30104. > > u>>Well he is using DSP for the most part and also he is complaing
  30105. > > u>>about speed and through put.  Disabling ppp offloading does slow
  30106. > >
  30107. > > u>No DSP installed yet, only the quads
  30108. > >
  30109. > > CMPQwk 1.42-21 9999
  30110. > >
  30111. > >
  30112. > > -
  30113. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30114. > >  with "unsubscribe usr-tc" in the body of the message.
  30115. > >  For information on digests or retrieving files and old messages send
  30116. > >  "help" to the same address.  Do not use quotes in your message.
  30117. > >
  30118. > 
  30119. > 
  30120. > -
  30121. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30122. >  with "unsubscribe usr-tc" in the body of the message.
  30123. >  For information on digests or retrieving files and old messages send
  30124. >  "help" to the same address.  Do not use quotes in your message.
  30125. > 
  30126.  
  30127. -
  30128.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30129.  with "unsubscribe usr-tc" in the body of the message.
  30130.  For information on digests or retrieving files and old messages send
  30131.  "help" to the same address.  Do not use quotes in your message.
  30132.  
  30133.  
  30134. -------------------------------------------------------------------------------
  30135.  
  30136. From: "T.J. Weber" <tjw-pop@ipmedia.net>
  30137. Subject: (usr-tc) RADIUS Daemons that Support Realms
  30138. Date: 24 Mar 1999 23:31:58 -0600
  30139.  
  30140.  
  30141. Hi, I'm in seek of if a RADIUS daemon that supports realms.  What I need
  30142. to be able to do is authenticate users by domain, for example
  30143. user@my-domain.com and user@reseller-domain.com.  Simple accounting is
  30144. all that is needed which will send basic information back to the acc't
  30145. server with the user@domain.  I would like to stay in the low price
  30146. range (as in free).  I know that Merit AAA supports this, how about the
  30147. basic Merit server?  Cistron? Any others I should know about?
  30148.  
  30149. Thanks,
  30150. --t.j.
  30151.  
  30152. --
  30153. T.J. Weber                      | James: "I hear that if you play the
  30154. Interplanetary Media            |         NT 4.0 CD backwards, you
  30155. phone:             847.205.5200 |         get a Satanic message!"
  30156. fax:               847.205.5201 | Marc:  "That's nothing. If you
  30157. e-mail:         tjw@ipmedia.net |         play it forward, it installs
  30158. web:     http://www.ipmedia.net |         NT 4.0!"
  30159.       He's not dead, he's       /  You have the right to remain 
  30160.   electroencephalographically  /  silent.  Anything you say will
  30161.           challenged.         /  be misquoted and used against you.
  30162.  
  30163. -
  30164.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30165.  with "unsubscribe usr-tc" in the body of the message.
  30166.  For information on digests or retrieving files and old messages send
  30167.  "help" to the same address.  Do not use quotes in your message.
  30168.  
  30169.  
  30170. -------------------------------------------------------------------------------
  30171.  
  30172. From: "Lon R. Stockton, Jr." <lon@moonstar.com>
  30173. Subject: Re: (usr-tc) RADIUS Daemons that Support Realms
  30174. Date: 25 Mar 1999 00:44:16 -0500 (EST)
  30175.  
  30176.  
  30177.  
  30178. Trivial with Radiator <http://www.open.com.au/radiator/>, which
  30179. works great with TC gear as well.
  30180.  
  30181.  
  30182. On Wed, 24 Mar 1999, T.J. Weber wrote:
  30183.  
  30184. > 
  30185. > Hi, I'm in seek of if a RADIUS daemon that supports realms.  What I need
  30186. > to be able to do is authenticate users by domain, for example
  30187. > user@my-domain.com and user@reseller-domain.com.  Simple accounting is
  30188. > all that is needed which will send basic information back to the acc't
  30189. > server with the user@domain.  I would like to stay in the low price
  30190. > range (as in free).  I know that Merit AAA supports this, how about the
  30191. > basic Merit server?  Cistron? Any others I should know about?
  30192. > 
  30193. > Thanks,
  30194. > --t.j.
  30195. > 
  30196. > --
  30197. > T.J. Weber                      | James: "I hear that if you play the
  30198. > Interplanetary Media            |         NT 4.0 CD backwards, you
  30199. > phone:             847.205.5200 |         get a Satanic message!"
  30200. > fax:               847.205.5201 | Marc:  "That's nothing. If you
  30201. > e-mail:         tjw@ipmedia.net |         play it forward, it installs
  30202. > web:     http://www.ipmedia.net |         NT 4.0!"
  30203. > ----------------------------------------------------------------------
  30204. >       He's not dead, he's       /  You have the right to remain 
  30205. >   electroencephalographically  /  silent.  Anything you say will
  30206. >           challenged.         /  be misquoted and used against you.
  30207. > ----------------------------------------------------------------------
  30208. > 
  30209. > -
  30210. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30211. >  with "unsubscribe usr-tc" in the body of the message.
  30212. >  For information on digests or retrieving files and old messages send
  30213. >  "help" to the same address.  Do not use quotes in your message.
  30214. > 
  30215.  
  30216.  
  30217. -
  30218.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30219.  with "unsubscribe usr-tc" in the body of the message.
  30220.  For information on digests or retrieving files and old messages send
  30221.  "help" to the same address.  Do not use quotes in your message.
  30222.  
  30223.  
  30224. -------------------------------------------------------------------------------
  30225.  
  30226. From: Thomas C Kinnen <tkinnen@livingston.com>
  30227. Subject: Re: (usr-tc) RADIUS Daemons that Support Realms
  30228. Date: 24 Mar 1999 21:46:16 -0800
  30229.  
  30230. "T.J. Weber" wrote:
  30231.  
  30232. > Hi, I'm in seek of if a RADIUS daemon that supports realms.  What I need
  30233. > to be able to do is authenticate users by domain, for example
  30234. > user@my-domain.com and user@reseller-domain.com.  Simple accounting is
  30235. > all that is needed which will send basic information back to the acc't
  30236. > server with the user@domain.  I would like to stay in the low price
  30237. > range (as in free).  I know that Merit AAA supports this, how about the
  30238. > basic Merit server?  Cistron? Any others I should know about?
  30239.  
  30240. Not free but Lucent PortAuthorty and Lucent RADIUS ABM.  Both are JAVA
  30241. Based.
  30242.  
  30243. -- 
  30244. Thomas C Kinnen - <tkinnen@ra.lucent.com> <tkinnen@sobhrach.com>
  30245. [RADIUS Test Engineer] - LUCENT Technologies RABU
  30246. "All of the opinions stated above are my own and not my employer's,
  30247. unless they were given to me by my employer"
  30248.  
  30249. -
  30250.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30251.  with "unsubscribe usr-tc" in the body of the message.
  30252.  For information on digests or retrieving files and old messages send
  30253.  "help" to the same address.  Do not use quotes in your message.
  30254.  
  30255.  
  30256. -------------------------------------------------------------------------------
  30257.  
  30258. From: Dan Hollis <goemon@sasami.anime.net>
  30259. Subject: Re: (usr-tc) RADIUS Daemons that Support Realms
  30260. Date: 24 Mar 1999 21:49:00 -0800 (PST)
  30261.  
  30262. On Wed, 24 Mar 1999, T.J. Weber wrote:
  30263. > Hi, I'm in seek of if a RADIUS daemon that supports realms.  What I need
  30264. > to be able to do is authenticate users by domain, for example
  30265. > user@my-domain.com and user@reseller-domain.com.
  30266.  
  30267. Cistron does this.
  30268.  
  30269. http://homepage.cistron.nl/~miquels/radius/
  30270.  
  30271. -Dan
  30272.  
  30273.  
  30274. -
  30275.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30276.  with "unsubscribe usr-tc" in the body of the message.
  30277.  For information on digests or retrieving files and old messages send
  30278.  "help" to the same address.  Do not use quotes in your message.
  30279.  
  30280.  
  30281. -------------------------------------------------------------------------------
  30282.  
  30283. From: "T.J. Weber" <tjw-pop@ipmedia.net>
  30284. Subject: Re: (usr-tc) RADIUS Daemons that Support Realms
  30285. Date: 25 Mar 1999 00:10:14 -0600
  30286.  
  30287.  
  30288. Yes, I noticed that in a seperate Cistron readme file after I posted the
  30289. message.  Thanks to all of those who replied.  I'm sure I'm going to
  30290. have a lot of other questions regarding USR/3com TC equipment.
  30291.  
  30292. Thanks,
  30293. --t.j.
  30294.  
  30295. Dan Hollis wrote:
  30296. > 
  30297. > On Wed, 24 Mar 1999, T.J. Weber wrote:
  30298. > > Hi, I'm in seek of if a RADIUS daemon that supports realms.  What I need
  30299. > > to be able to do is authenticate users by domain, for example
  30300. > > user@my-domain.com and user@reseller-domain.com.
  30301. > 
  30302. > Cistron does this.
  30303. > 
  30304. > http://homepage.cistron.nl/~miquels/radius/
  30305. > 
  30306. > -Dan
  30307. > 
  30308. > -
  30309. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30310. >  with "unsubscribe usr-tc" in the body of the message.
  30311. >  For information on digests or retrieving files and old messages send
  30312. >  "help" to the same address.  Do not use quotes in your message.
  30313.  
  30314. --
  30315. T.J. Weber                      | James: "I hear that if you play the
  30316. Interplanetary Media            |         NT 4.0 CD backwards, you
  30317. phone:             847.205.5200 |         get a Satanic message!"
  30318. fax:               847.205.5201 | Marc:  "That's nothing. If you
  30319. e-mail:         tjw@ipmedia.net |         play it forward, it installs
  30320. web:     http://www.ipmedia.net |         NT 4.0!"
  30321.       He's not dead, he's       /  You have the right to remain 
  30322.   electroencephalographically  /  silent.  Anything you say will
  30323.           challenged.         /  be misquoted and used against you.
  30324.  
  30325. -
  30326.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30327.  with "unsubscribe usr-tc" in the body of the message.
  30328.  For information on digests or retrieving files and old messages send
  30329.  "help" to the same address.  Do not use quotes in your message.
  30330.  
  30331.  
  30332. -------------------------------------------------------------------------------
  30333.  
  30334. From: Ricky Beam <jfbeam@beaker.interpath.net>
  30335. Subject: Re: (usr-tc) Buying 1st USR-TC
  30336. Date: 25 Mar 1999 02:11:01 -0500 (EST)
  30337.  
  30338. On Wed, 24 Mar 1999, MegaZone wrote:
  30339. >Once upon a time Ricky Beam shaped the electrons to say...
  30340. >>Both.  It costs 3Com money to develop the software and people were stealing
  30341. >>money from them by buying one contract and putting that code on more than
  30342. >>one chassis.
  30343. >
  30344. >Funny that other vendors can give away OS upgrades for free, and they
  30345. >aren't goign bankrupt.  And are even charging per port prices in the same
  30346. >range as 3Com.  And then they give you free support, free management tools...
  30347.  
  30348. 3Com seems to be selling things based on what it cost to make the card not
  30349. what it has cost to develop and support the software, etc.
  30350.  
  30351. >>Do you really want to see 3Com wiring serial number checks in the code to
  30352. >>prevent you from loading code on a card that isn't under a software support
  30353. >
  30354. >I'd like to see them give the upgrades away - but that might mean respecting
  30355. >the customers and responding to the market.  So I won't hold my breath.
  30356.  
  30357. I never have :-)  For all 3Com's craziness, I really like the hardware.
  30358. Even so much as to learn to deal with their crazy business practices.
  30359.  
  30360. >>they aren't charging enough for the hardware itself -- the TC hardware is,
  30361. >>by far, much cheaper than competing hardware.
  30362. >
  30363. >Much cheaper?  Not that I've seen.  Depending on the reseller, specials,
  30364. >etc, you can find other vendors' gear for less.  And prices across the
  30365. >board continue to decline.
  30366.  
  30367. 47 USR chassis: dual 70A PS, 12 Quads, dual PRI, NetServer, NMC
  30368.   Cost:  ~500k$ (two years ago)
  30369.    - support: 117k$ (full 24/7 hardware+software)
  30370. 47 Cisco AS5300s: single PS, single 48 port modem card, quad PRI "RSP"
  30371.   Cost: ~1.25M$ (a few months ago)
  30372.    - support: 188k$ (15% of purchase)
  30373.  
  30374. >Have you seen the latest (free) PM-4 open release? Jesus is it loaded.
  30375. ><URL:ftp://ftp.livingston.com/pub/le/doc/release/release41b14.txt> - free.
  30376. >The PM-4 itself is still pricey, but fairly new and prices are dropping.
  30377.  
  30378. The PM4 is an impressive critter.  I would have loved to play with one,
  30379. but there was this anti-lucent trend (something involving the desire to
  30380. put cisco gfx on the home page ??? (it's the only thing I can think of))
  30381.  
  30382. >I've also seen the notes for 3.9, but that isn't public yet.  Equally
  30383. >loaded, equally free.  And there will be a build for the PM-2 - of course
  30384. >if the PM-2 were 3Com it wou;d be 'obsolete' and 'discontinued' and you'd
  30385. >be told to 'upgrade' for any 'fix'...  Oh, did I get sarcasm on you?
  30386.  
  30387. We won't talk about their dropping the netserver (a mistake in my opinion,
  30388. but their NAS programming is far from what I would call "efficient".)  If
  30389. they want to shoot their feet out from under themselves, who am I to stop
  30390. them?
  30391.  
  30392. --Ricky
  30393.  
  30394.  
  30395.  
  30396. -
  30397.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30398.  with "unsubscribe usr-tc" in the body of the message.
  30399.  For information on digests or retrieving files and old messages send
  30400.  "help" to the same address.  Do not use quotes in your message.
  30401.  
  30402.  
  30403. -------------------------------------------------------------------------------
  30404.  
  30405. From: Ricky Beam <jfbeam@beaker.interpath.net>
  30406. Subject: Re: (usr-tc) Buying 1st USR-TC
  30407. Date: 25 Mar 1999 02:14:06 -0500 (EST)
  30408.  
  30409. On Wed, 24 Mar 1999, Dan Hollis wrote:
  30410. >On Wed, 24 Mar 1999, MegaZone wrote:
  30411. >> >Do you really want to see 3Com wiring serial number checks in the code to
  30412. >> >prevent you from loading code on a card that isn't under a software support
  30413. >> I'd like to see them give the upgrades away - but that might mean respecting
  30414. >> the customers and responding to the market.  So I won't hold my breath.
  30415. >
  30416. >Responding to the market. Hm. Then why did it take Lucent so long to
  30417. >support RIPv2. And why does it feel like Lucent is giving users the finger
  30418. >with the RIPv2 release. Eg "heres your RIPv2, you freaking lamers"
  30419.  
  30420. Well, I'd agree with the "screw RIP" attitude... the netblazers never did
  30421. RIPv2 either.  Come to think of it, it took IOS 11.1 to get the Cisco's to
  30422. handle RIPv2 as well. (or was it 10.3?  Anyway, we had to update IOS code
  30423. all over the place.  It was a bloody mess.)
  30424.  
  30425. --Ricky
  30426.  
  30427.  
  30428.  
  30429. -
  30430.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30431.  with "unsubscribe usr-tc" in the body of the message.
  30432.  For information on digests or retrieving files and old messages send
  30433.  "help" to the same address.  Do not use quotes in your message.
  30434.  
  30435.  
  30436. -------------------------------------------------------------------------------
  30437.  
  30438. From: Ricky Beam <jfbeam@beaker.interpath.net>
  30439. Subject: Re: (usr-tc) Buying 1st USR-TC
  30440. Date: 25 Mar 1999 02:17:57 -0500 (EST)
  30441.  
  30442. On Wed, 24 Mar 1999, Jeff Mcadams wrote:
  30443. >I kinda wondered about that comment too....we haven't seen that its much
  30444. >cheaper per port than much else, and sometimes more expensive.
  30445.  
  30446. For the high density stuff yes... for the average ISP (read: quads) the
  30447. USR hardware is pretty freakin' cheap. (esp. used :-))
  30448.  
  30449. >>3Com charges for just about everything.
  30450. >
  30451. >"just about?"  *ponders trying to think of something that they don't
  30452. >charge for in normal circumstances*
  30453.  
  30454. Umm, 3Com NIC drivers are free :-)
  30455.  
  30456. >>>PS: If you want "free" code updates, participate in the beta program and
  30457. >>>    actually give some feedback.  You'll have access to the code before it
  30458. >
  30459. >That's assuming they even acknowledge your request to be a part of the
  30460. >Beta process...hasn't happened yet for me.
  30461.  
  30462. I didn't have much of a problem... maybe I should go work for IgLou for
  30463. a few weeks :-) (I still have a palm pilot full of USR contacts.)
  30464.  
  30465. --Ricky
  30466.  
  30467.  
  30468.  
  30469. -
  30470.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30471.  with "unsubscribe usr-tc" in the body of the message.
  30472.  For information on digests or retrieving files and old messages send
  30473.  "help" to the same address.  Do not use quotes in your message.
  30474.  
  30475.  
  30476. -------------------------------------------------------------------------------
  30477.  
  30478. From: "Kalev Nurklik" <kalev@mail.lbi.ee>
  30479. Subject: Re: (usr-tc) Level "CRITICAL":: Deactivating Timer Fired on interface:
  30480. Date: 25 Mar 1999 13:05:17 +0200
  30481.  
  30482. I have seen this also in Harc log but I didn't associate entry with
  30483. dsp's going empty, which has also happened with no help from
  30484. imagination. Running 4.1.59-6 and 1.2.59 here.
  30485. Any info whats it all about is appreciated because I'm having
  30486. all sort of trouble here with our chassis. There is the dead modem
  30487. issue that I haven't found an answer yet.
  30488. If I make a cold start (had to last week) then all seemed to be fine.
  30489. But in time(week or so) there just couple of modems on some
  30490. dsp's that begin to die. BTW dead modems seem to like company -
  30491. there is always a pair of them.
  30492. "list pbus sess" show for those modems very little packets
  30493. processed and I guess the reason for their existence is because
  30494. they are generated in first couple of TCHs uptime days.
  30495. This issue has probably come up in this list but I couldn't get
  30496. any search output from list archive today.
  30497. Has anyone clue why these modems "die"?
  30498.  
  30499.  
  30500. > I have just noticed this error is syslogs, it seems to reset the whole card.
  30501. > Though I was imagining things, first the card was full, next it was empty??
  30502. > 
  30503. > At 20:40:00, Facility "Driver", Level "CRITICAL":: Deactivating Timer Fired
  30504. > on interface: slot:15/mod:16
  30505. > 
  30506. > 
  30507. > Sean Herr
  30508. > 
  30509. > -
  30510. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30511. >  with "unsubscribe usr-tc" in the body of the message.
  30512. >  For information on digests or retrieving files and old messages send
  30513. >  "help" to the same address.  Do not use quotes in your message.
  30514.  
  30515.  
  30516. __________________________________
  30517. Kalev Nurklik
  30518. MicroLink Online
  30519. Sakala 19, 10141 Tallinn, Estonia
  30520. Tel: +372 6 308 909
  30521. Fax: +372 6 308 901
  30522. E-mail: k.nurklik@online.ee
  30523. http://www.online.ee
  30524.  
  30525. -
  30526.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30527.  with "unsubscribe usr-tc" in the body of the message.
  30528.  For information on digests or retrieving files and old messages send
  30529.  "help" to the same address.  Do not use quotes in your message.
  30530.  
  30531.  
  30532. -------------------------------------------------------------------------------
  30533.  
  30534. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  30535. Subject: (usr-tc) Webramp Stac compression 
  30536. Date: 25 Mar 1999 06:58:30 -0600 (CST)
  30537.  
  30538.  
  30539. In the webramp GUI if you go to the advanced configuration section
  30540. you will find the option to disable the STAC compression. From
  30541. the command line you can use the setprofile command to do the
  30542. same.
  30543.  
  30544. setprofile "-n < profile id> -S < 1- enable 0 - disable>"
  30545.  
  30546. krish
  30547.  
  30548. -
  30549.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30550.  with "unsubscribe usr-tc" in the body of the message.
  30551.  For information on digests or retrieving files and old messages send
  30552.  "help" to the same address.  Do not use quotes in your message.
  30553.  
  30554.  
  30555. -------------------------------------------------------------------------------
  30556.  
  30557. From: "T.J. Weber" <tjw-pop@ipmedia.net>
  30558. Subject: (usr-tc) Assigning Different domain different IP blocks
  30559. Date: 25 Mar 1999 08:43:30 -0600
  30560.  
  30561.  
  30562. Hi, last night I posted a question asking about different RADIUS servers
  30563. that support realms.  Thanks for all your replies.  My next question is
  30564. how can I use the RADIUS server to assign different IP addresses.  For
  30565. example, we have two ISPs sharing one TC.  When a user logs in, his/her
  30566. username will be in the format user@domain-1.com or user@domain-2.com. 
  30567. I have decided to use the Cistron RADIUS server because it is free,
  30568. powerful, and now supports realms.  Now what I need to do is assign the
  30569. default user an address from a different pool.  For example,
  30570. domain-1.com will be using 192.168.1.0/24 and domain-2.com will be using
  30571. 192.168.2.0/24.  How do I configure this in the TC?  How do I configure
  30572. this in RADIUS?  Is there anything else that I need to know before I go
  30573. about doing this?
  30574.  
  30575. Thanks in advance,
  30576. --t.j. weber
  30577.  
  30578. --
  30579. T.J. Weber                      | James: "I hear that if you play the
  30580. Interplanetary Media            |         NT 4.0 CD backwards, you
  30581. phone:             847.205.5200 |         get a Satanic message!"
  30582. fax:               847.205.5201 | Marc:  "That's nothing. If you
  30583. e-mail:         tjw@ipmedia.net |         play it forward, it installs
  30584. web:     http://www.ipmedia.net |         NT 4.0!"
  30585.       He's not dead, he's       /  You have the right to remain 
  30586.   electroencephalographically  /  silent.  Anything you say will
  30587.           challenged.         /  be misquoted and used against you.
  30588.  
  30589. -
  30590.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30591.  with "unsubscribe usr-tc" in the body of the message.
  30592.  For information on digests or retrieving files and old messages send
  30593.  "help" to the same address.  Do not use quotes in your message.
  30594.  
  30595.  
  30596. -------------------------------------------------------------------------------
  30597.  
  30598. From: vanhalen@coredcs.com
  30599. Subject: (usr-tc) Follow up to Netserver ISDN problem
  30600. Date: 25 Mar 1999 09:14:15 -0600 (CST)
  30601.  
  30602. Hello-
  30603.  
  30604. This is a follow up for the netserver problem I posted yesterday.  We
  30605. still don't have a fix or reason as to why I cannot ping some customers
  30606. from the box and they cannot ping us.  Traceroutes show that the packet is
  30607. getting to the box and then it dies.
  30608.  
  30609. Here's part of the show global from the netserver, can anyone see anything
  30610. wrong with it?
  30611.  
  30612. PPP in modem: ON        SLIP in modem: OFF       Packet bus clock: SLAVE
  30613. ICMP error logging: ON  Connect message: ON      Dial !root access: OFF
  30614. Random hosts list: OFF  SNMP: OFF                Proxy Arp: ON
  30615. Response message: ON    PPP message: ON          Lan/Wan Routing: ON
  30616. RIP V2 Authen: OFF      VPN Local Routing: ON    MPIP Server: OFF
  30617. Hint assigned: OFF      Tap Login: OFF           Syslog facility: auth
  30618. Extd. IPXCP Opts: OFF   Acct AuthChk: OFF/OFF    Send DNS info: ON
  30619.  
  30620. Thanks for any help or pointers anyone can provide.
  30621.  
  30622. Steve   
  30623.  
  30624.  
  30625.  
  30626. -
  30627.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30628.  with "unsubscribe usr-tc" in the body of the message.
  30629.  For information on digests or retrieving files and old messages send
  30630.  "help" to the same address.  Do not use quotes in your message.
  30631.  
  30632.  
  30633. -------------------------------------------------------------------------------
  30634.  
  30635. From: <vanhalen@coredcs.com>
  30636. Subject: Re: (usr-tc) Assistance Needed Help!!!!
  30637. Date: 24 Mar 1999 18:51:01 -0600 (CST)
  30638.  
  30639. Thanks for the reply.  The problem is that I set it up originally with the
  30640. xxx.xxx.47.240 range and all I did was change the start address of the ip
  30641. within the 47 network.  It worked perfectly fine with the 47.240 range but
  30642. when moved to 47.225 it puked.
  30643.  
  30644. The other interesting thing related to this is that the customers who have
  30645. a static ip assigned to them are 100% fine and operational.  That ip is in
  30646. the xxx.xxx.45.xxx range.
  30647.  
  30648. The problem seems _only_ to be with the ip address pool and assignments
  30649. from the pool.
  30650.  
  30651. Thanks again for the reply.
  30652.  
  30653. Steve
  30654.  
  30655.  On Wed, 24 Mar 1999, Paul Farber wrote:
  30656.  
  30657. > Just a guess.. its on a different network?  You box is on network 46 while
  30658. > your modems are on network 47 (assuming a class c and no further
  30659. > subnetting).
  30660. > 
  30661. > Paul D. Farber II
  30662. > Farber Technology
  30663. > Ph. 570-628-5303
  30664. > Fax 570-628-5545
  30665. > farber@admin.f-tech.net
  30666. > 
  30667. > On Wed, 24 Mar 1999 vanhalen@coredcs.com wrote:
  30668. > 
  30669. > > Hello-
  30670. > > 
  30671. > > I'm trying to reprovision our isdn box(netserver with quads) here with
  30672. > > different ip's and move the range down.  In other words, it was
  30673. > > xxx.xxx.47.240 with a size of 12. I tried to move it to xxx.xxx.47.225
  30674. > > with the same size of 12.  I did this with the 'set assigned
  30675. > > xxx.xxx.47.225' command and did a save all and reboot.  Upon reboot anyone
  30676. > > who dials into the box with the box cannot get out nor can I ping them.  A
  30677. > > traceroute shows that the router knows what box to send it to but it just
  30678. > > never gets there.
  30679. > > 
  30680. > > traceroute to xxx.xxx.47.232), 30 hops max,
  30681. > > 40 byte packets
  30682. > >  1  xxx.xxx.xxx.2  1.998 ms  2.128 ms  2.377 ms
  30683. > >  2  xxx.xxx.xxx.4  3.746 ms  2.979 ms  3.567 ms
  30684. > >  3  xxx.xxx.46.8  7.153 ms  6.639 ms  7.037 ms <--this is the isdn box
  30685. > >  4  * * *   
  30686. > > 
  30687. > > 
  30688. > > 
  30689. > > Whatever more info is needed, i.e. show global or whatever, I can give.
  30690. > > 
  30691. > > Any help is appreciated.
  30692. > > 
  30693. > > Steve
  30694. > > 
  30695. > > 
  30696. > > -
  30697. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30698. > >  with "unsubscribe usr-tc" in the body of the message.
  30699. > >  For information on digests or retrieving files and old messages send
  30700. > >  "help" to the same address.  Do not use quotes in your message.
  30701. > > 
  30702. > 
  30703. > 
  30704. > -
  30705. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30706. >  with "unsubscribe usr-tc" in the body of the message.
  30707. >  For information on digests or retrieving files and old messages send
  30708. >  "help" to the same address.  Do not use quotes in your message.
  30709. > 
  30710.  
  30711. -
  30712.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30713.  with "unsubscribe usr-tc" in the body of the message.
  30714.  For information on digests or retrieving files and old messages send
  30715.  "help" to the same address.  Do not use quotes in your message.
  30716.  
  30717.  
  30718. -------------------------------------------------------------------------------
  30719.  
  30720. From: Carl Litt <carl@execulink.com>
  30721. Subject: (usr-tc) Call Failure Logging
  30722. Date: 24 Mar 1999 20:55:10 -0500 (EST)
  30723.  
  30724.  
  30725. (Sent this days ago but haven't seen it go through yet...)
  30726.  
  30727.  
  30728. Has anyone bothered counting the number of call failures on the
  30729. DSP's?  I have included a script below which parses through our
  30730. SNMP trap logs and generates a simple report on the number of call
  30731. failures ordered by modem.  The values get reset every midnight.
  30732.  
  30733. Here is a sample of what you get.  Note that this report was generated
  30734. mid afternoon.  I've confident that the top 7 modems have not
  30735. had a successfull call today.
  30736.  
  30737. Report generated: Fri Mar 19 15:00:01 EST 1999
  30738.  
  30739. Fails   NMC             Slot    Modem
  30740.  
  30741.      45 10.1.1.102      8       24
  30742.      45 10.1.1.102      8       23
  30743.      26 10.1.4.105      3       16
  30744.      26 10.1.4.105      3       15
  30745.      23 10.1.4.105      14      15
  30746.      22 10.1.4.105      3       6
  30747.      21 10.1.4.105      3       5
  30748.      18 10.1.5.11       15      6
  30749.      18 10.1.5.11       15      5
  30750. (NOTE: The above are all DSP's)
  30751.       7 10.1.5.11       6       3
  30752.       7 10.1.5.11       15      8
  30753.       5 10.1.5.11       4       1
  30754.  
  30755. Notice the trend of sequential pairs of modems with nearly the same
  30756. call failure rate?  As a witness to many of these reports, I can tell
  30757. you this is not even close to a rare occurrance.  And forget all the
  30758. BS about the 'telco'... at the 10.1.4.* site, _we_are_ the telco.
  30759. (The chassis' are barely 10 feet from the DMS100).
  30760.  
  30761. Since this report was generated rather early in the day, the values are
  30762. actually low.  By the end of the day, most of our pool is full, so these
  30763. bad modems are the only ones attempting to take calls.  I'll probably have
  30764. over 300 failures per bad modem by the end of the day.  ("good" modems
  30765. only have around 10-12 failures max. per day).
  30766.  
  30767. The only solution I've come up with to fix this is to reboot the DSP.
  30768. (Since this is not a desirable solution, I end up busying out the
  30769. associated DS0's and waiting until our _weekly_ chassis reboot).  Tried
  30770. resetting and dis/enabling the modems from the TCM, and soft-resetting the
  30771. modems.  Doesn't do a darn thing.  (BTW: Our code versions are ARC 4.1.72
  30772. and DSP 1.2.60, because I still don't trust the .59 codes... I mean, come
  30773. on... a bug fix for a bug fix???)
  30774.  
  30775.  
  30776. Here's how to set up this report:
  30777.  
  30778. On a Unix machine, set up the UCD-SNMP tools (snmptrapd in particular).
  30779.     (by default, it will syslog traps to LOG_LOCAL0, which you
  30780.     direct to /var/log/snmptraps).
  30781. Place the MIB files from the mib directory under TCM into the directory
  30782.     /usr/local/share/snmp/mibs on the UCD-SNMP machine.
  30783. Configure all of your modems to SNMP trap Incoming Call Failures to
  30784.     this machine.  (I actually trap all sorts of stuff).  This
  30785.     works with DSP's and Quadmodems.
  30786. Install the following scripts into /usr/local/bin.
  30787. Add a cron job to run 'publish_badmodems' every half hour.
  30788. Let the chaos unfold.
  30789.  
  30790. I don't claim that this will for for everyone.  I do know it works
  30791. for me.
  30792.  
  30793. --- publish_badmodems ---
  30794. #!/bin/sh
  30795.  
  30796. exec 1>/path/to/publish/to/badmodems.html
  30797.  
  30798. echo "<head></head><body>"
  30799. echo "<p>Report generated: `date`<hr><pre>"
  30800.  
  30801. echo -e "<b>Fails\tNMC\t\tSlot\tModem</b><p><hr>"
  30802. nice /usr/local/bin/parsefails
  30803.  
  30804. echo "</pre></body>"
  30805.  
  30806. --- parsefails ---
  30807. #!/bin/sh
  30808.  
  30809. if [ -f "$1" ]; then
  30810.         INFILE="$1"
  30811. else
  30812.         INFILE=/var/log/snmptraps
  30813. fi
  30814.  
  30815. egrep -i 'inconnectAttemptFailure|ctConnectAttemptFailure' $INFILE \
  30816.         | awk -f /usr/local/sbin/parsefails.awk \
  30817.         | sort -n | uniq -c | sort -nr
  30818.  
  30819. --- parsefails.awk ---
  30820. /Uptime: [0-9]* days?,/ { gsub("Uptime: [0-9]* days?,","Uptime: ") }
  30821.  
  30822. { gsub("[,:]","") }
  30823.  
  30824. /Trap \(inconnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }
  30825. /Trap \(ctConnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }
  30826.  
  30827. -
  30828.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30829.  with "unsubscribe usr-tc" in the body of the message.
  30830.  For information on digests or retrieving files and old messages send
  30831.  "help" to the same address.  Do not use quotes in your message.
  30832.  
  30833.  
  30834. -------------------------------------------------------------------------------
  30835.  
  30836. From: Carl Litt <carl@execulink.com>
  30837. Subject: (usr-tc) Call Failure Logging
  30838. Date: 19 Mar 1999 16:20:41 -0500 (EST)
  30839.  
  30840.  
  30841. Has anyone bothered counting the number of call failures on the
  30842. DSP's?  I have included a script below which parses through our
  30843. SNMP trap logs and generates a simple report on the number of call
  30844. failures ordered by modem.  The values get reset every midnight.
  30845.  
  30846. Here is a sample of what you get.  Note that this report was generated
  30847. mid afternoon.  I've confident that the top 7 modems have not
  30848. had a successfull call today.
  30849.  
  30850. Report generated: Fri Mar 19 15:00:01 EST 1999
  30851.  
  30852. Fails   NMC             Slot    Modem
  30853.  
  30854.      45 10.1.1.102      8       24
  30855.      45 10.1.1.102      8       23
  30856.      26 10.1.4.105      3       16
  30857.      26 10.1.4.105      3       15
  30858.      23 10.1.4.105      14      15
  30859.      22 10.1.4.105      3       6
  30860.      21 10.1.4.105      3       5
  30861.      18 10.1.5.11       15      6
  30862.      18 10.1.5.11       15      5
  30863. (NOTE: The above are all DSP's)
  30864.       7 10.1.5.11       6       3
  30865.       7 10.1.5.11       15      8
  30866.       5 10.1.5.11       4       1
  30867.  
  30868. Notice the trend of sequential pairs of modems with nearly the same
  30869. call failure rate?  As a witness to many of these reports, I can tell
  30870. you this is not even close to a rare occurrance.  And forget all the
  30871. BS about the 'telco'... at the 10.1.4.* site, _we_are_ the telco.
  30872. (The chassis' are barely 10 feet from the DMS100).
  30873.  
  30874. Since this report was generated rather early in the day, the values are
  30875. actually low.  By the end of the day, most of our pool is full, so these
  30876. bad modems are the only ones attempting to take calls.  I'll probably have
  30877. over 300 failures per bad modem by the end of the day.  ("good" modems
  30878. only have around 10-12 failures max. per day).
  30879.  
  30880. The only solution I've come up with to fix this is to reboot the DSP.
  30881. (Since this is not a desirable solution, I end up busying out the
  30882. associated DS0's and waiting until our _weekly_ chassis reboot).  Tried
  30883. resetting and dis/enabling the modems from the TCM, and soft-resetting the
  30884. modems.  Doesn't do a darn thing.  (BTW: Our code versions are ARC 4.1.72
  30885. and DSP 1.2.60, because I still don't trust the .59 codes... I mean, come
  30886. on... a bug fix for a bug fix???)
  30887.  
  30888.  
  30889. Here's how to set up this report:
  30890.  
  30891. On a Unix machine, set up the UCD-SNMP tools (snmptrapd in particular).
  30892.     (by default, it will syslog traps to LOG_LOCAL0, which you
  30893.     direct to /var/log/snmptraps).
  30894. Place the MIB files from the mib directory under TCM into the directory
  30895.     /usr/local/share/snmp/mibs on the UCD-SNMP machine.
  30896. Configure all of your modems to SNMP trap Incoming Call Failures to
  30897.     this machine.  (I actually trap all sorts of stuff).  This
  30898.     works with DSP's and Quadmodems.
  30899. Install the following scripts into /usr/local/bin.
  30900. Add a cron job to run 'publish_badmodems' every half hour.
  30901. Let the chaos unfold.
  30902.  
  30903. I don't claim that this will for for everyone.  I do know it works
  30904. for me.
  30905.  
  30906. --- publish_badmodems ---
  30907. #!/bin/sh
  30908.  
  30909. exec 1>/path/to/publish/to/badmodems.html
  30910.  
  30911. echo "<head></head><body>"
  30912. echo "<p>Report generated: `date`<hr><pre>"
  30913.  
  30914. echo -e "<b>Fails\tNMC\t\tSlot\tModem</b><p><hr>"
  30915. nice /usr/local/bin/parsefails
  30916.  
  30917. echo "</pre></body>"
  30918.  
  30919. --- parsefails ---
  30920. #!/bin/sh
  30921.  
  30922. if [ -f "$1" ]; then
  30923.         INFILE="$1"
  30924. else
  30925.         INFILE=/var/log/snmptraps
  30926. fi
  30927.  
  30928. egrep -i 'inconnectAttemptFailure|ctConnectAttemptFailure' $INFILE \
  30929.         | awk -f /usr/local/sbin/parsefails.awk \
  30930.         | sort -n | uniq -c | sort -nr
  30931.  
  30932. --- parsefails.awk ---
  30933. /Uptime: [0-9]* days?,/ { gsub("Uptime: [0-9]* days?,","Uptime: ") }
  30934.  
  30935. { gsub("[,:]","") }
  30936.  
  30937. /Trap \(inconnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }
  30938. /Trap \(ctConnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }
  30939.  
  30940. -
  30941.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30942.  with "unsubscribe usr-tc" in the body of the message.
  30943.  For information on digests or retrieving files and old messages send
  30944.  "help" to the same address.  Do not use quotes in your message.
  30945.  
  30946.  
  30947. -------------------------------------------------------------------------------
  30948.  
  30949. From: Pete Ashdown <pashdown@xmission.com>
  30950. Subject: Re: (usr-tc) PRI to overflow to another telco's PRI ?
  30951. Date: 25 Mar 1999 09:19:42 -0700 (MST)
  30952.  
  30953. d baud said once upon a time:
  30954. >
  30955. >I am currently trying to switch to another PRI provider, and to do a
  30956. >gradual move of all my PRIs I would need to have my old PRIs to overflow
  30957. >(when busy) to some other PRIs in another Central Office (in the same
  30958. >area code).
  30959. >The two telcos say that it is technically impossible to program this
  30960. >feature on the DMS since it is not in the same Central Office.  Could
  30961. >someone confirm if this is true ?
  30962.  
  30963. They could forward from the last number in your pool, but realize that
  30964. standard forwarding can only do about 100 calls at one time.  So this has
  30965. its limits.
  30966.  
  30967. -
  30968.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  30969.  with "unsubscribe usr-tc" in the body of the message.
  30970.  For information on digests or retrieving files and old messages send
  30971.  "help" to the same address.  Do not use quotes in your message.
  30972.  
  30973.  
  30974. -------------------------------------------------------------------------------
  30975.  
  30976. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  30977. Subject: RE: (usr-tc) Assistance Needed Help!!!!
  30978. Date: 25 Mar 1999 10:53:57 -0600
  30979.  
  30980.  
  30981.  
  30982. |-----Original Message-----
  30983. |From: owner-usr-tc@lists.xmission.com
  30984. |[mailto:owner-usr-tc@lists.xmission.com]On Behalf Of
  30985. |vanhalen@coredcs.com
  30986. |Sent: Wednesday, March 24, 1999 6:51 PM
  30987. |To: usr-tc@lists.xmission.com
  30988. |Subject: Re: (usr-tc) Assistance Needed Help!!!!
  30989. |
  30990. |
  30991. |Thanks for the reply.  The problem is that I set it up originally with the
  30992. |xxx.xxx.47.240 range and all I did was change the start address of the ip
  30993. |within the 47 network.  It worked perfectly fine with the 47.240 range but
  30994. |when moved to 47.225 it puked.
  30995. |
  30996. |The other interesting thing related to this is that the customers who have
  30997. |a static ip assigned to them are 100% fine and operational.  That ip is in
  30998. |the xxx.xxx.45.xxx range.
  30999. |
  31000. |The problem seems _only_ to be with the ip address pool and assignments
  31001. |from the pool.
  31002. |
  31003.  
  31004. Was the .47.225 range used by some other device previously? If so, you may want
  31005. to check your routers ARP cache and
  31006. see what MAC address it is using in conjunction with those IP's. Clearing the ARP
  31007. cache will resolve the problem in that case. I think the Cisco will clear after 4
  31008. hours but some other vendors like Bay default to infinity.
  31009.  
  31010. -M
  31011.  
  31012.  
  31013. -
  31014.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31015.  with "unsubscribe usr-tc" in the body of the message.
  31016.  For information on digests or retrieving files and old messages send
  31017.  "help" to the same address.  Do not use quotes in your message.
  31018.  
  31019.  
  31020. -------------------------------------------------------------------------------
  31021.  
  31022. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  31023. Subject: RE: (usr-tc) Assigning Different domain different IP blocks
  31024. Date: 25 Mar 1999 10:53:56 -0600
  31025.  
  31026.  
  31027. |
  31028. |Hi, last night I posted a question asking about different RADIUS servers
  31029. |that support realms.  Thanks for all your replies.  My next question is
  31030. |how can I use the RADIUS server to assign different IP addresses.  For
  31031. |example, we have two ISPs sharing one TC.  When a user logs in, his/her
  31032. |username will be in the format user@domain-1.com or user@domain-2.com.
  31033. |I have decided to use the Cistron RADIUS server because it is free,
  31034. |powerful, and now supports realms.  Now what I need to do is assign the
  31035. |default user an address from a different pool.  For example,
  31036. |domain-1.com will be using 192.168.1.0/24 and domain-2.com will be using
  31037. |192.168.2.0/24.  How do I configure this in the TC?  How do I configure
  31038. |this in RADIUS?  Is there anything else that I need to know before I go
  31039. |about doing this?
  31040. |
  31041.  
  31042. On the HARC you need to create a "PRIVATE" pool for each isp.
  31043.  
  31044. In the radius access-accept packet you indicate which pool you want the HARC to
  31045. assign from by including
  31046. the pool name in the VSA attribte "Framed-Pool-Name" (0x9024). The RADIUS must
  31047. support 3com style VSA's.
  31048.  
  31049. -M
  31050.  
  31051.  
  31052. -
  31053.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31054.  with "unsubscribe usr-tc" in the body of the message.
  31055.  For information on digests or retrieving files and old messages send
  31056.  "help" to the same address.  Do not use quotes in your message.
  31057.  
  31058.  
  31059. -------------------------------------------------------------------------------
  31060.  
  31061. From: <vanhalen@coredcs.com>
  31062. Subject: RE: (usr-tc) Assistance Needed Help!!!!
  31063. Date: 25 Mar 1999 11:07:17 -0600 (CST)
  31064.  
  31065. > 
  31066. > Was the .47.225 range used by some other device previously? If so, you may want
  31067. > to check your routers ARP cache and
  31068. > see what MAC address it is using in conjunction with those IP's. Clearing the ARP
  31069. > cache will resolve the problem in that case. I think the Cisco will clear after 4
  31070. > hours but some other vendors like Bay default to infinity.
  31071. > 
  31072.  
  31073. Hello-
  31074.  
  31075. Thanks for the note.  The 47.225 range wasn't used before.  We also
  31076. cleared the ARP cache just in case and for fun.  The ARP cache shows the
  31077. ip's and the correct mac address(the mac address of the net0 interface).
  31078. The traceroutes still show that the packets are reaching the netserver box
  31079. fine but then they don't know where to go after that or at least they
  31080. don't receive a reply back from the ip that we're pinging.
  31081.  
  31082. In reproducing the problem here when I ping off of the isdn box to one of
  31083. the 'dead links' I can see the ping make it to the machine I'm pinging. In
  31084. other words in 95 and NT there's that little picture of two computers near
  31085. the clock in the taskbar.  I can see it blink and the counters increase
  31086. when I ping it from somewhere on the network to that ip, but the ping
  31087. never gets answered by the modem/machine I'm dialed in with.
  31088.  
  31089. Steve
  31090.  
  31091.  
  31092. -
  31093.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31094.  with "unsubscribe usr-tc" in the body of the message.
  31095.  For information on digests or retrieving files and old messages send
  31096.  "help" to the same address.  Do not use quotes in your message.
  31097.  
  31098.  
  31099. -------------------------------------------------------------------------------
  31100.  
  31101. From: "Mike Wronski" <mike@coredump.ae.usr.com>
  31102. Subject: RE: (usr-tc) Assistance Needed Help!!!!
  31103. Date: 25 Mar 1999 11:45:16 -0600
  31104.  
  31105. |>
  31106. |> Was the .47.225 range used by some other device previously? If so,
  31107. |you may want
  31108. |> to check your routers ARP cache and
  31109. |> see what MAC address it is using in conjunction with those IP's.
  31110. |Clearing the ARP
  31111. |> cache will resolve the problem in that case. I think the Cisco will
  31112. |clear after 4
  31113. |> hours but some other vendors like Bay default to infinity.
  31114. |>
  31115. |
  31116. |Hello-
  31117. |
  31118. |Thanks for the note.  The 47.225 range wasn't used before.  We also
  31119. |cleared the ARP cache just in case and for fun.  The ARP cache shows the
  31120. |ip's and the correct mac address(the mac address of the net0 interface).
  31121. |The traceroutes still show that the packets are reaching the netserver box
  31122. |fine but then they don't know where to go after that or at least they
  31123. |don't receive a reply back from the ip that we're pinging.
  31124. |
  31125. |In reproducing the problem here when I ping off of the isdn box to one of
  31126. |the 'dead links' I can see the ping make it to the machine I'm pinging. In
  31127. |other words in 95 and NT there's that little picture of two computers near
  31128. |the clock in the taskbar.  I can see it blink and the counters increase
  31129. |when I ping it from somewhere on the network to that ip, but the ping
  31130. |never gets answered by the modem/machine I'm dialed in with.
  31131. |
  31132.  
  31133. What network is the NAS on? Is it 47.x or something else? If its something else
  31134. make sure that proxy arp is turned on.  Also, do you use RIP or static routes? If
  31135. static make sure that the next hop router knows where to send the replys to..
  31136.  
  31137. Can you ping the dial clients from the NAS? And vice-versa?
  31138.  
  31139. -M
  31140.  
  31141.  
  31142. -
  31143.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31144.  with "unsubscribe usr-tc" in the body of the message.
  31145.  For information on digests or retrieving files and old messages send
  31146.  "help" to the same address.  Do not use quotes in your message.
  31147.  
  31148.  
  31149. -------------------------------------------------------------------------------
  31150.  
  31151. From: ISPCnsl001@aol.com
  31152. Subject: Re: (usr-tc) Call Failure Logging
  31153. Date: 25 Mar 1999 12:47:56 EST
  31154.  
  31155. >  Has anyone bothered counting the number of call failures on the
  31156. >  DSP's?  I have included a script below which parses through our
  31157. >  SNMP trap logs and generates a simple report on the number of call
  31158. >  failures ordered by modem.  The values get reset every midnight.
  31159. >  
  31160. >  Here is a sample of what you get.  Note that this report was generated
  31161. >  mid afternoon.  I've confident that the top 7 modems have not
  31162. >  had a successful call today.
  31163.  
  31164. What are your reason's for call failure?  
  31165. I'm not sure how your call routing is set up on your DMS 100 or how you have
  31166. it set up on the DSP's but I'll bet the guard time you have specified on your
  31167. DMS 100 is default; which is 70ms I believe.  This has been discussed on the
  31168. list before but I would try changing it to 250ms.  This will give the modems
  31169. more time to reset and make themselves available to take a call after the last
  31170. call disconnects.  You can change this setting on the fly and since you are
  31171. the telco you will be able to do it in a minute.  If this doesn't solve your
  31172. trouble then please give details on the reasons for call failure as reported
  31173. by the modems
  31174.  
  31175. Brian
  31176.  
  31177. >  
  31178. >  Report generated: Fri Mar 19 15:00:01 EST 1999
  31179. >  
  31180. >  Fails   NMC             Slot    Modem
  31181. >  
  31182. >       45 10.1.1.102      8       24
  31183. >       45 10.1.1.102      8       23
  31184. >       26 10.1.4.105      3       16
  31185. >       26 10.1.4.105      3       15
  31186. >       23 10.1.4.105      14      15
  31187. >       22 10.1.4.105      3       6
  31188. >       21 10.1.4.105      3       5
  31189. >       18 10.1.5.11       15      6
  31190. >       18 10.1.5.11       15      5
  31191. >  (NOTE: The above are all DSP's)
  31192. >        7 10.1.5.11       6       3
  31193. >        7 10.1.5.11       15      8
  31194. >        5 10.1.5.11       4       1
  31195. >  
  31196. >  Notice the trend of sequential pairs of modems with nearly the same
  31197. >  call failure rate?  As a witness to many of these reports, I can tell
  31198. >  you this is not even close to a rare occurrence.  And forget all the
  31199. >  BS about the 'telco'... at the 10.1.4.* site, _we_are_ the telco.
  31200. >  (The chassis' are barely 10 feet from the DMS100).
  31201. >  
  31202. >  Since this report was generated rather early in the day, the values are
  31203. >  actually low.  By the end of the day, most of our pool is full, so these
  31204. >  bad modems are the only ones attempting to take calls.  I'll probably have
  31205. >  over 300 failures per bad modem by the end of the day.  ("good" modems
  31206. >  only have around 10-12 failures max. per day).
  31207. >  
  31208. >  The only solution I've come up with to fix this is to reboot the DSP.
  31209. >  (Since this is not a desirable solution, I end up busying out the
  31210. >  associated DS0's and waiting until our _weekly_ chassis reboot).  Tried
  31211. >  resetting and dis/enabling the modems from the TCM, and soft-resetting the
  31212. >  modems.  Doesn't do a darn thing.  (BTW: Our code versions are ARC 4.1.72
  31213. >  and DSP 1.2.60, because I still don't trust the .59 codes... I mean, come
  31214. >  on... a bug fix for a bug fix???)
  31215. >  
  31216. >  
  31217. >  Here's how to set up this report:
  31218. >  
  31219. >  On a Unix machine, set up the UCD-SNMP tools (snmptrapd in particular).
  31220. >      (by default, it will syslog traps to LOG_LOCAL0, which you
  31221. >      direct to /var/log/snmptraps).
  31222. >  Place the MIB files from the mib directory under TCM into the directory
  31223. >      /usr/local/share/snmp/mibs on the UCD-SNMP machine.
  31224. >  Configure all of your modems to SNMP trap Incoming Call Failures to
  31225. >      this machine.  (I actually trap all sorts of stuff).  This
  31226. >      works with DSP's and Quadmodems.
  31227. >  Install the following scripts into /usr/local/bin.
  31228. >  Add a cron job to run 'publish_badmodems' every half hour.
  31229. >  Let the chaos unfold.
  31230. >  
  31231. >  I don't claim that this will for for everyone.  I do know it works
  31232. >  for me.
  31233. >  
  31234. >  --- publish_badmodems ---
  31235. >  #!/bin/sh
  31236. >  
  31237. >  exec 1>/path/to/publish/to/badmodems.html
  31238. >  
  31239. >  echo "<head></head>"
  31240. >  echo "
  31241. > Report generated: `date`<hr>"
  31242. >  
  31243. >  echo -e "Fails\tNMC\t\tSlot\tModem
  31244. > <hr>"
  31245. >  nice /usr/local/bin/parsefails
  31246. >  
  31247. >  echo ""
  31248. >  
  31249. >  --- parsefails ---
  31250. >  #!/bin/sh
  31251. >  
  31252. >  if [ -f "$1" ]; then
  31253. >          INFILE="$1"
  31254. >  else
  31255. >          INFILE=/var/log/snmptraps
  31256. >  fi
  31257. >  
  31258. >  egrep -i 'inconnectAttemptFailure|ctConnectAttemptFailure' $INFILE \
  31259. >          | awk -f /usr/local/sbin/parsefails.awk \
  31260. >          | sort -n | uniq -c | sort -nr
  31261. >  
  31262. >  --- parsefails.awk ---
  31263. >  /Uptime: [0-9]* days?,/ { gsub("Uptime: [0-9]* days?,","Uptime: ") }
  31264. >  
  31265. >  { gsub("[,:]","") }
  31266. >  
  31267. >  /Trap \(inconnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }
  31268. >  /Trap \(ctConnectAttemptFailure\)/ { print $6"\t"$24"\t"$27 }
  31269.  
  31270. -
  31271.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31272.  with "unsubscribe usr-tc" in the body of the message.
  31273.  For information on digests or retrieving files and old messages send
  31274.  "help" to the same address.  Do not use quotes in your message.
  31275.  
  31276.  
  31277. -------------------------------------------------------------------------------
  31278.  
  31279. From: "T.J. Weber" <tjw-pop@ipmedia.net>
  31280. Subject: Re: (usr-tc) Assigning Different domain different IP blocks
  31281. Date: 25 Mar 1999 12:51:52 -0600
  31282.  
  31283. Mike Wronski wrote:
  31284. > On the HARC you need to create a "PRIVATE" pool for each isp.
  31285. > 
  31286. > In the radius access-accept packet you indicate which pool you want the HARC to
  31287. > assign from by including
  31288. > the pool name in the VSA attribte "Framed-Pool-Name" (0x9024). The RADIUS must
  31289. > support 3com style VSA's.
  31290. > 
  31291.  
  31292. Thanks for your reply.  How do I know if the Cistron RADIUS server
  31293. supports 3com style VSA's?  If it doesn't support it, what would be my
  31294. next step?
  31295.  
  31296. Thanks,
  31297. --t.j.
  31298.  
  31299. --
  31300. T.J. Weber                      | James: "I hear that if you play the
  31301. Interplanetary Media            |         NT 4.0 CD backwards, you
  31302. phone:             847.205.5200 |         get a Satanic message!"
  31303. fax:               847.205.5201 | Marc:  "That's nothing. If you
  31304. e-mail:         tjw@ipmedia.net |         play it forward, it installs
  31305. web:     http://www.ipmedia.net |         NT 4.0!"
  31306.       He's not dead, he's       /  You have the right to remain 
  31307.   electroencephalographically  /  silent.  Anything you say will
  31308.           challenged.         /  be misquoted and used against you.
  31309.  
  31310. -
  31311.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31312.  with "unsubscribe usr-tc" in the body of the message.
  31313.  For information on digests or retrieving files and old messages send
  31314.  "help" to the same address.  Do not use quotes in your message.
  31315.  
  31316.  
  31317. -------------------------------------------------------------------------------
  31318.  
  31319. From: <vanhalen@coredcs.com>
  31320. Subject: RE: (usr-tc) Assistance Needed Help!!!!
  31321. Date: 25 Mar 1999 13:58:29 -0600 (CST)
  31322.  
  31323. On Thu, 25 Mar 1999, Mike Wronski wrote:
  31324. > What network is the NAS on? Is it 47.x or something else? If its something else
  31325. > make sure that proxy arp is turned on.  Also, do you use RIP or static routes? If
  31326. > static make sure that the next hop router knows where to send the replys to..
  31327. > 
  31328. > Can you ping the dial clients from the NAS? And vice-versa?
  31329. > 
  31330. > -M
  31331. > 
  31332.  
  31333. I'm getting really confused by this whole thing now.  Proxy arp is on and
  31334. we use rip.  
  31335.  
  31336. Here's more info yet again:
  31337. WinNT 4 with LCP Extensions and Software Compression on connecting via an
  31338. analog USR Sportster I cannot ping the NAS nor can the NAS ping back.
  31339. However I can see the activity light on NT blink for each ping.  It never
  31340. sends an acknowledgement back though.  Turn off LCP and software
  31341. compression and it works fine everytime  - can ping both ways.  I followed
  31342. the thread about disabling the LCP extensions but I thought it was only
  31343. for HiperArc/DSP that the problem showed up.  This box is a Netserver with
  31344. Quads.
  31345.  
  31346. A customer with a Cisco 704 ISDN router.  I cannot ping them from the NAS
  31347. but they can move around on the Internet 100% fine and speeds are
  31348. according to them "incredibly fast."  Is this maybe dropping ICMP
  31349. requests?
  31350.  
  31351. So far I have noticed no consistent pattern for why I cannot ping some
  31352. customers and ping others.  I don't know the hardware for all customers
  31353. either which would obviosuly help immensely.  
  31354.  
  31355. Right now the box has an ip address pool in the 70.x range and some
  31356. customers are working fine on it when they get assigned out of that pool.
  31357.  
  31358. I just have found no consistent pattern on this problem so I now I'm even
  31359. doubting whether it's a NAS problem or just a few client problems.  Why
  31360. they are suddenly showing up within the last 22 hours is beyond me and
  31361. it's the reason that I've been hammering away at it for that long. 
  31362.  
  31363. Thanks for the continued assistance and any other suggestions you might
  31364. have.
  31365.  
  31366. Steve
  31367.  
  31368.  
  31369. -
  31370.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31371.  with "unsubscribe usr-tc" in the body of the message.
  31372.  For information on digests or retrieving files and old messages send
  31373.  "help" to the same address.  Do not use quotes in your message.
  31374.  
  31375.  
  31376. -------------------------------------------------------------------------------
  31377.  
  31378. From: Steve Johnson <linuxnut@sonic.net>
  31379. Subject: (usr-tc) D Channel Busy
  31380. Date: 25 Mar 1999 12:33:30 -0800
  31381.  
  31382.  
  31383. I have a TC Network hub, with a HyperArc, and 2 Hyper DSP cards installed. 
  31384. Plugged in my 2 new PRI's and the phone company is getting remote busy on D
  31385. channel.  Is there a setting that I am over looking for this?  How can I
  31386. unbusy the D channel,  the phone co. is saying it is my cards causing the
  31387. remote busy on D channel.  Anyone have any clues?
  31388.  
  31389. -Steve
  31390.  
  31391.  
  31392. -- 
  31393.  ----------------------------------------------------------------------------
  31394.  Steve Johnson                                     Sonic Sys Admin          
  31395.  (707)522-1001 (33.6kbps)                          (707)522-1000 (Voice)    
  31396.  e-mail linuxnut at sonic.net                       http://www.sonic.net     
  31397.  ----------------------------------------------------------------------------
  31398.    "Knowing others is wisdom, knowing your self is Enlightenment."
  31399.                                                    -- Lao-Tzu
  31400.  
  31401. -
  31402.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31403.  with "unsubscribe usr-tc" in the body of the message.
  31404.  For information on digests or retrieving files and old messages send
  31405.  "help" to the same address.  Do not use quotes in your message.
  31406.  
  31407.  
  31408. -------------------------------------------------------------------------------
  31409.  
  31410. From: Pete Ashdown <pashdown@xmission.com>
  31411. Subject: Re: (usr-tc) D Channel Busy
  31412. Date: 25 Mar 1999 13:51:32 -0700 (MST)
  31413.  
  31414. Steve Johnson said once upon a time:
  31415. >
  31416. >
  31417. >I have a TC Network hub, with a HyperArc, and 2 Hyper DSP cards installed. 
  31418. >Plugged in my 2 new PRI's and the phone company is getting remote busy on D
  31419. >channel.  Is there a setting that I am over looking for this?  How can I
  31420. >unbusy the D channel,  the phone co. is saying it is my cards causing the
  31421. >remote busy on D channel.  Anyone have any clues?
  31422.  
  31423. Make sure your switch type matches what the telco is using.  Make sure your
  31424. cards are configured for "messageOriented" rather than "robbed bit".
  31425.  
  31426.  
  31427. -
  31428.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31429.  with "unsubscribe usr-tc" in the body of the message.
  31430.  For information on digests or retrieving files and old messages send
  31431.  "help" to the same address.  Do not use quotes in your message.
  31432.  
  31433.  
  31434. -------------------------------------------------------------------------------
  31435.  
  31436. From: ISPCnsl001@aol.com
  31437. Subject: Re: (usr-tc) D Channel Busy
  31438. Date: 25 Mar 1999 15:50:47 EST
  31439.  
  31440. In a message dated 3/25/99 3:40:49 PM US Eastern Standard Time,
  31441. linuxnut@sonic.net writes:
  31442.  
  31443. > I have a TC Network hub, with a HyperArc, and 2 Hyper DSP cards installed. 
  31444. >  Plugged in my 2 new PRI's and the phone company is getting remote busy on D
  31445. >  channel.  Is there a setting that I am over looking for this?  How can I
  31446. >  unbusy the D channel,  the phone co. is saying it is my cards causing the
  31447. >  remote busy on D channel.  Anyone have any clues?
  31448. >  
  31449.  
  31450. How have they set up the Pri's?  They didn't set them up from NFAS did they?  
  31451. >  -Steve
  31452.  
  31453. -
  31454.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31455.  with "unsubscribe usr-tc" in the body of the message.
  31456.  For information on digests or retrieving files and old messages send
  31457.  "help" to the same address.  Do not use quotes in your message.
  31458.  
  31459.  
  31460. -------------------------------------------------------------------------------
  31461.  
  31462. From: mark@vielle.datasys.net (Mark R. Lindsey)
  31463. Subject: (usr-tc) TX/RX monitor jacks
  31464. Date: 25 Mar 1999 16:02:21 -0500
  31465.  
  31466. On a dual cht1/PRI card, does the RX monitor have the signal received
  31467. by the NIC from the CO?
  31468.  
  31469. Thanks.
  31470.  
  31471.  
  31472. -
  31473.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31474.  with "unsubscribe usr-tc" in the body of the message.
  31475.  For information on digests or retrieving files and old messages send
  31476.  "help" to the same address.  Do not use quotes in your message.
  31477.  
  31478.  
  31479. -------------------------------------------------------------------------------
  31480.  
  31481. From: "C Thompson" <cthompson@wingnet.net>
  31482. Subject: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  31483. Date: 25 Mar 1999 17:02:24 -0500
  31484.  
  31485. Has anyone gotten 
  31486.  
  31487. 1) Auth-Type = "Reject:you did not pay your bill"
  31488. 2) Reply-Message = "Go away"
  31489.  
  31490. types of messages to work with Total Control chasses?
  31491.  
  31492. I don't see either type of message either in the Win98 dialer -OR- in a 
  31493. standard HyperTerminal dialup window.
  31494.  
  31495. I thought I would at least see the message in the latter.  It just says 
  31496. "Request Denied" at the HyperTerminal screen, and the Win98 dialer 
  31497. keeps popping up the login/password box.
  31498.  
  31499. Any ideas?
  31500.  
  31501.  
  31502.  
  31503. Craig Thompson
  31504. WingNET Internet Services,
  31505. P.O. Box 3000 // Cleveland, TN 37320-3000
  31506. 423-559-LINK (v)  423-559-5444 (f)
  31507. http://www.wingnet.net
  31508.  
  31509. One-seventh of your life is spent on Monday.
  31510.  
  31511.  
  31512. -
  31513.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31514.  with "unsubscribe usr-tc" in the body of the message.
  31515.  For information on digests or retrieving files and old messages send
  31516.  "help" to the same address.  Do not use quotes in your message.
  31517.  
  31518.  
  31519. -------------------------------------------------------------------------------
  31520.  
  31521. From: "Robb Bryn" <rbryn@cape-fear.net>
  31522. Subject: (usr-tc) Corrupted Passwords?
  31523. Date: 25 Mar 1999 17:58:14 -0500
  31524.  
  31525. We recently upgraded our HARC and ever since (maybe coincidentally) we are
  31526. getting allot of strange authentication problems.  We are set to PAP  auth
  31527. all the way around and are receiving allot of corrupted passwords.  10% of
  31528. all logons fail due to a bad password (that was input on the uses side
  31529. correctly).  I've run the test a million times using different modems and
  31530. conditions and none seem to be a specific culprit.  Below is an example of
  31531. the output from our logs.  This only appears to happen on the password and
  31532. not the usernames.  I used to call this line noise but it's too consistent
  31533. to be the case.
  31534.  
  31535. example excerpts from logs:
  31536. teen¥╠Xƒ
  31537. a"ás-
  31538. hafro&
  31539. tim│
  31540.  
  31541. We are at HARC 4.1.59  DSP 1.2.59 and using PRI's for our services.
  31542.  
  31543. Thanks,
  31544. Robb Bryn
  31545.  
  31546.  
  31547. -
  31548.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31549.  with "unsubscribe usr-tc" in the body of the message.
  31550.  For information on digests or retrieving files and old messages send
  31551.  "help" to the same address.  Do not use quotes in your message.
  31552.  
  31553.  
  31554. -------------------------------------------------------------------------------
  31555.  
  31556. From: MegaZone <megazone@megazone.org>
  31557. Subject: Re: (usr-tc) RADIUS Daemons that Support Realms
  31558. Date: 25 Mar 1999 15:24:25 -0800 (PST)
  31559.  
  31560. Once upon a time T.J. Weber shaped the electrons to say...
  31561. >Hi, I'm in seek of if a RADIUS daemon that supports realms.  What I need
  31562. >to be able to do is authenticate users by domain, for example
  31563. >user@my-domain.com and user@reseller-domain.com.  Simple accounting is
  31564. >all that is needed which will send basic information back to the acc't
  31565. >server with the user@domain.  I would like to stay in the low price
  31566. >range (as in free).  I know that Merit AAA supports this, how about the
  31567. >basic Merit server?  Cistron? Any others I should know about?
  31568.  
  31569. Cistron does it - and is free.  It has more features than the basic (free)
  31570. Merit by far.
  31571.  
  31572. The free Lucent 2.1b6 server does it as well - but you need to own a PM.
  31573.  
  31574. After that you get into commercial turf - Radiator, RADIUS ABM, Port
  31575. Authority, RadiusNT, Steel-Belted RADIUS, etc.
  31576.  
  31577. -MZ
  31578. -- 
  31579. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  31580. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  31581. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  31582. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  31583. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  31584.  
  31585. -
  31586.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31587.  with "unsubscribe usr-tc" in the body of the message.
  31588.  For information on digests or retrieving files and old messages send
  31589.  "help" to the same address.  Do not use quotes in your message.
  31590.  
  31591.  
  31592. -------------------------------------------------------------------------------
  31593.  
  31594. From: Pete Ashdown <pashdown@xmission.com>
  31595. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  31596. Date: 25 Mar 1999 16:28:47 -0700 (MST)
  31597.  
  31598. C Thompson said once upon a time:
  31599.  
  31600. >Has anyone gotten 
  31601. >
  31602. >1) Auth-Type = "Reject:you did not pay your bill"
  31603. >2) Reply-Message = "Go away"
  31604. >
  31605. >types of messages to work with Total Control chasses?
  31606.  
  31607. Man that would be cool.  Does Win95/98/NT have the ability to pass messages
  31608. on to the user?
  31609.  
  31610. -
  31611.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31612.  with "unsubscribe usr-tc" in the body of the message.
  31613.  For information on digests or retrieving files and old messages send
  31614.  "help" to the same address.  Do not use quotes in your message.
  31615.  
  31616.  
  31617. -------------------------------------------------------------------------------
  31618.  
  31619. From: MegaZone <megazone@megazone.org>
  31620. Subject: Re: (usr-tc) Buying 1st USR-TC
  31621. Date: 25 Mar 1999 15:52:25 -0800 (PST)
  31622.  
  31623. This is a short history lesson since I couldn't explain the position without
  31624. context.  Feel free to skip.
  31625.  
  31626. Once upon a time Dan Hollis shaped the electrons to say...
  31627. >Any lamer than doing RIPv1 but not RIPv2? I never understood this. How
  31628. >long does it take to do a RIPv2 implementation from a RIPv1 one? A day or
  31629. >two max? Why Livingston blew it off for *years*, in favor of the long
  31630. >development time of a far more complex protocol, Ill never understand.
  31631.  
  31632. When it finally got done it was done in one afternoon, as I recall.
  31633.  
  31634. And no, pointy hairs were not involved - Steve Willens wasn't just the
  31635. founder, CEO and President, he was also Chief Engineer.  Everything fell
  31636. under him.  Frankly, Livingston was a small company with only a few full
  31637. time engineers.  I was the 5th person in the support engineering group -
  31638. and at that time that group was tech support, SQA, Beta, documentation,
  31639. some new product development, product test, etc.  I was the entire email
  31640. support 'group' for quite a while - I created it basically.  I also created
  31641. their first real website and ran that.  It was a fairly small number of 
  31642. people doing an incredible amount of work.  I think the development folks
  31643. were three people, counting Steve.  Then one person, Andy, doing host tools
  31644. and Carl doing RADIUS.  Others - myself, Brian Rice, etc - would contribute
  31645. where we could - debugging, testing, etc.  I did the PCMCIA modem testing
  31646. for the OR-M and developed the first modem table entries for ComOS, etc.
  31647.  
  31648. It was a fun time, but damn busy.  I'd do 48 or 72 shifts frequently. I went
  31649. a bit too far early on and actually collapsed during a meeting from exhaustion
  31650. and illness.  At first there really wasn't demand for RIPv2.  When demand
  31651. for VLSM/CIDR appeared Steve started on it, but it was one of those things
  31652. that just got bumped by more important things again and again.  Not from 
  31653. any desire not to do it, but from the need to do other things first and
  31654. having finite resources.  Livingston was very lean, which I'm sure helped
  31655. them maintain their low prices, and the quality of the people made for good
  31656. products - but it did limit what could be done.  We focused on the core
  31657. product features and producing a solid, reliably product - and that grew
  31658. the business and allowed for steady growth.  I think they had something like
  31659. 33 consecutive profitable quarters and steady growth.
  31660.  
  31661. It was a different world - I'd come over from Xylogics which had something
  31662. like 300 people in the Burlington, MA offices - and had other offices around
  31663. the world.  Livingston had 50-60 people, but had a wider range of products,
  31664. which had a higher performance and more features (in the IP/IPX world - 
  31665. Xylo did have Appletalk, LAT, etc - ick).  It was so much more efficient.
  31666.  
  31667. Growth really took off with the PM-3.  Engineering expanded, along about
  31668. the same time new departments were created and populated - Beta, SQA, Docs,
  31669. Web, etc.  It was in that era that a dedicated routing engineer position
  31670. was established, and hence OSPF and BGP appeared in short order.  Once the
  31671. resources werein place OSPF was basically running in a few weeks, ready
  31672. for release in a couple of months.  With that short a development cycle
  31673. there was no point in releasing RIPv2 right away.
  31674.  
  31675. The philosophy was always not to support things unless there was enough
  31676. demand.  Keep ComOS lean and fast, and don't bloat it unnecessarily.  Since
  31677. OSPF was popular and RIPv2 demand all but completely dried up, it was 
  31678. shelved.  And I was one of those who had been saying we should have RIPv2
  31679. released - I changed my mind based on the success of OSPF in ComOS.
  31680.  
  31681. Other projects died along the way as well.  We had Appletalk running in 
  31682. ComOS for a few years, even Apple was using some PMs, but it was decided
  31683. to shelve AT indefinitely rather than direct engineering resources to
  31684. polishing it and completing it for open shipment.  Obviously it has not 
  31685. appeared in ComOS to this day.  The PowerLink128 ISA ISDN BRI card was
  31686. canceled just before going into production - I still have one in the 
  31687. actual retail box it was to ship in.  I've still not seen an ISDN ISA card
  31688. with performance as high as the PL128.  But the market changed during
  31689. development, which had been prolonged a few times (notably it was about
  31690. to ship when Win95 shipped - and no one wanted something not PnP for Win95),
  31691. competing products had appeared and prices had dropped.  So they decided to
  31692. stick with the server market and leave the low-end user to someone else.
  31693. Such is the business world.
  31694.  
  31695. I think it is great that they pushed OSPF.  Even now I believe RIPv2 is only
  31696. on the PM-4 - it isn't listed in the notes for ComOS 3.9 on the other
  31697. platforms.  I know that this caused a number of sites to switch to OSPF, or 
  31698. to try OSPF when they would have defaulted to RIPv2.  Thereby getting more
  31699. sites to use a better protocol, and reducing the number running RIPv2 -
  31700. which I consider braindead.
  31701.  
  31702. IMHO this is a good thing overall.
  31703.  
  31704. -MZ
  31705. -- 
  31706. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  31707. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  31708. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  31709. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  31710. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  31711.  
  31712. -
  31713.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31714.  with "unsubscribe usr-tc" in the body of the message.
  31715.  For information on digests or retrieving files and old messages send
  31716.  "help" to the same address.  Do not use quotes in your message.
  31717.  
  31718.  
  31719. -------------------------------------------------------------------------------
  31720.  
  31721. From: MegaZone <megazone@megazone.org>
  31722. Subject: Re: (usr-tc) Assigning Different domain different IP blocks
  31723. Date: 25 Mar 1999 15:54:47 -0800 (PST)
  31724.  
  31725. Once upon a time T.J. Weber shaped the electrons to say...
  31726. >Thanks for your reply.  How do I know if the Cistron RADIUS server
  31727. >supports 3com style VSA's?  If it doesn't support it, what would be my
  31728.  
  31729. It does.
  31730.  
  31731. BTW, it says so in the READMEs.
  31732.  
  31733. -MZ
  31734. -- 
  31735. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  31736. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  31737. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  31738. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  31739. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  31740.  
  31741. -
  31742.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31743.  with "unsubscribe usr-tc" in the body of the message.
  31744.  For information on digests or retrieving files and old messages send
  31745.  "help" to the same address.  Do not use quotes in your message.
  31746.  
  31747.  
  31748. -------------------------------------------------------------------------------
  31749.  
  31750. From: Paul Farber <farber@admin.f-tech.net>
  31751. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  31752. Date: 25 Mar 1999 19:02:04 -0500 (EST)
  31753.  
  31754. I doubt it. PAP is just a simple text based authentication method.
  31755.  
  31756. YOu would need some sort of app/web page with CGI to do that.
  31757.  
  31758. Paul D. Farber II
  31759. Farber Technology
  31760. Ph. 570-628-5303
  31761. Fax 570-628-5545
  31762. farber@admin.f-tech.net
  31763.  
  31764. On Thu, 25 Mar 1999, Pete Ashdown wrote:
  31765.  
  31766. > C Thompson said once upon a time:
  31767. > 
  31768. > >Has anyone gotten 
  31769. > >
  31770. > >1) Auth-Type = "Reject:you did not pay your bill"
  31771. > >2) Reply-Message = "Go away"
  31772. > >
  31773. > >types of messages to work with Total Control chasses?
  31774. > 
  31775. > Man that would be cool.  Does Win95/98/NT have the ability to pass messages
  31776. > on to the user?
  31777. > 
  31778. > -
  31779. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31780. >  with "unsubscribe usr-tc" in the body of the message.
  31781. >  For information on digests or retrieving files and old messages send
  31782. >  "help" to the same address.  Do not use quotes in your message.
  31783. > 
  31784.  
  31785.  
  31786. -
  31787.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31788.  with "unsubscribe usr-tc" in the body of the message.
  31789.  For information on digests or retrieving files and old messages send
  31790.  "help" to the same address.  Do not use quotes in your message.
  31791.  
  31792.  
  31793. -------------------------------------------------------------------------------
  31794.  
  31795. From: MegaZone <megazone@megazone.org>
  31796. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  31797. Date: 25 Mar 1999 15:58:25 -0800 (PST)
  31798.  
  31799. Once upon a time Pete Ashdown shaped the electrons to say...
  31800. >C Thompson said once upon a time:
  31801. >>1) Auth-Type = "Reject:you did not pay your bill"
  31802.  
  31803. I don't know what this is supposed to be.  I've never seen a RADIUS server
  31804. that would understand this.
  31805.  
  31806. >>2) Reply-Message = "Go away"
  31807.  
  31808. Now this is allowed by the RFCs to be sent in an Access-Reject.  And the NAS
  31809. should display it ot the user.
  31810.  
  31811. >Man that would be cool.  Does Win95/98/NT have the ability to pass messages
  31812. >on to the user?
  31813.  
  31814. But this is the rub - no, it does not.  In fact, MOST PPP clients WILL NOT
  31815. display the message text displayed by the NAS.  To see this on Windoze you'd
  31816. need to have it set to open the console window after dialing.  Even on a
  31817. NAS that does display the text, a normal user using DUN will never see it.
  31818. Same for the normal MacOS dialer, etc.
  31819.  
  31820. -MZ
  31821. -- 
  31822. -=*X I'm going down...  under that is! <URL:http://www.aussie-isp.net/> X*=-
  31823. <URL:mailto:megazone@megazone.org> Gweep, Discordian, Author, Engineer, me..
  31824. Join ISP/C Internet Service Providers' Consortium <URL:http://www.ispc.org/>
  31825. "A little nonsense now and then, is relished by the wisest men" 781-788-0130
  31826. <URL:http://www.megazone.org/>  <URL:http://www.gweep.net/>  Hail Discordia!
  31827.  
  31828. -
  31829.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31830.  with "unsubscribe usr-tc" in the body of the message.
  31831.  For information on digests or retrieving files and old messages send
  31832.  "help" to the same address.  Do not use quotes in your message.
  31833.  
  31834.  
  31835. -------------------------------------------------------------------------------
  31836.  
  31837. From: Jeff Mcadams <jeffm@iglou.com>
  31838. Subject: Re: (usr-tc) Buying 1st USR-TC
  31839. Date: 25 Mar 1999 19:31:38 -0500 (EST)
  31840.  
  31841. Thus spake MegaZone
  31842. >This is a short history lesson since I couldn't explain the position without
  31843. >context.  Feel free to skip.
  31844.  
  31845. Twas a nice reminder of past times.  :)
  31846.  
  31847. >Others - myself, Brian Rice, etc - 
  31848.  
  31849. Wow, there's a name I haven't heard in a while.  :)
  31850.  
  31851. >At first there really wasn't demand for RIPv2.  When demand for
  31852. >VLSM/CIDR appeared Steve started on it, but it was one of those things
  31853. >that just got bumped by more important things again and again.  
  31854.  
  31855. I remember a lot of things getting bumped because there were more
  31856. important things...and this I don't fault.
  31857.  
  31858. >Once the resources werein place OSPF was basically running in a few
  31859. >weeks, ready for release in a couple of months.  With that short a
  31860. >development cycle there was no point in releasing RIPv2 right away.
  31861.  
  31862. >The philosophy was always not to support things unless there was enough
  31863. >demand.  Keep ComOS lean and fast, and don't bloat it unnecessarily.  Since
  31864. >OSPF was popular and RIPv2 demand all but completely dried up, it was 
  31865. >shelved.  And I was one of those who had been saying we should have RIPv2
  31866. >released - I changed my mind based on the success of OSPF in ComOS.
  31867.  
  31868. Keep in mind we had pretty much quit using Livingston gear for USR gear
  31869. by the time OSPF showed up, so I can't say that I was there for this,
  31870. but I do disagree somewhat with this mindset.  Like it or not, RIPv2 is
  31871. consider the least common denominator of routing protocols, and support
  31872. really *should* be in equipment for it.  That's the specific case...in
  31873. the general case, I wasn't particularly fond of Livingston's complete
  31874. obsession with remaining lean.  Really, that was, in the overall scheme
  31875. of things, what made us quit using Livingston equipment.  I can point to
  31876. several things that specifically were involved, but I won't go into
  31877. them...heck, MZ, you may remember some of my rants (yes, 3Com isn't the
  31878. only target of my rants) on portmaster-users :).  Suffice it to say that
  31879. Livingston's obsession with keeping their gear so lean made it an
  31880. absolute bear to deal with them.  Any time you'd ask for a feature, or
  31881. tech support on a feature that was perhaps not that typical way a
  31882. feature was used, the attitude gotten back was something along the lines
  31883. of "Why are you doing it that way?  That's not how you're supposed to
  31884. use the equipment."  To be fair...I *still* get this attitude in
  31885. response to requests to vendors (most notably, 3Com definitely falls
  31886. into this category :).  I made some feature requests from Livingston,
  31887. and got, quite literally, responses such as "Why on earth would you want
  31888. that?"  As if to say I didn't know what I was talking about, and that
  31889. the person I was talking to knew how to do my job better than I did.
  31890. That really irked me when I got responses like that...and they were
  31891. commonplace at Livingston.
  31892.  
  31893. When I've made feature requests of 3Com, I typically will end up getting
  31894. someone asking me how I'm wanting to use it, but usually its more of an
  31895. effort to be sure they understand how I'm asking to have the feature
  31896. implemented.  For example, when I was working with Buster Joseph to get
  31897. the prompt_delay feature added to the HiPer Arc code, we went through,
  31898. in depth, how our dial-in setup was configured on the NETServers so he
  31899. could be sure he understood how the feature should be implemented on the
  31900. HiPer Arc.  I have no problem with that.  The feature got implemented.
  31901. Several times with Livingston, I was responded to incredulously as
  31902. above, and the feature never got implemented...I can only assume, based
  31903. on the response that I was given, that they considered me a crackpot or
  31904. something for wanting a feature that they didn't immediately understand
  31905. a need for.
  31906.  
  31907. FWIW, one of the features I asked of Livingston was the same type of
  31908. prompt_delay type of thing that I asked for and got implemented in the
  31909. HiPer Arcs.  To my knowledge, ComOS to this day doesn't have anything
  31910. that would work for this.
  31911.  
  31912. >I think it is great that they pushed OSPF.  
  31913.  
  31914. Hey, don't get me wrong, I *love* OSPF, and I've got as much of my
  31915. network running it as possible, and will be thrilled to banish RIPv2 to
  31916. the nether regions on my network once its available on the Arcs, but
  31917. these products really do need to support RIPv2 as the lowest common
  31918. denominator still.
  31919.  
  31920. >Even now I believe RIPv2 is only on the PM-4 - it isn't listed in the
  31921. >notes for ComOS 3.9 on the other platforms.  I know that this caused a
  31922. >number of sites to switch to OSPF, or to try OSPF when they would have
  31923. >defaulted to RIPv2.  
  31924.  
  31925. That's great to get people moved over to OSPF, but I wonder how many
  31926. sites are now having to run RIPv2 and OSPF and redistribute through a
  31927. Cisco router to get their Livingston/Lucent gear talking with other gear
  31928. (perhaps 3Com stuff) that only talks RIPv2.  While its great to get
  31929. people moving over to OSPF, its not yet widespread enough to be the
  31930. lowest common denominator routing protocol on a system.
  31931.  
  31932. >Thereby getting more sites to use a better protocol, and reducing the
  31933. >number running RIPv2 - which I consider braindead.
  31934.  
  31935. Oh, RIPv2 *is* braindead...won't argue you there, but unfortunately, it
  31936. is still the LCD of routing protocols, and not having it in equipment is
  31937. a good way to cut out a significant market.
  31938. -- 
  31939. Jeff McAdams                            Email: jeffm@iglou.com
  31940. Head Network Administrator              Voice: (502) 966-3848
  31941. IgLou Internet Services                        (800) 436-4456
  31942.  
  31943. -
  31944.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31945.  with "unsubscribe usr-tc" in the body of the message.
  31946.  For information on digests or retrieving files and old messages send
  31947.  "help" to the same address.  Do not use quotes in your message.
  31948.  
  31949.  
  31950. -------------------------------------------------------------------------------
  31951.  
  31952. From: ROC Services <rocsoft@itol.com>
  31953. Subject: Re: (usr-tc) Corrupted Passwords?
  31954. Date: 25 Mar 1999 19:55:51 -0600 (CST)
  31955.  
  31956. On Thu, 25 Mar 1999, Robb Bryn wrote:
  31957.  
  31958. > We recently upgraded our HARC and ever since (maybe coincidentally) we are
  31959. > getting allot of strange authentication problems.  We are set to PAP  auth
  31960. > all the way around and are receiving allot of corrupted passwords.  10% of
  31961. > all logons fail due to a bad password (that was input on the uses side
  31962. > correctly).  I've run the test a million times using different modems and
  31963. > conditions and none seem to be a specific culprit.  Below is an example of
  31964. > the output from our logs.  This only appears to happen on the password and
  31965. > not the usernames.  I used to call this line noise but it's too consistent
  31966. > to be the case.
  31967.  
  31968. I'm seeing this as well, along with some other bizarre auth-related
  31969. difficulties, on which I sent a relatively long report yesterday.
  31970.  
  31971. HARC 4.1.59-6, DSP 1.2.59 and 1.2.43
  31972.  
  31973. Are you running 4.1.59-6 of the HARC code as well?  If so, I think I'll
  31974. try reverting to 4.1.72-7 and see what happens..
  31975.  
  31976.  
  31977.  
  31978. -
  31979.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  31980.  with "unsubscribe usr-tc" in the body of the message.
  31981.  For information on digests or retrieving files and old messages send
  31982.  "help" to the same address.  Do not use quotes in your message.
  31983.  
  31984.  
  31985. -------------------------------------------------------------------------------
  31986.  
  31987. From: Andy Berkvam <aberkvam@coredcs.com>
  31988. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  31989. Date: 25 Mar 1999 18:06:43 -0600 (CST)
  31990.  
  31991. On Thu, 25 Mar 1999, MegaZone wrote:
  31992.  
  31993. > But this is the rub - no, it does not.  In fact, MOST PPP clients WILL NOT
  31994. > display the message text displayed by the NAS.  To see this on Windoze you'd
  31995. > need to have it set to open the console window after dialing.  Even on a
  31996. > NAS that does display the text, a normal user using DUN will never see it.
  31997. > Same for the normal MacOS dialer, etc.
  31998. > 
  31999.   The only dialer that I've seen that actually does this is Trumpet
  32000. Winsock.  I remember being very disappointed when Win95 came out.  A
  32001. simple pop-up display of some sort giving the reason why the connection
  32002. was denied would have been a wonderful thing for ISPs.  I don't know why
  32003. they didn't add it.
  32004.  
  32005. Andy
  32006.  
  32007. -- 
  32008. ===========================================================================
  32009. Andy Berkvam          | "Only two things are infinite, the universe 
  32010.                       |  and human stupidity, and I'm not sure about 
  32011. Email:                |  the former."
  32012.  aberkvam@coredcs.com |                                   - Albert Einstein
  32013.  (MIME Attachments OK)|-WWW Pages: <http://www.coredcs.com/~aberkvam/>
  32014. ===========================================================================
  32015.  
  32016.  
  32017. -
  32018.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32019.  with "unsubscribe usr-tc" in the body of the message.
  32020.  For information on digests or retrieving files and old messages send
  32021.  "help" to the same address.  Do not use quotes in your message.
  32022.  
  32023.  
  32024. -------------------------------------------------------------------------------
  32025.  
  32026. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  32027. Subject: Re: (usr-tc) PPP Get Option Rejected (long)
  32028. Date: 25 Mar 1999 20:41:58 -0600 (CST)
  32029.  
  32030. On Wed, 24 Mar 1999, ROC Services wrote:
  32031.  
  32032. > I've got a problem with users fairly frequently getting disconnected
  32033. > immediately after performing PAP, with this message getting syslogged:
  32034. > 
  32035. > Mar 24 16:00:28 gb-hiper At 22:00:28, Facility "Auth Facility", Level
  32036. > "COMMON":: Port slot:4/mod:9 successful RADIUS authentication
  32037. > for user: Pxxxxxxxxx
  32038. > 
  32039. > Mar 24 16:00:28 gb-hiper At 22:00:28, Facility "PPP", Level "UNUSUAL"::
  32040. > ../../src/ppp_main.c: PPP Get Option Rejected, (bad status).
  32041.  
  32042. This is fine - if you have syslog set to critical you will not see this.
  32043. This says just that one of the ppp options was rejected - which is fine.
  32044.  
  32045. > 
  32046. > They can usually get connected on the second try.  There doesn't seem to
  32047. > be a pattern to the slot/mod numbers -- they're more or less random
  32048. > throughout the group.  We've got one where they get this every time, but
  32049. > they're an ISDN customer with what I think may be a misconfigured router.
  32050. > The others are analog dialups.
  32051. > 
  32052. > A 'mon ppp' on one of these connection shows the ARC sending a PAP
  32053. > auth-ack and then nothing after that.  In our RADIUS server's log I can
  32054. > see the auth request and ack, but no accounting records.  Logging of
  32055. > unauthenticated calls isn't enabled on this box.
  32056. > 
  32057. Well if you see the HiPer arc does send a ack for the ppp user for pap. 
  32058. And it does not get anything back from the client.
  32059.  
  32060.  
  32061.  
  32062.  
  32063. > Any info would be appreciated.  If this is an RTFM issue, someone please
  32064. > indicate which FM.  I suspect it's not, though, as this just started
  32065. > happening relatively recently.
  32066. > 
  32067.  
  32068. Try these
  32069.  
  32070. 1. Set up ppp to any default
  32071.  
  32072. set ppp recevi  any 
  32073. set ppp authe pre default
  32074.  
  32075. or 
  32076.  
  32077. disable ppp offloading
  32078.  
  32079. on the hiper arc and see what you get.  I would not recommend disable ppp 
  32080. offloading but if you can try it will give a hint on what is happening.
  32081.  
  32082. krish
  32083.  
  32084. > [versions]
  32085. > HARC 4.1.59-6
  32086. > DSP 1.2.43 and 1.2.59, some on PRI some on channelized.
  32087. > Livingston RADIUS 2.0.1, soon to be Cistron RADIUS.
  32088. > 
  32089. > [relevant config stuff]
  32090. > PPP offloading:                           ENABLED
  32091. > Send Accounting for PPP Abnormal Disc:    DISABLED
  32092. > PPP Address Field Compression:            ENABLED
  32093. > PPP Protocol Field Compression:           ENABLED
  32094. > PPP Multilink PPP:                        ENABLED
  32095. > PPP BACP and BAP:                         DISABLED
  32096. > PPP Bap Hunt Group Phone Number:
  32097. > PPP Receive ACCM:                         DISABLE
  32098. > 
  32099. > [mon PPP]
  32100. > Outgoing PPP Data on interface: slot:4/mod:9
  32101. >     LCP        CFG_REQ           MRU            05 ea
  32102. >                                  ASYNC_MAP      00 00 00 00
  32103. >                                  AUTH_TYPE      c0 23
  32104. >                                  MAGIC_NUM      50 8a b1 9b
  32105. >                                  PROTO_COMP
  32106. >                                  AC_COMP
  32107. >                                  MPP_MRRU       05 ea
  32108. >                                  MPP_ENDPTID    00
  32109. > 
  32110. > Incoming PPP Data on interface: slot:4/mod:9
  32111. >     LCP        CFG_REQ           ASYNC_MAP      00 0a 00 00
  32112. >                                  MAGIC_NUM      00 01 1a 04
  32113. >                                  PROTO_COMP
  32114. >                                  AC_COMP
  32115. >                                  CALLBACK       06
  32116. > 
  32117. > Outgoing PPP Data on interface: slot:4/mod:9
  32118. >     LCP        CFG_REJ           CALLBACK       06
  32119. > 
  32120. > Incoming PPP Data on interface: slot:4/mod:9
  32121. >     LCP        CFG_REJ           MPP_MRRU       05 ea
  32122. >                                  MPP_ENDPTID    00
  32123. > 
  32124. > Outgoing PPP Data on interface: slot:4/mod:9
  32125. >     LCP        CFG_REQ           MRU            05 ea
  32126. >                                  ASYNC_MAP      00 00 00 00
  32127. >                                  AUTH_TYPE      c0 23
  32128. >                                  MAGIC_NUM      50 8a b1 9b
  32129. >                                  PROTO_COMP
  32130. >                                  AC_COMP
  32131. > 
  32132. > Incoming PPP Data on interface: slot:4/mod:9
  32133. >     LCP        CFG_REQ           ASYNC_MAP      00 0a 00 00
  32134. >                                  MAGIC_NUM      00 01 1a 04
  32135. >                                  PROTO_COMP
  32136. >                                  AC_COMP
  32137. > 
  32138. > Outgoing PPP Data on interface: slot:4/mod:9
  32139. >     LCP        CFG_ACK           ASYNC_MAP      00 0a 00 00
  32140. >                                  MAGIC_NUM      00 01 1a 04
  32141. >                                  PROTO_COMP
  32142. >                                  AC_COMP
  32143. > 
  32144. > Incoming PPP Data on interface: slot:4/mod:9
  32145. >     LCP        CFG_ACK           MRU            05 ea
  32146. >                                  ASYNC_MAP      00 00 00 00
  32147. >                                  AUTH_TYPE      c0 23
  32148. >                                  MAGIC_NUM      50 8a b1 9b
  32149. >                                  PROTO_COMP
  32150. >                                  AC_COMP
  32151. > 
  32152. > Incoming PPP Data on interface: slot:4/mod:9
  32153. >     PAP        REQUEST           USERNAME = Pxxxxxxxx
  32154. >                                  PASSWORD = yyyyyyyyy
  32155. > Outgoing PPP Data on interface: slot:4/mod:9
  32156. >     PAP        ACK               ....Tracing the current/next session;
  32157. > Escape to stop...
  32158. > Tracing stopped, Return/Enter to re-start, ESCAPE to quit.
  32159. > 
  32160. > 
  32161. > 
  32162. > -
  32163. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32164. >  with "unsubscribe usr-tc" in the body of the message.
  32165. >  For information on digests or retrieving files and old messages send
  32166. >  "help" to the same address.  Do not use quotes in your message.
  32167. > 
  32168.  
  32169. -
  32170.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32171.  with "unsubscribe usr-tc" in the body of the message.
  32172.  For information on digests or retrieving files and old messages send
  32173.  "help" to the same address.  Do not use quotes in your message.
  32174.  
  32175.  
  32176. -------------------------------------------------------------------------------
  32177.  
  32178. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  32179. Subject: Re: (usr-tc) Corrupted Passwords?
  32180. Date: 25 Mar 1999 20:47:16 -0600 (CST)
  32181.  
  32182. On Thu, 25 Mar 1999, Robb Bryn wrote:
  32183.  
  32184. > We recently upgraded our HARC and ever since (maybe coincidentally) we ar=
  32185. e
  32186. > getting allot of strange authentication problems.  We are set to PAP  aut=
  32187. h
  32188. > all the way around and are receiving allot of corrupted passwords.  10% o=
  32189. f
  32190. > all logons fail due to a bad password (that was input on the uses side
  32191. > correctly).  I've run the test a million times using different modems and
  32192. > conditions and none seem to be a specific culprit.  Below is an example o=
  32193. f
  32194. > the output from our logs.  This only appears to happen on the password an=
  32195. d
  32196. > not the usernames.  I used to call this line noise but it's too consisten=
  32197. t
  32198. > to be the case.
  32199.  
  32200. The NAS (Hiper ARc) uses the secret to encrypt the password.  Make sure=20
  32201. that you can really decode the password.  What you are seeing here could=20
  32202. be the hashed password.  Do you really see this when you do a mon ppp on=20
  32203. the hiper arc and also are you using pap when this is done?
  32204.  
  32205. krish
  32206.  
  32207. Ps:  You can download the radius debugger code from Mike Wronski's site=20
  32208. ftp://coredump.ae.usr.com/raddebug
  32209.  
  32210. and get a snoop/tcpdump to see what is exactly happening?  If pap then=20
  32211. you can decode the password using this tool.
  32212.  
  32213.  
  32214.  
  32215. >=20
  32216. > example excerpts from logs:
  32217. > teen=15=9D=CCX=04=9F
  32218. > a"=A0s-
  32219. > hafro&
  32220. > tim=B3
  32221. >=20
  32222. > We are at HARC 4.1.59  DSP 1.2.59 and using PRI's for our services.
  32223. >=20
  32224. > Thanks,
  32225. > Robb Bryn
  32226. >=20
  32227. >=20
  32228. > -
  32229. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32230. >  with "unsubscribe usr-tc" in the body of the message.
  32231. >  For information on digests or retrieving files and old messages send
  32232. >  "help" to the same address.  Do not use quotes in your message.
  32233. >=20
  32234.  
  32235. -
  32236.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32237.  with "unsubscribe usr-tc" in the body of the message.
  32238.  For information on digests or retrieving files and old messages send
  32239.  "help" to the same address.  Do not use quotes in your message.
  32240.  
  32241.  
  32242. -------------------------------------------------------------------------------
  32243.  
  32244. From: ROC Services <rocsoft@itol.com>
  32245. Subject: Re: (usr-tc) Corrupted Passwords?
  32246. Date: 25 Mar 1999 20:38:53 -0600 (CST)
  32247.  
  32248. On Thu, 25 Mar 1999, Tatai SV Krishnan wrote:
  32249.  
  32250. > The NAS (Hiper ARc) uses the secret to encrypt the password.  Make sure 
  32251. > that you can really decode the password.  What you are seeing here could 
  32252. > be the hashed password.  Do you really see this when you do a mon ppp on 
  32253. > the hiper arc and also are you using pap when this is done?
  32254.  
  32255. Pardon my jumping in on this one, but I see it in a mon ppp, and I also
  32256. have a version of radius that I use for testing that syslogs the attempted
  32257. password if it fails (after decryption of course) and it comes through
  32258. garbled there as well...
  32259.  
  32260.  
  32261.  
  32262. -
  32263.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32264.  with "unsubscribe usr-tc" in the body of the message.
  32265.  For information on digests or retrieving files and old messages send
  32266.  "help" to the same address.  Do not use quotes in your message.
  32267.  
  32268.  
  32269. -------------------------------------------------------------------------------
  32270.  
  32271. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  32272. Subject: Re: (usr-tc) Corrupted Passwords?
  32273. Date: 25 Mar 1999 21:02:03 -0600 (CST)
  32274.  
  32275. On Thu, 25 Mar 1999, ROC Services wrote:
  32276.  
  32277. > On Thu, 25 Mar 1999, Tatai SV Krishnan wrote:
  32278. > 
  32279. > > The NAS (Hiper ARc) uses the secret to encrypt the password.  Make sure 
  32280. > > that you can really decode the password.  What you are seeing here could 
  32281. > > be the hashed password.  Do you really see this when you do a mon ppp on 
  32282. > > the hiper arc and also are you using pap when this is done?
  32283. > 
  32284. > Pardon my jumping in on this one, but I see it in a mon ppp, and I also
  32285. > have a version of radius that I use for testing that syslogs the attempted
  32286. > password if it fails (after decryption of course) and it comes through
  32287. > garbled there as well...
  32288. > 
  32289.  
  32290. Ok - So if you can reproduce it let me know.  I can work with you on your 
  32291. chassis to see what is happening.  Would need access to your hiper arc.
  32292.  
  32293. krish
  32294.  
  32295. > 
  32296.  
  32297. -
  32298.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32299.  with "unsubscribe usr-tc" in the body of the message.
  32300.  For information on digests or retrieving files and old messages send
  32301.  "help" to the same address.  Do not use quotes in your message.
  32302.  
  32303.  
  32304. -------------------------------------------------------------------------------
  32305.  
  32306. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  32307. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  32308. Date: 25 Mar 1999 21:08:23 -0600 (CST)
  32309.  
  32310. On Thu, 25 Mar 1999, Pete Ashdown wrote:
  32311.  
  32312. > C Thompson said once upon a time:
  32313. > 
  32314. > >Has anyone gotten 
  32315. > >
  32316. > >1) Auth-Type = "Reject:you did not pay your bill"
  32317. > >2) Reply-Message = "Go away"
  32318. > >
  32319. > >types of messages to work with Total Control chasses?
  32320.  
  32321. > Man that would be cool.  Does Win95/98/NT have the ability to pass messages
  32322. > on to the user?
  32323. > 
  32324.  
  32325. NT windows do not support this - but here is what you can do, you can do 
  32326. on the radius.  I have seen a setup where when the user does not pay the 
  32327. bill, a script on the server check this and then changes the user to a 
  32328. tunnel user.  Now when the user dials back he gets to a separate network, 
  32329. then when the user brings up say netscape of IE - regardless of what ever 
  32330. site he/she wishes to go, the bill payment webpage is displayed.
  32331.  
  32332. This does require some changes in DNS server and in setup and was done 
  32333. using Hiper arcs.  Very cool
  32334.  
  32335. krish
  32336.  
  32337. > -
  32338. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32339. >  with "unsubscribe usr-tc" in the body of the message.
  32340. >  For information on digests or retrieving files and old messages send
  32341. >  "help" to the same address.  Do not use quotes in your message.
  32342. > 
  32343.  
  32344. -
  32345.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32346.  with "unsubscribe usr-tc" in the body of the message.
  32347.  For information on digests or retrieving files and old messages send
  32348.  "help" to the same address.  Do not use quotes in your message.
  32349.  
  32350.  
  32351. -------------------------------------------------------------------------------
  32352.  
  32353. From: David Bolen <db3l@ans.net>
  32354. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  32355. Date: 25 Mar 1999 22:55:12 EST
  32356.  
  32357. Paul Farber <farber@admin.f-tech.net> writes:
  32358.  
  32359. > I doubt it. PAP is just a simple text based authentication method.
  32360.  
  32361. Yes, but the Authenticate-Ack and Authenticate-Nak packets of PAP both
  32362. include room for an optional text message.  If I recall correctly (it
  32363. was quite a while back I checked), I do think that the NETServer
  32364. stuffed the value in a Reply-Message RADIUS attribute into the packet
  32365. - not sure about the ARC.
  32366.  
  32367. However, in my experience, Windows never makes use of that
  32368. information.
  32369.  
  32370. -- David
  32371.  
  32372. /-----------------------------------------------------------------------\
  32373.  \               David Bolen              \  Internet: db3l@ans.net    /
  32374.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  32375.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  32376. \-----------------------------------------------------------------------/
  32377.  
  32378. -
  32379.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32380.  with "unsubscribe usr-tc" in the body of the message.
  32381.  For information on digests or retrieving files and old messages send
  32382.  "help" to the same address.  Do not use quotes in your message.
  32383.  
  32384.  
  32385. -------------------------------------------------------------------------------
  32386.  
  32387. From: David Bolen <db3l@ans.net>
  32388. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  32389. Date: 25 Mar 1999 22:59:48 EST
  32390.  
  32391. Andy Berkvam <aberkvam@coredcs.com> writes:
  32392.  
  32393. >   The only dialer that I've seen that actually does this is Trumpet
  32394. > Winsock.  I remember being very disappointed when Win95 came out.  A
  32395. > simple pop-up display of some sort giving the reason why the connection
  32396. > was denied would have been a wonderful thing for ISPs.  I don't know why
  32397. > they didn't add it.
  32398.  
  32399. I'm not positive, but does Trumpet do PPP with PAP/CHAP or does it use
  32400. a scripted login?
  32401.  
  32402. There's a difference between scripting your way into a session (where
  32403. there is an ASCII prompt/response sequence prior to the start of PPP
  32404. frames) and using PPP with PAP/CHAP, where the only communication is
  32405. PPP frames.  In the former case, you can trap standard output from a
  32406. NAS (which many present after the login attempt) including failure
  32407. messages.  In the latter case, there is no such output since you're
  32408. already in a PPP session that has negotiated LCP and is exchanging
  32409. frames - this is what DUN does.
  32410.  
  32411. Of course, the annoying part is that as I noted in an earlier
  32412. response, PAP does include a facility for including a message within
  32413. the PPP frame that could be extracted if the clients wanted to.
  32414.  
  32415. -- David
  32416.  
  32417. /-----------------------------------------------------------------------\
  32418.  \               David Bolen              \  Internet: db3l@ans.net    /
  32419.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  32420.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  32421. \-----------------------------------------------------------------------/
  32422.  
  32423. -
  32424.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32425.  with "unsubscribe usr-tc" in the body of the message.
  32426.  For information on digests or retrieving files and old messages send
  32427.  "help" to the same address.  Do not use quotes in your message.
  32428.  
  32429.  
  32430. -------------------------------------------------------------------------------
  32431.  
  32432. From: Jeff Mcadams <jeffm@iglou.com>
  32433. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  32434. Date: 25 Mar 1999 23:16:46 -0500 (EST)
  32435.  
  32436. Thus spake David Bolen
  32437. >Andy Berkvam <aberkvam@coredcs.com> writes:
  32438. >>   The only dialer that I've seen that actually does this is Trumpet
  32439. >>   Winsock.  I remember being very disappointed when Win95 came out.
  32440. >>   A simple pop-up display of some sort giving the reason why the
  32441. >>   connection was denied would have been a wonderful thing for ISPs.
  32442. >>   I don't know why they didn't add it.
  32443.  
  32444. >I'm not positive, but does Trumpet do PPP with PAP/CHAP or does it use
  32445. >a scripted login?
  32446.  
  32447. The later versions would do either.  I don't know much of anything about
  32448. under which circumstances it would print a message from the login.
  32449.  
  32450. >Of course, the annoying part is that as I noted in an earlier response,
  32451. >PAP does include a facility for including a message within the PPP
  32452. >frame that could be extracted if the clients wanted to.
  32453.  
  32454. Agreed, it would be really nice if this was made use of, but alas, tis
  32455. not.
  32456. -- 
  32457. Jeff McAdams                            Email: jeffm@iglou.com
  32458. Head Network Administrator              Voice: (502) 966-3848
  32459. IgLou Internet Services                        (800) 436-4456
  32460.  
  32461. -
  32462.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32463.  with "unsubscribe usr-tc" in the body of the message.
  32464.  For information on digests or retrieving files and old messages send
  32465.  "help" to the same address.  Do not use quotes in your message.
  32466.  
  32467.  
  32468. -------------------------------------------------------------------------------
  32469.  
  32470. From: <vanhalen@coredcs.com>
  32471. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  32472. Date: 25 Mar 1999 23:21:12 -0600 (CST)
  32473.  
  32474. I'd be interested in any further info or examples of this implementation
  32475. that you can give!
  32476.  
  32477. Steve
  32478.  
  32479.  
  32480. On Thu, 25 Mar 1999, Tatai SV Krishnan wrote:
  32481.  
  32482. > On Thu, 25 Mar 1999, Pete Ashdown wrote:
  32483. > 
  32484. > > C Thompson said once upon a time:
  32485. > > 
  32486. > > >Has anyone gotten 
  32487. > > >
  32488. > > >1) Auth-Type = "Reject:you did not pay your bill"
  32489. > > >2) Reply-Message = "Go away"
  32490. > > >
  32491. > > >types of messages to work with Total Control chasses?
  32492. > 
  32493. > > Man that would be cool.  Does Win95/98/NT have the ability to pass messages
  32494. > > on to the user?
  32495. > > 
  32496. > 
  32497. > NT windows do not support this - but here is what you can do, you can do 
  32498. > on the radius.  I have seen a setup where when the user does not pay the 
  32499. > bill, a script on the server check this and then changes the user to a 
  32500. > tunnel user.  Now when the user dials back he gets to a separate network, 
  32501. > then when the user brings up say netscape of IE - regardless of what ever 
  32502. > site he/she wishes to go, the bill payment webpage is displayed.
  32503. > 
  32504. > This does require some changes in DNS server and in setup and was done 
  32505. > using Hiper arcs.  Very cool
  32506. > 
  32507. > krish
  32508. > 
  32509. > > -
  32510. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32511. > >  with "unsubscribe usr-tc" in the body of the message.
  32512. > >  For information on digests or retrieving files and old messages send
  32513. > >  "help" to the same address.  Do not use quotes in your message.
  32514. > > 
  32515. > 
  32516. > -
  32517. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32518. >  with "unsubscribe usr-tc" in the body of the message.
  32519. >  For information on digests or retrieving files and old messages send
  32520. >  "help" to the same address.  Do not use quotes in your message.
  32521. > 
  32522.  
  32523.  
  32524. -
  32525.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32526.  with "unsubscribe usr-tc" in the body of the message.
  32527.  For information on digests or retrieving files and old messages send
  32528.  "help" to the same address.  Do not use quotes in your message.
  32529.  
  32530.  
  32531. -------------------------------------------------------------------------------
  32532.  
  32533. From: Brian Burgmeier <brianb@ntwrld.com>
  32534. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  32535. Date: 25 Mar 1999 11:06:01 -0800
  32536.  
  32537. Me too!  This sounds really cool!
  32538.  
  32539. Thanks-Brian
  32540.  
  32541. vanhalen@coredcs.com wrote:
  32542.  
  32543. > I'd be interested in any further info or examples of this implementation
  32544. > that you can give!
  32545. >
  32546. > Steve
  32547. >
  32548. > On Thu, 25 Mar 1999, Tatai SV Krishnan wrote:
  32549. >
  32550. > > On Thu, 25 Mar 1999, Pete Ashdown wrote:
  32551. > >
  32552. > > > C Thompson said once upon a time:
  32553. > > >
  32554. > > > >Has anyone gotten
  32555. > > > >
  32556. > > > >1) Auth-Type = "Reject:you did not pay your bill"
  32557. > > > >2) Reply-Message = "Go away"
  32558. > > > >
  32559. > > > >types of messages to work with Total Control chasses?
  32560. > >
  32561. > > > Man that would be cool.  Does Win95/98/NT have the ability to pass messages
  32562. > > > on to the user?
  32563. > > >
  32564. > >
  32565. > > NT windows do not support this - but here is what you can do, you can do
  32566. > > on the radius.  I have seen a setup where when the user does not pay the
  32567. > > bill, a script on the server check this and then changes the user to a
  32568. > > tunnel user.  Now when the user dials back he gets to a separate network,
  32569. > > then when the user brings up say netscape of IE - regardless of what ever
  32570. > > site he/she wishes to go, the bill payment webpage is displayed.
  32571. > >
  32572. > > This does require some changes in DNS server and in setup and was done
  32573. > > using Hiper arcs.  Very cool
  32574. > >
  32575. > > krish
  32576. > >
  32577. > > > -
  32578. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32579. > > >  with "unsubscribe usr-tc" in the body of the message.
  32580. > > >  For information on digests or retrieving files and old messages send
  32581. > > >  "help" to the same address.  Do not use quotes in your message.
  32582. > > >
  32583. > >
  32584. > > -
  32585. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32586. > >  with "unsubscribe usr-tc" in the body of the message.
  32587. > >  For information on digests or retrieving files and old messages send
  32588. > >  "help" to the same address.  Do not use quotes in your message.
  32589. > >
  32590. >
  32591. > -
  32592. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32593. >  with "unsubscribe usr-tc" in the body of the message.
  32594. >  For information on digests or retrieving files and old messages send
  32595. >  "help" to the same address.  Do not use quotes in your message.
  32596.  
  32597.  
  32598. -
  32599.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32600.  with "unsubscribe usr-tc" in the body of the message.
  32601.  For information on digests or retrieving files and old messages send
  32602.  "help" to the same address.  Do not use quotes in your message.
  32603.  
  32604.  
  32605. -------------------------------------------------------------------------------
  32606.  
  32607. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  32608. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  32609. Date: 26 Mar 1999 08:11:54 -0600 (CST)
  32610.  
  32611. I have to dig through my notes - but sure sometime this week I will come 
  32612. up with a write up and desing for this.
  32613.  
  32614. krish
  32615.  
  32616.         \    T.S.V. Krishnan  \
  32617.          \      Network System Engineer \ ( : - : )
  32618.           \     3Com ............   \
  32619.         ----------------------------------------------/
  32620. tkrishna@bubba.ae.usr.com  
  32621. ----------------------------/ http://interproc.ae.usr.com ----/
  32622. The Yadda Yadda Search - for simple anwers - http://interproc.ae.usr.com/tkb.html
  32623.     Any Sufficiently advanced bug is indistinguishable for a feature.
  32624.                         - Rick Kulawiec
  32625.  
  32626. On Thu, 25 Mar 1999 vanhalen@coredcs.com wrote:
  32627.  
  32628. > I'd be interested in any further info or examples of this implementation
  32629. > that you can give!
  32630. > 
  32631. > Steve
  32632. > 
  32633. > 
  32634. > On Thu, 25 Mar 1999, Tatai SV Krishnan wrote:
  32635. > 
  32636. > > On Thu, 25 Mar 1999, Pete Ashdown wrote:
  32637. > > 
  32638. > > > C Thompson said once upon a time:
  32639. > > > 
  32640. > > > >Has anyone gotten 
  32641. > > > >
  32642. > > > >1) Auth-Type = "Reject:you did not pay your bill"
  32643. > > > >2) Reply-Message = "Go away"
  32644. > > > >
  32645. > > > >types of messages to work with Total Control chasses?
  32646. > > 
  32647. > > > Man that would be cool.  Does Win95/98/NT have the ability to pass messages
  32648. > > > on to the user?
  32649. > > > 
  32650. > > 
  32651. > > NT windows do not support this - but here is what you can do, you can do 
  32652. > > on the radius.  I have seen a setup where when the user does not pay the 
  32653. > > bill, a script on the server check this and then changes the user to a 
  32654. > > tunnel user.  Now when the user dials back he gets to a separate network, 
  32655. > > then when the user brings up say netscape of IE - regardless of what ever 
  32656. > > site he/she wishes to go, the bill payment webpage is displayed.
  32657. > > 
  32658. > > This does require some changes in DNS server and in setup and was done 
  32659. > > using Hiper arcs.  Very cool
  32660. > > 
  32661. > > krish
  32662. > > 
  32663. > > > -
  32664. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32665. > > >  with "unsubscribe usr-tc" in the body of the message.
  32666. > > >  For information on digests or retrieving files and old messages send
  32667. > > >  "help" to the same address.  Do not use quotes in your message.
  32668. > > > 
  32669. > > 
  32670. > > -
  32671. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32672. > >  with "unsubscribe usr-tc" in the body of the message.
  32673. > >  For information on digests or retrieving files and old messages send
  32674. > >  "help" to the same address.  Do not use quotes in your message.
  32675. > > 
  32676. > 
  32677. > 
  32678. > -
  32679. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32680. >  with "unsubscribe usr-tc" in the body of the message.
  32681. >  For information on digests or retrieving files and old messages send
  32682. >  "help" to the same address.  Do not use quotes in your message.
  32683. > 
  32684.  
  32685. -
  32686.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32687.  with "unsubscribe usr-tc" in the body of the message.
  32688.  For information on digests or retrieving files and old messages send
  32689.  "help" to the same address.  Do not use quotes in your message.
  32690.  
  32691.  
  32692. -------------------------------------------------------------------------------
  32693.  
  32694. From: Scott Boggs <sboggs@unitedbank.net>
  32695. Subject: (usr-tc) specific modem probs.
  32696. Date: 26 Mar 1999 13:41:28 -0500
  32697.  
  32698. My users with a few different types of modems are still having trouble
  32699. connecting to the TC.  These same users can connect fine to an Ascend
  32700. max4004.
  32701. The two main types of modems involved are iMac modems,Rockwell56k PCI,
  32702. and a few users with LT winmodems.  Most users are OK.  Anybody know of any
  32703. probs
  32704. with TC and these modems? Here are the usual specifics, let me know if more
  32705. info would be helpful.
  32706.  
  32707. TCtrl:
  32708. 8 PRI - each with own D channel
  32709. 8 DSP - ver 1.2.43(same prob. with 1.2.59)
  32710. 1 HARC - ver 4.1.11 (?would this make a diff?)
  32711. Unit purch. New last Dec.
  32712.  
  32713. Ascend:
  32714. 3 PRI - bound on 1 D channel
  32715. 6 SL-12MOD-S56 modems
  32716. Software ver 6.1.7
  32717.  
  32718. Thanks,
  32719. Scott Boggs
  32720. Information Systems Manager
  32721. United Bank
  32722.  
  32723.  
  32724.  
  32725. -
  32726.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32727.  with "unsubscribe usr-tc" in the body of the message.
  32728.  For information on digests or retrieving files and old messages send
  32729.  "help" to the same address.  Do not use quotes in your message.
  32730.  
  32731.  
  32732. -------------------------------------------------------------------------------
  32733.  
  32734. From: "Wayne Barber" <barberw@tidewater.net>
  32735. Subject: RE: (usr-tc) specific modem probs.
  32736. Date: 26 Mar 1999 14:15:29 -0500
  32737.  
  32738. > [mailto:owner-usr-tc@lists.xmission.com]On Behalf Of Scott Boggs
  32739. > Sent: Friday, March 26, 1999 1:41 PM
  32740. > To: usr-tc@lists.xmission.com
  32741. > Subject: (usr-tc) specific modem probs.
  32742. >
  32743. >
  32744. > My users with a few different types of modems are still having trouble
  32745. > connecting to the TC.  These same users can connect fine to an Ascend
  32746. > max4004.
  32747. > The two main types of modems involved are iMac modems,Rockwell56k PCI,
  32748. > and a few users with LT winmodems.  Most users are OK.  Anybody
  32749. > know of any
  32750. > probs
  32751. > with TC and these modems?
  32752.  
  32753. Here's the lowdown:
  32754. LT Winmodems: download the latest driver: 5.39. You can get it from
  32755. http://www.tidewater.net/56k.shtml.
  32756.  
  32757. Rockwell 56k PCI: these can be either HCF or ITU modems. HCF are real crap.
  32758. They need in init string of +ms=v34 to turn off all 56k attempts. The ITU
  32759. (or non-HCF) Rockwells use an init string of +ms=11,1 or update the drivers
  32760. from the manufacturer's site.
  32761.  
  32762. iMac: download the modem updater 1.2.1 from Apple. Or get it on the CD that
  32763. came with MacAddict(?) in January ( I think. I don't get the mag).
  32764.  
  32765. Go to http://www.56k.com for more info on the init strings.
  32766.  
  32767. Wayne Barber
  32768. Coastal Telco Services
  32769.  
  32770.  
  32771. -
  32772.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32773.  with "unsubscribe usr-tc" in the body of the message.
  32774.  For information on digests or retrieving files and old messages send
  32775.  "help" to the same address.  Do not use quotes in your message.
  32776.  
  32777.  
  32778. -------------------------------------------------------------------------------
  32779.  
  32780. From: Mike Andrews <mandrews@termfrost.org>
  32781. Subject: Re: (usr-tc) modem configs
  32782. Date: 26 Mar 1999 17:00:44 -0500 (EST)
  32783.  
  32784. On Mon, 22 Mar 1999, Mike Andrews wrote:
  32785.  
  32786. > I'm also having a problem that maybe someone else can help with here. The
  32787. > above init string doesn't disable v.90/x2 correctly on the Quads. (Works
  32788. > great on DSP's.)  If I call in with a Courier, it chokes during the
  32789. > handshake -- it sounds as if one side is attempting x2 (not v.90) and the
  32790. > other side is trying v.34.  (It dies during the line frequency probe
  32791. > sequence, in other words.)  If I call in with an LT Winmodem it seems to
  32792. > be more or less OK.
  32793. > 
  32794. > So...  What's the *correct* AT sequence to completely kill all 56K
  32795. > modulations on a Quad modem and leave v.34 intact?
  32796.  
  32797. If anyone cares, I fixed this by disabling all 3 x2 modes -- client,
  32798. server, and symmetric.  Apparently disabling just server wasn't good
  32799. enough for the Quads.  Go figure...
  32800.  
  32801.  
  32802. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  32803. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  32804. Microsoft operating system is like a dog without a brick tied to its head."
  32805.  
  32806.  
  32807. -
  32808.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32809.  with "unsubscribe usr-tc" in the body of the message.
  32810.  For information on digests or retrieving files and old messages send
  32811.  "help" to the same address.  Do not use quotes in your message.
  32812.  
  32813.  
  32814. -------------------------------------------------------------------------------
  32815.  
  32816. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  32817. Subject: (usr-tc) Reply message
  32818. Date: 26 Mar 1999 17:44:14 -0600 (CST)
  32819.  
  32820.   This message is in MIME format.  The first part should be readable text,
  32821.   while the remaining parts are likely unreadable without MIME-aware tools.
  32822.   Send mail to mime@docserver.cac.washington.edu for more info.
  32823.  
  32824. --416219727-1971951701-922491854=:30300
  32825. Content-Type: TEXT/PLAIN; charset=US-ASCII
  32826.  
  32827.  
  32828. OK I am attaching a figure here - Use xfig to open the same.
  32829.  
  32830. The idea here is to have the users who have not paid their bills to go to 
  32831. a Bill payment web site - irrespective of where ever they want to go.
  32832.  
  32833. In order to do this you need two HiPer arcs, A radius server with a 
  32834. script that checks for expiration dates and converts the user settings, 
  32835. A DNS server that would fake all the DNS names and your Bill payment web 
  32836. server.
  32837.  
  32838. The script on the radius server will check for users who have not paid 
  32839. their dues and change their user settings.  The user settings are changed 
  32840. such that the users now will actually establish a L2tp or PPTP tunnel.
  32841.  
  32842. So when the user dials in he/she will see normal ppp connections but in 
  32843. effect the user connection will be terminated on HiPer arc 2.  which is a 
  32844. internal intranet.
  32845.  
  32846. The user will not be able to go to the internet so to check status he/she 
  32847. will try to open their web browser - The DNS server will send all DNS 
  32848. request to the Bill payment web server.  Thus no matter where the user 
  32849. wants to go they will see the bill payment server only.
  32850.  
  32851. If the user tries to go out using a differenet dns or programs a static 
  32852. dns - it does not matter - because they will not go anywhere.
  32853.  
  32854. The configuration on the HiPer arc side is very easy - Radius and scripts 
  32855. are also very easy but the DNS is a little tricky.  
  32856.  
  32857.  
  32858. Hope this helps.
  32859.  
  32860. PS:  Dont flame me for attachments.
  32861.  
  32862.  
  32863. regards
  32864.  
  32865. krish
  32866. --416219727-1971951701-922491854=:30300
  32867. Content-Type: TEXT/PLAIN; charset=US-ASCII; name="reply.fig"
  32868. Content-Transfer-Encoding: BASE64
  32869. Content-ID: <Pine.LNX.3.91.990326174414.30300C@bubba.ae.usr.com>
  32870. Content-Description: 
  32871.  
  32872. I0ZJRyAyLjENCjgwIDINCjEgMyAwIDEgLTEgMCAwIDAgMC4wMDAwMCAxIDAu
  32873. MDAwIDE3NCAxMjQgOTcgOTcgMTc0IDEyNCAyNjQgMTU5DQoyIDIgMCAxIC0x
  32874. IDAgMCAwIDAuMDAwIDAgMCAwDQoJIDI1NCAzMzkgMjU0IDI5NCAxMjkgMjk0
  32875. IDEyOSAzMzkgMjU0IDMzOSA5OTk5IDk5OTkNCjIgMiAwIDEgLTEgMCAwIDAg
  32876. MC4wMDAgMCAwIDANCgkgMjk0IDUwOSAyOTQgNDI0IDk5IDQyNCA5OSA1MDkg
  32877. Mjk0IDUwOSA5OTk5IDk5OTkNCjIgMiAwIDEgLTEgMCAwIDAgMC4wMDAgMCAw
  32878. IDANCgkgMTE5IDQyOSAxMTkgNDI5IDExOSA0MjkgMTE5IDQyOSAxMTkgNDI5
  32879. IDk5OTkgOTk5OQ0KMiAyIDAgMSAtMSAwIDAgMSAwLjAwMCAwIDAgMA0KCSAx
  32880. MTkgNDI5IDEzNCA0MjkgMTM0IDQ3NCAxMTkgNDc0IDExOSA0MjkgOTk5OSA5
  32881. OTk5DQoyIDEgMCAxIC0xIDAgMCAwIDAuMDAwIC0xIDAgMA0KCSAxNzQgMjE5
  32882. IDE3NCAyOTQgMTc0IDI5NCAxNzkgMjg5IDk5OTkgOTk5OQ0KMiAxIDAgMSAt
  32883. MSAwIDAgMCAwLjAwMCAtMSAwIDANCgkgMTc0IDMzOSAxNzQgNDE5IDk5OTkg
  32884. OTk5OQ0KMiAyIDAgMSAtMSAwIDAgMCAwLjAwMCAwIDAgMA0KCSA0MzQgMTY0
  32885. IDQzNCAxMDkgMzI5IDEwOSAzMjkgMTY0IDQzNCAxNjQgOTk5OSA5OTk5DQoy
  32886. IDIgMCAxIC0xIDAgMCAwIDAuMDAwIDAgMCAwDQoJIDQxNCA0NDkgNDE0IDM5
  32887. NCAzNjQgMzk0IDM2NCA0NDkgNDE0IDQ0OSA5OTk5IDk5OTkNCjIgMiAwIDEg
  32888. LTEgMCAwIDAgMC4wMDAgMCAwIDANCgkgNTQ0IDM1NCA1NDQgMjQ5IDQ2NCAy
  32889. NDkgNDY0IDM1NCA1NDQgMzU0IDk5OTkgOTk5OQ0KMiAyIDAgMSAtMSAwIDAg
  32890. MCAwLjAwMCAwIDAgMA0KCSA3MDkgMjY0IDcwOSAxNTkgNjM0IDE1OSA2MzQg
  32891. MjY0IDcwOSAyNjQgOTk5OSA5OTk5DQoyIDEgMCAxIC0xIDAgMCAwIDAuMDAw
  32892. IC0xIDAgMA0KCSAxNzQgMjQ5IDM2NCAyNDkgMzY0IDI0OSAzNjkgMjQ5IDk5
  32893. OTkgOTk5OQ0KMiAxIDAgMSAtMSAwIDAgMCAwLjAwMCAtMSAwIDANCgkgMzY5
  32894. IDE2NCAzNjkgMzk0IDk5OTkgOTk5OQ0KMiAxIDAgMSAtMSAwIDAgMCAwLjAw
  32895. MCAtMSAwIDANCgkgMzY5IDMwOSA0NjQgMzA5IDk5OTkgOTk5OQ0KMiAxIDAg
  32896. MSAtMSAwIDAgMCAwLjAwMCAtMSAwIDANCgkgNTQ5IDI4NCA1NzQgMjg0IDk5
  32897. OTkgOTk5OQ0KMiAxIDAgMSAtMSAwIDAgMCAwLjAwMCAtMSAwIDANCgkgNjM0
  32898. IDIyNCA1OTQgMjI0IDU5NCAxNzkgOTk5OSA5OTk5DQoyIDEgMCAxIC0xIDAg
  32899. MCAwIDAuMDAwIC0xIDAgMA0KCSA1OTQgMjI0IDU5NCA0MTQgOTk5OSA5OTk5
  32900. DQoyIDEgMCAxIC0xIDAgMCAwIDAuMDAwIC0xIDAgMA0KCSA1NzQgMjg0IDU5
  32901. NCAyODQgOTk5OSA5OTk5DQozIDIgMCAxIC0xIDAgMCAwIDAuMDAwIDAgMA0K
  32902. CSAxODkgNDI0IDE5NCAyNjQgMzg0IDI2NCAzODQgMjk5IDQ3NCAyOTkgNDY5
  32903. IDI5OSA5OTk5IDk5OTkNCgkgMC4wMDAgMC4wMDAgMTU5Ljc0MiAzMzUuOTkz
  32904. IDE2MC45OTIgMjk1Ljk5MyAyNDYuMjM2IDIxMy4zNzANCgkgMzMxLjc1MSAy
  32905. MTEuNzUyIDM5My42MjUgMjczLjYyNSAzNzQuMzc1IDI4OS4zNzUgNDA4Ljc1
  32906. MCAzMjMuNzQ5DQoJIDQ3NC4wMDAgMjk5LjAwMCA0NzQuMDAwIDI5OS4wMDAg
  32907. NDcyLjc1MCAyOTkuMDAwIDAuMDAwIDAuMDAwDQo0IDAgMCAxMiAwIC0xIDAg
  32908. MC4wMDAwMCA0IDkgNDAgMTI0IDEwNCBJbnRlcm5ldAENCjQgMCAwIDEyIDAg
  32909. LTEgMCAwLjAwMDAwIDQgOSA2MSAxNDkgMzE0IENvcmUgUm91dGVyAQ0KNCAw
  32910. IDAgMTIgMCAtMSAwIDAuMDAwMDAgNCA5IDU3IDE1OSA0ODQgSGlQZXIgQVJD
  32911. AQ0KNCAwIDAgMTIgMCAtMSAwIDAuMDAwMDAgNCA5IDcxIDM0NCAxMzQgUmFk
  32912. aXVzIFNlcnZlcgENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAwIDQgOSAyNCAz
  32913. NjkgNDE5IFdlYgENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAwIDQgOSA1NyA0
  32914. NzkgMjg5IEhpUGVyIEFSQwENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAwIDQg
  32915. OSAyNSA2NDkgMTg5IEROUwENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAwIDQg
  32916. MTIgMjkgNjQ5IDIwOSBQcm94eQENCjQgMCAwIDEyIDAgLTEgMCAwLjAwMDAw
  32917. IDQgOSAzMCA0MTQgMzI0IEV0aDogMgENCjQgMCAwIDEyIDAgLTEgMCAwLjAw
  32918. MDAwIDQgOSAyNyA1NTQgMzA5IEV0aCAxAQ0KNCAwIDAgMTIgMCAtMSAwIDAu
  32919. MDAwMDAgNCA5IDI3IDIxNCAyMzQgTDJUUAENCjQgMCAwIDEyIDAgLTEgMCAw
  32920. LjAwMDAwIDQgOSAxNyAzNzQgNDM0IEJpbGwBDQo0IDAgMCAxMiAwIC0xIDAg
  32921. MC4wMDAwMCA0IDkgNiA1MDQgMzI5IDIBDQo0IDAgMCAxMiAwIC0xIDAgMC4w
  32922. MDAwMCA0IDkgNiAyNTkgNDg0IDEBDQo=
  32923. --416219727-1971951701-922491854=:30300--
  32924.  
  32925. -
  32926.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32927.  with "unsubscribe usr-tc" in the body of the message.
  32928.  For information on digests or retrieving files and old messages send
  32929.  "help" to the same address.  Do not use quotes in your message.
  32930.  
  32931.  
  32932. -------------------------------------------------------------------------------
  32933.  
  32934. From: Andy Berkvam <aberkvam@coredcs.com>
  32935. Subject: RE: (usr-tc) specific modem probs.
  32936. Date: 26 Mar 1999 17:33:33 -0600 (CST)
  32937.  
  32938. On Fri, 26 Mar 1999, Wayne Barber wrote:
  32939.  
  32940. > LT Winmodems: download the latest driver: 5.39. You can get it from
  32941. > http://www.tidewater.net/56k.shtml.
  32942. > 
  32943.   The latest driver is actually 5.43.  You can get it from
  32944. <http://www.808hi.com/56k/x2-lucent.htm>.
  32945.  
  32946. > iMac: download the modem updater 1.2.1 from Apple. Or get it on the CD that
  32947. > came with MacAddict(?) in January ( I think. I don't get the mag).
  32948. > 
  32949.   For the iMac and PowerBook G3, you can get the Apple Modem Updater US
  32950. 1.2.1 from <http://asu.info.apple.com/swupdates.nsf/artnum/n10665>.  For
  32951. other Macs with built-in 56K modems, you can get the Apple/GV 56K Updaters
  32952. 1.1.3 from <http://asu.info.apple.com/swupdates.nsf/artnum/n11206>.  Both
  32953. of these update Apple modems to the Rockwell 2.2 code.
  32954.  
  32955.   MacAddict occasionally includes Apple Updates on its CD.  I know I've
  32956. seen the modem updates on the CDs but I don't know what months offhand.
  32957.  
  32958. Andy
  32959.  
  32960. -- 
  32961. ===========================================================================
  32962. Andy Berkvam          | Freedom of the press is guaranteed only to those 
  32963.                       | who own one.
  32964. Email:                |                           - Abbott Joseph Liebling
  32965.  aberkvam@coredcs.com | 
  32966.  (MIME Attachments OK)|-WWW Pages: <http://www.coredcs.com/~aberkvam/>
  32967. ===========================================================================
  32968.  
  32969.  
  32970. -
  32971.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  32972.  with "unsubscribe usr-tc" in the body of the message.
  32973.  For information on digests or retrieving files and old messages send
  32974.  "help" to the same address.  Do not use quotes in your message.
  32975.  
  32976.  
  32977. -------------------------------------------------------------------------------
  32978.  
  32979. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  32980. Subject: Re: (usr-tc) specific modem probs.
  32981. Date: 26 Mar 1999 21:56:36 -0600 (CST)
  32982.  
  32983. On Fri, 26 Mar 1999, Scott Boggs wrote:
  32984.  
  32985. > My users with a few different types of modems are still having trouble
  32986. > connecting to the TC.  These same users can connect fine to an Ascend
  32987. > max4004.
  32988.  
  32989. Ascend and Rockwell modems would work fine - In this case you are 
  32990. connecting Rockwell to Rockwell, and most likely you are connecting K56.
  32991.  
  32992. > The two main types of modems involved are iMac modems,Rockwell56k PCI,
  32993. > and a few users with LT winmodems.  Most users are OK.  Anybody know of any
  32994. > probs
  32995.  
  32996. LT win modems with latest code does not have problems with USR equip.
  32997. Get the latest LT code for your modems.  Any LT code after octover 1998 
  32998. should be fine.
  32999.  
  33000. > with TC and these modems? Here are the usual specifics, let me know if more
  33001. > info would be helpful.
  33002. > 
  33003. As far as Rockwell is concerned - certain modems with new code should 
  33004. work but there are bugs on Rockwell side that have to be fixed.
  33005. using 1.2.43 may help a bit but still some issues.
  33006.  
  33007. krish
  33008.  
  33009.  
  33010. > TCtrl:
  33011. > 8 PRI - each with own D channel
  33012. > 8 DSP - ver 1.2.43(same prob. with 1.2.59)
  33013. > 1 HARC - ver 4.1.11 (?would this make a diff?)
  33014. > Unit purch. New last Dec.
  33015. > 
  33016. > Ascend:
  33017. > 3 PRI - bound on 1 D channel
  33018. > 6 SL-12MOD-S56 modems
  33019. > Software ver 6.1.7
  33020. > 
  33021. > Thanks,
  33022. > Scott Boggs
  33023. > Information Systems Manager
  33024. > United Bank
  33025. > 
  33026. > 
  33027. > 
  33028. > -
  33029. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33030. >  with "unsubscribe usr-tc" in the body of the message.
  33031. >  For information on digests or retrieving files and old messages send
  33032. >  "help" to the same address.  Do not use quotes in your message.
  33033. > 
  33034.  
  33035. -
  33036.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33037.  with "unsubscribe usr-tc" in the body of the message.
  33038.  For information on digests or retrieving files and old messages send
  33039.  "help" to the same address.  Do not use quotes in your message.
  33040.  
  33041.  
  33042. -------------------------------------------------------------------------------
  33043.  
  33044. From: Sean Herr <Sean@YNC.NET>
  33045. Subject: (usr-tc) All Calls Showing Port 1 in radius
  33046. Date: 26 Mar 1999 22:43:22 -0600
  33047.  
  33048. I have a chassis on PRI's with Quad's and a ARC. All ports numbers are
  33049. hitting Radius as port 1.  My other chassis did this until I upped the code
  33050. to 4.1.59 and did a reboot.  I have done the same on this one with no luck.
  33051.  
  33052. If I pop in the Netserver card all is fine.
  33053.  
  33054. My GW Slot is 16 and the calls still terminate on the modems, even after the
  33055. reboot.  When I pop in the Netserver, calls are handled by the Netserver
  33056. card.
  33057.  
  33058. The thing that is even more confusing is that the port numbers should start
  33059. on slot 2 which would actually be port 25????
  33060.  
  33061. I cannot figure this out for the life of me, and in the mean time have no
  33062. concurrency login control.
  33063.  
  33064.  
  33065. Sean Herr
  33066.  
  33067. -
  33068.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33069.  with "unsubscribe usr-tc" in the body of the message.
  33070.  For information on digests or retrieving files and old messages send
  33071.  "help" to the same address.  Do not use quotes in your message.
  33072.  
  33073.  
  33074. -------------------------------------------------------------------------------
  33075.  
  33076. From: Robert Reynolds <lists@lcii.net>
  33077. Subject: Re: (usr-tc) specific modem probs.
  33078. Date: 27 Mar 1999 00:13:41 -0600 (EST)
  33079.  
  33080. I've always manged to get LT Winmodems to work.  Just disable Flex and
  33081. v.90.
  33082.  
  33083. On Fri, 26 Mar 1999, Scott Boggs wrote:
  33084.  
  33085. > My users with a few different types of modems are still having trouble
  33086. > connecting to the TC.  These same users can connect fine to an Ascend
  33087. > max4004.
  33088. > The two main types of modems involved are iMac modems,Rockwell56k PCI,
  33089. > and a few users with LT winmodems.  Most users are OK.  Anybody know of any
  33090. > probs
  33091. > with TC and these modems? Here are the usual specifics, let me know if more
  33092. > info would be helpful.
  33093. > 
  33094. > TCtrl:
  33095. > 8 PRI - each with own D channel
  33096. > 8 DSP - ver 1.2.43(same prob. with 1.2.59)
  33097. > 1 HARC - ver 4.1.11 (?would this make a diff?)
  33098. > Unit purch. New last Dec.
  33099. > 
  33100. > Ascend:
  33101. > 3 PRI - bound on 1 D channel
  33102. > 6 SL-12MOD-S56 modems
  33103. > Software ver 6.1.7
  33104. > 
  33105. > Thanks,
  33106. > Scott Boggs
  33107. > Information Systems Manager
  33108. > United Bank
  33109. > 
  33110. > 
  33111. > 
  33112. > -
  33113. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33114. >  with "unsubscribe usr-tc" in the body of the message.
  33115. >  For information on digests or retrieving files and old messages send
  33116. >  "help" to the same address.  Do not use quotes in your message.
  33117. > 
  33118.  
  33119.  
  33120. -
  33121.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33122.  with "unsubscribe usr-tc" in the body of the message.
  33123.  For information on digests or retrieving files and old messages send
  33124.  "help" to the same address.  Do not use quotes in your message.
  33125.  
  33126.  
  33127. -------------------------------------------------------------------------------
  33128.  
  33129. From: Stephen Amadei <amadei@dandy.net>
  33130. Subject: Re: (usr-tc) Reply message
  33131. Date: 27 Mar 1999 01:06:49 -0500 (EST)
  33132.  
  33133. On Fri, 26 Mar 1999, Tatai SV Krishnan wrote:
  33134.  
  33135. <snipped excellent way to bite non-paying deadbeat lamers...>
  33136.  
  33137. Krish, isn't this a little involved?   
  33138.  
  33139. We are currently using a Radius server that uses a flat file generated
  33140. periodically from a database... in the future it will be a live
  33141. connection, but instead of setting up a tunnel straight to your billing
  33142. webserver and wasting a second ARC card, couldn't you just give your
  33143. deadbeat customer an IP address from an IP address pool of unroutable 
  33144. IP adresses?  Say... 10.10.10.10.  (I think that's unroutable...) and
  33145. provide a static route from your TC equipment to a computer that runs a
  33146. hacked name server, pointing all requests to this system, which is also 
  33147. a webserver (showing a page describing the payment dilemma... and taking
  33148. credit cards...), a mail server (only giving out a e-bill email) and
  33149. telnet (logs in, spits out messages and disconnects).
  33150.  
  33151. With the unroutable address, the customer shouldn't be able to do much
  33152. else... or is there something here I am overlooking... me thinks this
  33153. solution only requires updating the Radius records with a static IP, a
  33154. static route on each ARC/Netserver and a spare system running some TCPIP
  33155. services...  Any thoughts?
  33156.  
  33157.                     ----Steve
  33158. Stephen Amadei
  33159. Director of MIS
  33160. Dandy Connections, Inc.
  33161. Atlantic City, NJ
  33162.  
  33163.  
  33164. -
  33165.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33166.  with "unsubscribe usr-tc" in the body of the message.
  33167.  For information on digests or retrieving files and old messages send
  33168.  "help" to the same address.  Do not use quotes in your message.
  33169.  
  33170.  
  33171. -------------------------------------------------------------------------------
  33172.  
  33173. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  33174. Subject: Re: (usr-tc) Reply message
  33175. Date: 27 Mar 1999 05:05:40 -0600 (CST)
  33176.  
  33177. On Sat, 27 Mar 1999, Stephen Amadei wrote:
  33178.  
  33179. > On Fri, 26 Mar 1999, Tatai SV Krishnan wrote:
  33180. > 
  33181. > <snipped excellent way to bite non-paying deadbeat lamers...>
  33182. > 
  33183. > Krish, isn't this a little involved?   
  33184.  
  33185. Yes it is little involved, the whole configuration including the DNS 
  33186. server etc takes about 5-10 hours of work.
  33187.  
  33188.  
  33189. > 
  33190. > We are currently using a Radius server that uses a flat file generated
  33191. > periodically from a database... in the future it will be a live
  33192. > connection, but instead of setting up a tunnel straight to your billing
  33193. > webserver and wasting a second ARC card, couldn't you just give your
  33194.  
  33195. No you are not wasting another arc, you see The second arc has both the 
  33196. interfaces configured.  The first interface goes to the private network 
  33197. and the second is still connected to the internet.  Essentially you can 
  33198. use both the hiper arc's for regular connection.  The beauty of this here 
  33199. is when the customer gets a unroutable address and when they try to 
  33200. access the web - they know what is wrong.  This stops the phone calls to 
  33201. your customer service.
  33202.  
  33203. > deadbeat customer an IP address from an IP address pool of unroutable 
  33204. > IP adresses?  Say... 10.10.10.10.  (I think that's unroutable...) and
  33205. > provide a static route from your TC equipment to a computer that runs a
  33206. > hacked name server, pointing all requests to this system, which is also 
  33207. > a webserver (showing a page describing the payment dilemma... and taking
  33208. > credit cards...), a mail server (only giving out a e-bill email) and
  33209. > telnet (logs in, spits out messages and disconnects).
  33210. >
  33211.  
  33212. Well the user does get a bogus address - and the only service available 
  33213. to the user is access to the billing server and nothing else.
  33214.  
  33215.  
  33216.  
  33217.  
  33218.  
  33219.  
  33220. > With the unroutable address, the customer shouldn't be able to do much
  33221. > else... or is there something here I am overlooking... me thinks this
  33222. > solution only requires updating the Radius records with a static IP, a
  33223. > static route on each ARC/Netserver and a spare system running some TCPIP
  33224. > services...  Any thoughts?
  33225. > 
  33226.  
  33227. This would the easy way out and you do have to make sure that support 
  33228. does know about this and inform them about what to tell the customer.
  33229.  
  33230. krish
  33231.  
  33232.  
  33233.  
  33234.  
  33235. >                     ----Steve
  33236. > Stephen Amadei
  33237. > Director of MIS
  33238. > Dandy Connections, Inc.
  33239. > Atlantic City, NJ
  33240. > 
  33241. > 
  33242. > -
  33243. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33244. >  with "unsubscribe usr-tc" in the body of the message.
  33245. >  For information on digests or retrieving files and old messages send
  33246. >  "help" to the same address.  Do not use quotes in your message.
  33247. > 
  33248.  
  33249. -
  33250.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33251.  with "unsubscribe usr-tc" in the body of the message.
  33252.  For information on digests or retrieving files and old messages send
  33253.  "help" to the same address.  Do not use quotes in your message.
  33254.  
  33255.  
  33256. -------------------------------------------------------------------------------
  33257.  
  33258. From: Jeff Mcadams <jeffm@iglou.com>
  33259. Subject: Re: (usr-tc) All Calls Showing Port 1 in radius
  33260. Date: 27 Mar 1999 09:17:08 -0500 (EST)
  33261.  
  33262. Thus spake Sean Herr
  33263. >I have a chassis on PRI's with Quad's and a ARC. All ports numbers are
  33264. >hitting Radius as port 1.  My other chassis did this until I upped the
  33265. >code to 4.1.59 and did a reboot.  I have done the same on this one with
  33266. >no luck.
  33267.  
  33268. >If I pop in the Netserver card all is fine.
  33269.  
  33270. >My GW Slot is 16 
  33271.  
  33272. That's a problem.  The GW slot being set to 16 indicates to the PRI card
  33273. that the card in slot 16 is supposed to terminate the ISDN calls.  The
  33274. Arc can't terminate ISDN calls though, only the Munich card on the
  33275. NETServer can do that.  Set the ISDN GW slot to 0 and that could very
  33276. likely help.
  33277.  
  33278. >and the calls still terminate on the modems, even after the reboot.
  33279. >When I pop in the Netserver, calls are handled by the Netserver card.
  33280.  
  33281. >The thing that is even more confusing is that the port numbers should
  33282. >start on slot 2 which would actually be port 25????
  33283.  
  33284. Actually, it would be 257.  The Arc reserves 256 port numbers for each
  33285. slot in anticipation of higher density cards down the road.
  33286. -- 
  33287. Jeff McAdams                            Email: jeffm@iglou.com
  33288. Head Network Administrator              Voice: (502) 966-3848
  33289. IgLou Internet Services                        (800) 436-4456
  33290.  
  33291. -
  33292.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33293.  with "unsubscribe usr-tc" in the body of the message.
  33294.  For information on digests or retrieving files and old messages send
  33295.  "help" to the same address.  Do not use quotes in your message.
  33296.  
  33297.  
  33298. -------------------------------------------------------------------------------
  33299.  
  33300. From: Sean Herr <Sean@YNC.NET>
  33301. Subject: RE: (usr-tc) All Calls Showing Port 1 in radius
  33302. Date: 27 Mar 1999 11:41:36 -0600
  33303.  
  33304. It was originally set to 0 but I set it to 16 to not terminate calls 
  33305. on the modems.  I was not aware of the Munich card on the netserver 
  33306. was what controlled the calls, I just assumed that the ARC would 
  33307. handle it.
  33308.  
  33309. Anyway, I set it to 0 with no help.
  33310.  
  33311. All ports are hitting radius as port1.
  33312.  
  33313. Any other suggestions?
  33314.  
  33315.  
  33316.  
  33317.  
  33318. -----Original Message-----
  33319. Sent: Saturday, March 27, 1999 8:17 AM
  33320.  
  33321.  
  33322. Thus spake Sean Herr
  33323. >I have a chassis on PRI's with Quad's and a ARC. All ports numbers are
  33324. >hitting Radius as port 1.  My other chassis did this until I upped the
  33325. >code to 4.1.59 and did a reboot.  I have done the same on this one with
  33326. >no luck.
  33327.  
  33328. >If I pop in the Netserver card all is fine.
  33329.  
  33330. >My GW Slot is 16 
  33331.  
  33332. That's a problem.  The GW slot being set to 16 indicates to the PRI card
  33333. that the card in slot 16 is supposed to terminate the ISDN calls.  The
  33334. Arc can't terminate ISDN calls though, only the Munich card on the
  33335. NETServer can do that.  Set the ISDN GW slot to 0 and that could very
  33336. likely help.
  33337.  
  33338. >and the calls still terminate on the modems, even after the reboot.
  33339. >When I pop in the Netserver, calls are handled by the Netserver card.
  33340.  
  33341. >The thing that is even more confusing is that the port numbers should
  33342. >start on slot 2 which would actually be port 25????
  33343.  
  33344. Actually, it would be 257.  The Arc reserves 256 port numbers for each
  33345. slot in anticipation of higher density cards down the road.
  33346. -- 
  33347. Jeff McAdams                            Email: jeffm@iglou.com
  33348. Head Network Administrator              Voice: (502) 966-3848
  33349. IgLou Internet Services                        (800) 436-4456
  33350.  
  33351. -
  33352.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33353.  with "unsubscribe usr-tc" in the body of the message.
  33354.  For information on digests or retrieving files and old messages send
  33355.  "help" to the same address.  Do not use quotes in your message.
  33356.  
  33357. -
  33358.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33359.  with "unsubscribe usr-tc" in the body of the message.
  33360.  For information on digests or retrieving files and old messages send
  33361.  "help" to the same address.  Do not use quotes in your message.
  33362.  
  33363.  
  33364. -------------------------------------------------------------------------------
  33365.  
  33366. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  33367. Subject: RE: (usr-tc) All Calls Showing Port 1 in radius
  33368. Date: 27 Mar 1999 12:56:23 -0600 (CST)
  33369.  
  33370. On Sat, 27 Mar 1999, Sean Herr wrote:
  33371.  
  33372. > It was originally set to 0 but I set it to 16 to not terminate calls 
  33373. > on the modems.  I was not aware of the Munich card on the netserver 
  33374. > was what controlled the calls, I just assumed that the ARC would 
  33375. > handle it.
  33376. > 
  33377. > Anyway, I set it to 0 with no help.
  33378.  
  33379. What is the pbus setting set to?
  33380.  
  33381. Do a show pbus set 
  33382. on the hiper arc.
  33383.  
  33384.  
  33385. > 
  33386. > All ports are hitting radius as port1.
  33387. > 
  33388. When you say port1 Guess you are talking about the NAS port - this 
  33389. setting depends on the pbus setting that you have on the hiper arc.  The 
  33390. default is 
  33391.  
  33392.  sh pbus set
  33393. PBUS SETTINGS
  33394. Reported Base :1
  33395. Port Density  :256
  33396.  
  33397. So the first port reported to radius would be 257 and so on.
  33398.  
  33399. but you can change this also
  33400.  
  33401. krish
  33402.  
  33403. > Any other suggestions?
  33404. > 
  33405. > 
  33406. > 
  33407. > 
  33408. > -----Original Message-----
  33409. > From: Jeff Mcadams [mailto:jeffm@iglou.com]
  33410. > Sent: Saturday, March 27, 1999 8:17 AM
  33411. > To: usr-tc@lists.xmission.com
  33412. > Subject: Re: (usr-tc) All Calls Showing Port 1 in radius
  33413. > 
  33414. > 
  33415. > Thus spake Sean Herr
  33416. > >I have a chassis on PRI's with Quad's and a ARC. All ports numbers are
  33417. > >hitting Radius as port 1.  My other chassis did this until I upped the
  33418. > >code to 4.1.59 and did a reboot.  I have done the same on this one with
  33419. > >no luck.
  33420. > 
  33421. > >If I pop in the Netserver card all is fine.
  33422. > 
  33423. > >My GW Slot is 16 
  33424. > 
  33425. > That's a problem.  The GW slot being set to 16 indicates to the PRI card
  33426. > that the card in slot 16 is supposed to terminate the ISDN calls.  The
  33427. > Arc can't terminate ISDN calls though, only the Munich card on the
  33428. > NETServer can do that.  Set the ISDN GW slot to 0 and that could very
  33429. > likely help.
  33430. > 
  33431. > >and the calls still terminate on the modems, even after the reboot.
  33432. > >When I pop in the Netserver, calls are handled by the Netserver card.
  33433. > 
  33434. > >The thing that is even more confusing is that the port numbers should
  33435. > >start on slot 2 which would actually be port 25????
  33436. > 
  33437. > Actually, it would be 257.  The Arc reserves 256 port numbers for each
  33438. > slot in anticipation of higher density cards down the road.
  33439. > -- 
  33440. > Jeff McAdams                            Email: jeffm@iglou.com
  33441. > Head Network Administrator              Voice: (502) 966-3848
  33442. > IgLou Internet Services                        (800) 436-4456
  33443. > 
  33444. > -
  33445. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33446. >  with "unsubscribe usr-tc" in the body of the message.
  33447. >  For information on digests or retrieving files and old messages send
  33448. >  "help" to the same address.  Do not use quotes in your message.
  33449. > 
  33450. > -
  33451. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33452. >  with "unsubscribe usr-tc" in the body of the message.
  33453. >  For information on digests or retrieving files and old messages send
  33454. >  "help" to the same address.  Do not use quotes in your message.
  33455. > 
  33456.  
  33457. -
  33458.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33459.  with "unsubscribe usr-tc" in the body of the message.
  33460.  For information on digests or retrieving files and old messages send
  33461.  "help" to the same address.  Do not use quotes in your message.
  33462.  
  33463.  
  33464. -------------------------------------------------------------------------------
  33465.  
  33466. From: Brian <signal@shreve.net>
  33467. Subject: Re: (usr-tc) Reply message
  33468. Date: 27 Mar 1999 19:37:10 -0600 (EST)
  33469.  
  33470. > So when the user dials in he/she will see normal ppp connections but in 
  33471. > effect the user connection will be terminated on HiPer arc 2.  which is a 
  33472. > internal intranet.
  33473.  
  33474. Can't you just term the user on eth:2 of the same arc and make that an
  33475. internal network?
  33476. > 
  33477. > regards
  33478. > 
  33479. > krish
  33480.  
  33481. Brian Feeny (BF304)     signal@shreve.net   
  33482. 318-222-2638 x 109    http://www.shreve.net/~signal      
  33483. Network Administrator   ShreveNet Inc. (ASN 11881)           
  33484.  
  33485.  
  33486. -
  33487.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33488.  with "unsubscribe usr-tc" in the body of the message.
  33489.  For information on digests or retrieving files and old messages send
  33490.  "help" to the same address.  Do not use quotes in your message.
  33491.  
  33492.  
  33493. -------------------------------------------------------------------------------
  33494.  
  33495. From: Tatai SV Krishnan <tkrishna@bubba.ae.usr.com>
  33496. Subject: Re: (usr-tc) Reply message
  33497. Date: 27 Mar 1999 20:11:43 -0600 (CST)
  33498.  
  33499. On Sat, 27 Mar 1999, Brian wrote:
  33500.  
  33501. > > So when the user dials in he/she will see normal ppp connections but in 
  33502. > > effect the user connection will be terminated on HiPer arc 2.  which is a 
  33503. > > internal intranet.
  33504. > 
  33505. > Can't you just term the user on eth:2 of the same arc and make that an
  33506. > internal network?
  33507.  
  33508. You can - When we first did the setup the IEA feature was not present in 
  33509. the hiper arc.  Come to think of it now yes you can.
  33510.  
  33511. krish
  33512.  
  33513.  
  33514. > > 
  33515. > > regards
  33516. > > 
  33517. > > krish
  33518. > 
  33519. > -----------------------------------------------------
  33520. > Brian Feeny (BF304)     signal@shreve.net   
  33521. > 318-222-2638 x 109    http://www.shreve.net/~signal      
  33522. > Network Administrator   ShreveNet Inc. (ASN 11881)           
  33523. > 
  33524. > 
  33525. > -
  33526. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33527. >  with "unsubscribe usr-tc" in the body of the message.
  33528. >  For information on digests or retrieving files and old messages send
  33529. >  "help" to the same address.  Do not use quotes in your message.
  33530. > 
  33531.  
  33532. -
  33533.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33534.  with "unsubscribe usr-tc" in the body of the message.
  33535.  For information on digests or retrieving files and old messages send
  33536.  "help" to the same address.  Do not use quotes in your message.
  33537.  
  33538.  
  33539. -------------------------------------------------------------------------------
  33540.  
  33541. From: Charles Sprickman <spork@inch.com>
  33542. Subject: Re: (usr-tc) Reply message
  33543. Date: 27 Mar 1999 22:12:25 -0500 (EST)
  33544.  
  33545. It can be really simple if you have IEA.  From what I understand, IEA can
  33546. basically throw people at a different gateway.  Make the gateway a small
  33547. box that sits at your pop.  Run a web and pop server.  The POP server is
  33548. could be "DPOP" (a dummy popper that just returns an error message saying
  33549. 'pay your bill') and the web server has a page stating that the account is
  33550. delinquent.  With either FreeBSD (or your os of choice) you simply
  33551. configure both of these as "transparent" proxies.  No matter what the
  33552. person tries to do, the request is caught by the web server...
  33553.  
  33554. Charles
  33555.  
  33556. -- 
  33557. =-----------------=                                        = 
  33558. | Charles Sprickman                       Internet Channel |
  33559. | INCH System Administration Team         (212)243-5200    |
  33560. | spork@inch.com                          access@inch.com  |
  33561. =                                         =----------------=
  33562.  
  33563. On Sat, 27 Mar 1999, Tatai SV Krishnan wrote:
  33564.  
  33565. > On Sat, 27 Mar 1999, Brian wrote:
  33566. > 
  33567. > > > So when the user dials in he/she will see normal ppp connections but in 
  33568. > > > effect the user connection will be terminated on HiPer arc 2.  which is a 
  33569. > > > internal intranet.
  33570. > > 
  33571. > > Can't you just term the user on eth:2 of the same arc and make that an
  33572. > > internal network?
  33573. > 
  33574. > You can - When we first did the setup the IEA feature was not present in 
  33575. > the hiper arc.  Come to think of it now yes you can.
  33576. > 
  33577. > krish
  33578. > 
  33579. > 
  33580. > > > 
  33581. > > > regards
  33582. > > > 
  33583. > > > krish
  33584. > > 
  33585. > > -----------------------------------------------------
  33586. > > Brian Feeny (BF304)     signal@shreve.net   
  33587. > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  33588. > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  33589. > > 
  33590. > > 
  33591. > > -
  33592. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33593. > >  with "unsubscribe usr-tc" in the body of the message.
  33594. > >  For information on digests or retrieving files and old messages send
  33595. > >  "help" to the same address.  Do not use quotes in your message.
  33596. > > 
  33597. > 
  33598. > -
  33599. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33600. >  with "unsubscribe usr-tc" in the body of the message.
  33601. >  For information on digests or retrieving files and old messages send
  33602. >  "help" to the same address.  Do not use quotes in your message.
  33603. > 
  33604.  
  33605.  
  33606. -
  33607.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33608.  with "unsubscribe usr-tc" in the body of the message.
  33609.  For information on digests or retrieving files and old messages send
  33610.  "help" to the same address.  Do not use quotes in your message.
  33611.  
  33612.  
  33613. -------------------------------------------------------------------------------
  33614.  
  33615. From: Brian <signal@shreve.net>
  33616. Subject: Re: (usr-tc) Reply message
  33617. Date: 27 Mar 1999 21:58:50 -0600 (EST)
  33618.  
  33619. On Sat, 27 Mar 1999, Charles Sprickman wrote:
  33620.  
  33621. > It can be really simple if you have IEA.  From what I understand, IEA can
  33622. > basically throw people at a different gateway.  Make the gateway a small
  33623. > box that sits at your pop.  Run a web and pop server.  The POP server is
  33624. > could be "DPOP" (a dummy popper that just returns an error message saying
  33625. > 'pay your bill') and the web server has a page stating that the account is
  33626. > delinquent.  With either FreeBSD (or your os of choice) you simply
  33627. > configure both of these as "transparent" proxies.  No matter what the
  33628. > person tries to do, the request is caught by the web server...
  33629.  
  33630.  
  33631. You said, "sits at your pop".  What if you have 20 pops?  IEA, is cool,
  33632. and I use it for Xstop, but the problem with VPN-Neighbor, is that it
  33633. needs that gateway to be directly reachable, which makes it hard to do for
  33634. a central gateway.
  33635.  
  33636. I am wondering if actually creating a l2tp/pptp tunnel might be a better
  33637. way, then all pops could link back to one central machine.
  33638.  
  33639. I am using VPN-Neighbor for our Xstop users, to take them to an alternate
  33640. gateway.  The xstop box is hanging off the same /24 as the arc's, so this
  33641. is not a problem.  But now in our pops we have arc's which are on a
  33642. different /24 than our xstop box and also across a router/serial link.
  33643.  
  33644. Now, I suppose a simple VPN-Neighbor statment would work, if the routes
  33645. for the network the xstop box or webserver in this case, were sent to the
  33646. pop via routing protocols.  To do this though would mean redistributing
  33647. ospf routes into rip which is something I am trying to avoid.  Right now,
  33648. we take routes from the arc's at the pops (ripv2) and distribute them into
  33649. ospf to talk back to our border and our lan.  What would need to be done,
  33650. is also the reverse, taking the routes from the lan (xstop, webserver etc)
  33651. and distrbuting them into rip from ospf.  Then you end up with:
  33652.  
  33653. ospf--->rip
  33654. rip---->ospf
  33655.  
  33656.  
  33657. which can get ugly fast without some smart redistribution filters.  And if
  33658. anyone has a sample redistrubiton filter for two way ospf<--->rip, I would
  33659. really appreciate a copy, just so I can envision it.  When your just
  33660. redistributing rip into ospf, and not the reverse also, you don't even
  33661. really need a filter since their is no loop.
  33662.  
  33663. > 
  33664. > Charles
  33665. > 
  33666. > -- 
  33667. > =-----------------=                                        = 
  33668. > | Charles Sprickman                       Internet Channel |
  33669. > | INCH System Administration Team         (212)243-5200    |
  33670. > | spork@inch.com                          access@inch.com  |
  33671. > =                                         =----------------=
  33672. > 
  33673. > On Sat, 27 Mar 1999, Tatai SV Krishnan wrote:
  33674. > 
  33675. > > On Sat, 27 Mar 1999, Brian wrote:
  33676. > > 
  33677. > > > > So when the user dials in he/she will see normal ppp connections but in 
  33678. > > > > effect the user connection will be terminated on HiPer arc 2.  which is a 
  33679. > > > > internal intranet.
  33680. > > > 
  33681. > > > Can't you just term the user on eth:2 of the same arc and make that an
  33682. > > > internal network?
  33683. > > 
  33684. > > You can - When we first did the setup the IEA feature was not present in 
  33685. > > the hiper arc.  Come to think of it now yes you can.
  33686. > > 
  33687. > > krish
  33688. > > 
  33689. > > 
  33690. > > > > 
  33691. > > > > regards
  33692. > > > > 
  33693. > > > > krish
  33694. > > > 
  33695. > > > -----------------------------------------------------
  33696. > > > Brian Feeny (BF304)     signal@shreve.net   
  33697. > > > 318-222-2638 x 109    http://www.shreve.net/~signal      
  33698. > > > Network Administrator   ShreveNet Inc. (ASN 11881)           
  33699. > > > 
  33700. > > > 
  33701. > > > -
  33702. > > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33703. > > >  with "unsubscribe usr-tc" in the body of the message.
  33704. > > >  For information on digests or retrieving files and old messages send
  33705. > > >  "help" to the same address.  Do not use quotes in your message.
  33706. > > > 
  33707. > > 
  33708. > > -
  33709. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33710. > >  with "unsubscribe usr-tc" in the body of the message.
  33711. > >  For information on digests or retrieving files and old messages send
  33712. > >  "help" to the same address.  Do not use quotes in your message.
  33713. > > 
  33714. > 
  33715.  
  33716. Brian Feeny (BF304)     signal@shreve.net   
  33717. 318-222-2638 x 109    http://www.shreve.net/~signal      
  33718. Network Administrator   ShreveNet Inc. (ASN 11881)           
  33719.  
  33720.  
  33721.  
  33722. -
  33723.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33724.  with "unsubscribe usr-tc" in the body of the message.
  33725.  For information on digests or retrieving files and old messages send
  33726.  "help" to the same address.  Do not use quotes in your message.
  33727.  
  33728.  
  33729. -------------------------------------------------------------------------------
  33730.  
  33731. From: Sean Herr <Sean@YNC.NET>
  33732. Subject: RE: (usr-tc) All Calls Showing Port 1 in radius
  33733. Date: 28 Mar 1999 10:41:28 -0600
  33734.  
  33735. PBUS SETTINGS
  33736. Reported Base :1
  33737. Port Density  :24
  33738.  
  33739. Sean Herr
  33740. @YourNET Connection, Inc.
  33741. 847-524-3910
  33742. http://www.ync.net 
  33743.  
  33744.  
  33745. -----Original Message-----
  33746. Sent: Saturday, March 27, 1999 12:56 PM
  33747. Cc: 'usr-tc@lists.xmission.com'
  33748.  
  33749.  
  33750. On Sat, 27 Mar 1999, Sean Herr wrote:
  33751.  
  33752. > It was originally set to 0 but I set it to 16 to not terminate calls 
  33753. > on the modems.  I was not aware of the Munich card on the netserver 
  33754. > was what controlled the calls, I just assumed that the ARC would 
  33755. > handle it.
  33756. > 
  33757. > Anyway, I set it to 0 with no help.
  33758.  
  33759. What is the pbus setting set to?
  33760.  
  33761. Do a show pbus set 
  33762. on the hiper arc.
  33763.  
  33764.  
  33765. > 
  33766. > All ports are hitting radius as port1.
  33767. > 
  33768. When you say port1 Guess you are talking about the NAS port - this 
  33769. setting depends on the pbus setting that you have on the hiper arc.  The 
  33770. default is 
  33771.  
  33772.  sh pbus set
  33773. PBUS SETTINGS
  33774. Reported Base :1
  33775. Port Density  :256
  33776.  
  33777. So the first port reported to radius would be 257 and so on.
  33778.  
  33779. but you can change this also
  33780.  
  33781. krish
  33782.  
  33783. > Any other suggestions?
  33784. > 
  33785. > 
  33786. > 
  33787. > 
  33788. > -----Original Message-----
  33789. > From: Jeff Mcadams [mailto:jeffm@iglou.com]
  33790. > Sent: Saturday, March 27, 1999 8:17 AM
  33791. > To: usr-tc@lists.xmission.com
  33792. > Subject: Re: (usr-tc) All Calls Showing Port 1 in radius
  33793. > 
  33794. > 
  33795. > Thus spake Sean Herr
  33796. > >I have a chassis on PRI's with Quad's and a ARC. All ports numbers are
  33797. > >hitting Radius as port 1.  My other chassis did this until I upped the
  33798. > >code to 4.1.59 and did a reboot.  I have done the same on this one with
  33799. > >no luck.
  33800. > 
  33801. > >If I pop in the Netserver card all is fine.
  33802. > 
  33803. > >My GW Slot is 16 
  33804. > 
  33805. > That's a problem.  The GW slot being set to 16 indicates to the PRI card
  33806. > that the card in slot 16 is supposed to terminate the ISDN calls.  The
  33807. > Arc can't terminate ISDN calls though, only the Munich card on the
  33808. > NETServer can do that.  Set the ISDN GW slot to 0 and that could very
  33809. > likely help.
  33810. > 
  33811. > >and the calls still terminate on the modems, even after the reboot.
  33812. > >When I pop in the Netserver, calls are handled by the Netserver card.
  33813. > 
  33814. > >The thing that is even more confusing is that the port numbers should
  33815. > >start on slot 2 which would actually be port 25????
  33816. > 
  33817. > Actually, it would be 257.  The Arc reserves 256 port numbers for each
  33818. > slot in anticipation of higher density cards down the road.
  33819. > -- 
  33820. > Jeff McAdams                            Email: jeffm@iglou.com
  33821. > Head Network Administrator              Voice: (502) 966-3848
  33822. > IgLou Internet Services                        (800) 436-4456
  33823. > 
  33824. > -
  33825. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33826. >  with "unsubscribe usr-tc" in the body of the message.
  33827. >  For information on digests or retrieving files and old messages send
  33828. >  "help" to the same address.  Do not use quotes in your message.
  33829. > 
  33830. > -
  33831. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33832. >  with "unsubscribe usr-tc" in the body of the message.
  33833. >  For information on digests or retrieving files and old messages send
  33834. >  "help" to the same address.  Do not use quotes in your message.
  33835. > 
  33836.  
  33837. -
  33838.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33839.  with "unsubscribe usr-tc" in the body of the message.
  33840.  For information on digests or retrieving files and old messages send
  33841.  "help" to the same address.  Do not use quotes in your message.
  33842.  
  33843. -
  33844.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33845.  with "unsubscribe usr-tc" in the body of the message.
  33846.  For information on digests or retrieving files and old messages send
  33847.  "help" to the same address.  Do not use quotes in your message.
  33848.  
  33849.  
  33850. -------------------------------------------------------------------------------
  33851.  
  33852. From: Info Perthlink <info@twistedpair.perthlink.net>
  33853. Subject: (usr-tc) Radius Server - Seek (Authentication) AAA
  33854. Date: 29 Mar 1999 01:51:31 +0800 (WST)
  33855.  
  33856.  
  33857.  
  33858. Hi Every one, can some one help me with the Basics of Authentication?
  33859.  
  33860. I will need the following options to meet:
  33861. - Be able to cut out users when the system gets busy (Busy hour kick) ( is it done by radius)?
  33862. - Downloaded megabytes
  33863. - Able to generate a report from web (i need Perl?) or MySQL?
  33864. - Double Connection Deny (and email the user about it)
  33865. - Billing (Automatic emailing and Print overdue accounts)
  33866.  
  33867. Either i need to choose Merit AAA (free) -  Cisteron radius - Radiusd (lucent) 
  33868. And either i need aditional scripts. Perl or Mysql are those i thinking
  33869. will be the answer
  33870.  
  33871. * additional q?
  33872.     MySQL is a good Database., Can it have encrypted passwords? is it
  33873. suitable for radius as an isp? Thanks.
  33874.  
  33875. Jelle Hempenius
  33876.  
  33877. Perthlink.net (net)
  33878. aeon.net.au   (isp)
  33879. paradox.net.au(isp)
  33880.  
  33881.  
  33882.  
  33883. -
  33884.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33885.  with "unsubscribe usr-tc" in the body of the message.
  33886.  For information on digests or retrieving files and old messages send
  33887.  "help" to the same address.  Do not use quotes in your message.
  33888.  
  33889.  
  33890. -------------------------------------------------------------------------------
  33891.  
  33892. From: Brian <signal@shreve.net>
  33893. Subject: Re: (usr-tc) Radius Server - Seek (Authentication) AAA
  33894. Date: 28 Mar 1999 22:18:46 -0600 (EST)
  33895.  
  33896. On Mon, 29 Mar 1999, Info Perthlink wrote:
  33897.  
  33898. > 
  33899. > 
  33900. > Hi Every one, can some one help me with the Basics of Authentication?
  33901. > 
  33902. > I will need the following options to meet:
  33903. > - Be able to cut out users when the system gets busy (Busy hour kick) ( is it done by radius)?
  33904.  
  33905. TSMON can do this www.tsmon.com
  33906.  
  33907. > - Downloaded megabytes
  33908.  
  33909. all radius detail files should contain the amount of data transferred
  33910.  
  33911. > - Able to generate a report from web (i need Perl?) or MySQL?
  33912.  
  33913. man billing packages can do this, such as platypus, www.boardtown.com
  33914.  
  33915. > - Double Connection Deny (and email the user about it)
  33916. > - Billing (Automatic emailing and Print overdue accounts)
  33917.  
  33918. TSMON once again
  33919.  
  33920. > 
  33921. > Either i need to choose Merit AAA (free) -  Cisteron radius - Radiusd (lucent) 
  33922. > And either i need aditional scripts. Perl or Mysql are those i thinking
  33923. > will be the answer
  33924. > 
  33925. > * additional q?
  33926. >     MySQL is a good Database., Can it have encrypted passwords? is it
  33927. > suitable for radius as an isp? Thanks.
  33928. > 
  33929.  
  33930.  
  33931. brian
  33932.  
  33933.  
  33934. > Jelle Hempenius
  33935. > 
  33936. > Perthlink.net (net)
  33937. > aeon.net.au   (isp)
  33938. > paradox.net.au(isp)
  33939. > 
  33940. > 
  33941. > 
  33942. > -
  33943. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33944. >  with "unsubscribe usr-tc" in the body of the message.
  33945. >  For information on digests or retrieving files and old messages send
  33946. >  "help" to the same address.  Do not use quotes in your message.
  33947. > 
  33948.  
  33949. Brian Feeny (BF304)     signal@shreve.net   
  33950. 318-222-2638 x 109    http://www.shreve.net/~signal      
  33951. Network Administrator   ShreveNet Inc. (ASN 11881)           
  33952.  
  33953.  
  33954. -
  33955.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  33956.  with "unsubscribe usr-tc" in the body of the message.
  33957.  For information on digests or retrieving files and old messages send
  33958.  "help" to the same address.  Do not use quotes in your message.
  33959.  
  33960.  
  33961. -------------------------------------------------------------------------------
  33962.  
  33963. From: "C Thompson" <cthompson@wingnet.net>
  33964. Subject: (usr-tc) how to route a subnet on Hiper ARC / 3COM / TC
  33965. Date: 29 Mar 1999 14:01:43 -0500
  33966.  
  33967. I tried to get info for a few months off and on regarding how to do this.  
  33968. Finally, after some trial and error, and using a customer's connection 
  33969. (with permission) to test, I have found out how to route a network to a 
  33970. customer's connection.
  33971.  
  33972. Before using RADIUS to do it, I had to set a static route in each Hiper 
  33973. ARC (which stunk).
  33974.  
  33975. This is an example of how to route a network / subnet to a customer's 
  33976. static IP address.  This is using Radiator RADIUS and a 3COM Hiper 
  33977. Arc.  Replace all IPs and xxx with valid numbers for your network.  Please 
  33978. note that your 'dictionary' file may have slightly different syntax for some 
  33979. of the reply items (e.g. Framed-Address instead of Framed-IP-Address).
  33980.  
  33981. user        Auth-Type = System, Simultaneous-Use = 2
  33982.         Framed-Protocol = PPP,
  33983.         Service-Type = Framed-User,
  33984.         Framed-IP-Address = 206.30.215.xxx,
  33985. #    customer's static IP address above
  33986.         Framed-Netmask = 255.255.255.255,
  33987.         Framed-Route = "206.30.xxx.0/24 206.30.215.xxx 1",
  33988. #    network to be routed, netmask, static IP of customer, metric
  33989.         Framed-Routing = None,
  33990. #    can be changed to valid entries as defined in the dictionary
  33991.         Routing-Protocol = Rip1,
  33992. #    can be Rip1 or Rip2
  33993.         Idle-Timeout = 0
  33994. #    don't drop dedicated customers...
  33995.  
  33996. It will also work with the setting below.
  33997.  
  33998. #               Framed-Routing = Broadcast-Listen,
  33999.  
  34000. If Framed-Routing is set to anything besides "None," this will affect the
  34001. HARM, Networks, IP Networks, username-ip-.... settings.  In other words,
  34002. if set to Broadcast-Listen, then the customer's network will have those
  34003. settings showing up in their network settings on the Hiper ARC.
  34004.  
  34005. At this writing, I haven't tried Rip2 yet, but it should work.  Rip1 is sending the route to the other Hiper ARCs.
  34006.  
  34007. I hope this helps someone.  If it does, please send me an e-mail and let 
  34008. me know.
  34009.  
  34010. Have a great day,
  34011.  
  34012.  
  34013. Craig Thompson
  34014. WingNET Internet Services,
  34015. P.O. Box 3000 // Cleveland, TN 37320-3000
  34016. 423-559-LINK (v)  423-559-5444 (f)
  34017. http://www.wingnet.net
  34018.  
  34019. Classic - a book which people praise and don't read.
  34020.  
  34021.  
  34022. -
  34023.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34024.  with "unsubscribe usr-tc" in the body of the message.
  34025.  For information on digests or retrieving files and old messages send
  34026.  "help" to the same address.  Do not use quotes in your message.
  34027.  
  34028.  
  34029. -------------------------------------------------------------------------------
  34030.  
  34031. From: "Randy Cosby" <dcosby@infowest.com>
  34032. Subject: RE: (usr-tc) Radius Server - Seek (Authentication) AAA
  34033. Date: 29 Mar 1999 12:24:50 -0700
  34034.  
  34035. I use and like Radiator (http://www.open.com.au/radiator).  It has all the
  34036. code for Mysql built into it, as well as dual-login checking.  It's easy to
  34037. get any report you need if you log to Mysql.  Throw in some PHP
  34038. (http://www.php.net), and you can create all kinds of web-based
  34039. administration and reporting tools.
  34040.  
  34041. Randy
  34042.  
  34043.  
  34044. -
  34045.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34046.  with "unsubscribe usr-tc" in the body of the message.
  34047.  For information on digests or retrieving files and old messages send
  34048.  "help" to the same address.  Do not use quotes in your message.
  34049.  
  34050.  
  34051. -------------------------------------------------------------------------------
  34052.  
  34053. From: "Mike Hamrich" <mikeh@drfast.net>
  34054. Subject: Re: (usr-tc) modem configs
  34055. Date: 26 Mar 1999 17:49:15 -0500
  34056.  
  34057. Any news about making Sportsters that use to connect fine in X2, 46-48K
  34058. range connect above 28K with the latest v.90 TC code?
  34059.  
  34060. I am starting tonight with telling a few tech-aware users how to disable
  34061. v.90 on thier modems.
  34062.  
  34063.  
  34064. -----Original Message-----
  34065.  
  34066.  
  34067. >On Mon, 22 Mar 1999, Mike Andrews wrote:
  34068. >
  34069. >> I'm also having a problem that maybe someone else can help with here. The
  34070. >> above init string doesn't disable v.90/x2 correctly on the Quads. (Works
  34071. >> great on DSP's.)  If I call in with a Courier, it chokes during the
  34072. >> handshake -- it sounds as if one side is attempting x2 (not v.90) and the
  34073. >> other side is trying v.34.  (It dies during the line frequency probe
  34074. >> sequence, in other words.)  If I call in with an LT Winmodem it seems to
  34075. >> be more or less OK.
  34076. >>
  34077. >> So...  What's the *correct* AT sequence to completely kill all 56K
  34078. >> modulations on a Quad modem and leave v.34 intact?
  34079. >
  34080. >If anyone cares, I fixed this by disabling all 3 x2 modes -- client,
  34081. >server, and symmetric.  Apparently disabling just server wasn't good
  34082. >enough for the Quads.  Go figure...
  34083. >
  34084. >
  34085. >Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  34086. >mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  34087. >Microsoft operating system is like a dog without a brick tied to its head."
  34088. >
  34089. >
  34090. >-
  34091. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34092. > with "unsubscribe usr-tc" in the body of the message.
  34093. > For information on digests or retrieving files and old messages send
  34094. > "help" to the same address.  Do not use quotes in your message.
  34095.  
  34096. -
  34097.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34098.  with "unsubscribe usr-tc" in the body of the message.
  34099.  For information on digests or retrieving files and old messages send
  34100.  "help" to the same address.  Do not use quotes in your message.
  34101.  
  34102.  
  34103. -------------------------------------------------------------------------------
  34104.  
  34105. From: "System Administrator" <root@wingnet.net>
  34106. Subject: Re: (usr-tc) 3COM Chassis and Radiator Reply-Message not working
  34107. Date: 26 Mar 1999 10:09:07 -0500
  34108.  
  34109. Will you please send me a copy once you do.  I'm sure the folks on the 
  34110. Radiator mailing list would be interested as well.  I'm having to 
  34111. juggle back and forth between lists sometimes to get info...  Thanks 
  34112. for your help.
  34113.  
  34114. > I have to dig through my notes - but sure sometime this week I will come 
  34115. > up with a write up and desing for this.
  34116. > 
  34117. > krish
  34118.  
  34119. WingNET System Administrator
  34120. 423-559-LINK (v)
  34121. 423-559-5444 (f)
  34122.  
  34123. -
  34124.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34125.  with "unsubscribe usr-tc" in the body of the message.
  34126.  For information on digests or retrieving files and old messages send
  34127.  "help" to the same address.  Do not use quotes in your message.
  34128.  
  34129.  
  34130. -------------------------------------------------------------------------------
  34131.  
  34132. From: "Terry Kennedy" <terry@olypen.com>
  34133. Subject: (usr-tc) Code base
  34134. Date: 29 Mar 1999 12:00:14 -0800
  34135.  
  34136. We are running 1.2.59 on our DSP's. Any good reason
  34137. to upgrade to 1.2.43? It is an upgrade insn't it?
  34138.  
  34139.  
  34140. -
  34141.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34142.  with "unsubscribe usr-tc" in the body of the message.
  34143.  For information on digests or retrieving files and old messages send
  34144.  "help" to the same address.  Do not use quotes in your message.
  34145.  
  34146.  
  34147. -------------------------------------------------------------------------------
  34148.  
  34149. From: Jeff Mcadams <jeffm@iglou.com>
  34150. Subject: (usr-tc) Control over MPIP
  34151. Date: 29 Mar 1999 15:04:10 -0500 (EST)
  34152.  
  34153. OK, I've been playing around a bit doing my darndest to work around MPIP
  34154. brokenness.
  34155.  
  34156. At this point I've gone to using SNMP to reset the MPIP server state in
  34157. the MPIP server.  This has two benefits...1) the MPIP server is only
  34158. offline for approximately 5 seconds (long enough for a couple of
  34159. snmpsets and snmpgets to the MPIP server) rather than the 2 minutes or
  34160. so that resulted from a full HiPer Arc reboot (man those things take a
  34161. long time to boot up), and 2) it allows me to put the MPIP server on a
  34162. HiPer Arc that is actively taking calls since I don't have to reboot the
  34163. whole thing resulting in disconnected calls.  This allows me to replace
  34164. one more NETServer without further expenditure.  Neither of these two
  34165. things results in huge improvements, but I can deal with incremental if
  34166. quantum improvements aren't possible.
  34167.  
  34168. With further exploration into the SNMP information stored in the HiPer
  34169. Arcs, it seems that all of the MPIP server information (bundles,
  34170. userids, EDO types and values, bundle owners, link owners, etc.) are all
  34171. available through MPIP.  This is a good thing.  :)  However, attempts to
  34172. alter, delete, or anything like that have failed.  This *could* be
  34173. because I'm still pretty much a newbie at SNMP, but I don't think so.
  34174.  
  34175. I'm looking at using SNMP for all of this because it is considerably
  34176. more scriptable than dealing with the CLI.
  34177.  
  34178. My questions come down to: 1)  is it possible to alter the data that the
  34179. MPIP server has in its data directly...ie, without altering it on the
  34180. client side and letting the client transmit this information to the MPIP
  34181. server?
  34182.  
  34183. I ask this because we still have NETServers in service and altering the
  34184. MPIP data from the client side on the NETServers is not possible.  Also,
  34185. because the problem with the MPIP protocol as a whole seems to be that
  34186. the MPIP server is either missing, or mishandling deregistration
  34187. request(s) from clients....the clients think the bundle is deregistered,
  34188. but the server doesn't actually deregister it (from what I can tell
  34189. anyway).
  34190.  
  34191. 2)  if the answer to the above question is that its not possible...can
  34192. it be made to be possible?  (call this a feature request I guess).
  34193. Since MPIP is unreliable at best at the moment, the ability to manually
  34194. go in and clean out the phantom, cruft MPIP bundles out of the MPIP
  34195. server would be useful as a possible workaround.  The ability to do this
  34196. through SNMP would be most helpful as well (again, for scriptability
  34197. reasons).
  34198. -- 
  34199. Jeff McAdams                            Email: jeffm@iglou.com
  34200. Head Network Administrator              Voice: (502) 966-3848
  34201. IgLou Internet Services                        (800) 436-4456
  34202.  
  34203. -
  34204.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34205.  with "unsubscribe usr-tc" in the body of the message.
  34206.  For information on digests or retrieving files and old messages send
  34207.  "help" to the same address.  Do not use quotes in your message.
  34208.  
  34209.  
  34210. -------------------------------------------------------------------------------
  34211.  
  34212. From: Jeff Mcadams <jeffm@iglou.com>
  34213. Subject: (usr-tc) Another quick q:
  34214. Date: 29 Mar 1999 17:01:55 -0500 (EST)
  34215.  
  34216. OK...still getting a bit acclimated to the Arcs...
  34217.  
  34218. Perhaps I'm missing an easy one here.
  34219.  
  34220. Is there any way to see where a tunneled link is tunneled *from* on a
  34221. HiPer Arc?
  34222.  
  34223. Ie, on the NETServers you can do a show bun to see the MP bundle head,
  34224. and then do a show netports to see which NAS the other links of the
  34225. bundle are connecting from.  This is very convenient since it lets you
  34226. trace back from a traceroute to the bundle head, and then from the
  34227. bundle head, see where the other links are connected.
  34228.  
  34229. I know you can do a list mpip links on the MPIP server to show where all
  34230. the links are connected, but if you do a lot of MPIP, that can get
  34231. rather hairy to see where everything is matching up.
  34232.  
  34233. There's also a list tunnel connections on the bundle head that shows the
  34234. tunnel interfaces and usernames, but no way that I found to be able to
  34235. match that up to the source of the tunnel.
  34236. -- 
  34237. Jeff McAdams                            Email: jeffm@iglou.com
  34238. Head Network Administrator              Voice: (502) 966-3848
  34239. IgLou Internet Services                        (800) 436-4456
  34240.  
  34241. -
  34242.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34243.  with "unsubscribe usr-tc" in the body of the message.
  34244.  For information on digests or retrieving files and old messages send
  34245.  "help" to the same address.  Do not use quotes in your message.
  34246.  
  34247.  
  34248. -------------------------------------------------------------------------------
  34249.  
  34250. From: usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox)
  34251. Subject: (usr-tc) New PRI rings busy. Any ideas? 
  34252. Date: 29 Mar 1999 21:55:08 -0500
  34253.  
  34254. Up until now we've used GTE for our PRI's setup as NI2. 
  34255. Our first CLEC PRI went in today on a PRI NIC/NAC with an 
  34256. existing GTE PRI already operating. e.Spire is showing we
  34257. have set the pri out of service locally, and all the lines
  34258. of course get the standard busy signal. I'm showing everything
  34259. looks good, except that no calls can get through. 
  34260.  
  34261. I'm showing D channel up, all DS0's In Service. The only 
  34262. difference between the GTE PRI's and the e.Spire PRI is NI2 
  34263. vs. 5ESS. I can put the GTE PRI on either port, set it to NI2,
  34264. and it fires right up. I can put the e.Spire PRI on either
  34265. port, set for NI2 or 5ESS, and it won't come up. I've tried 
  34266. changing the span to in service (option 17). I've also tried 
  34267. bringing up the rack with just the new PRI, and swapped the 
  34268. T1 interface card, still no go. Rebooting and power cycling 
  34269. along the way. B8ZS, ESF. Any ideas would be welcomed. 
  34270.  
  34271. Thanks,
  34272.   Steve Kinkaid
  34273.   Suncoast Networking 
  34274.  
  34275.  
  34276. -
  34277.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34278.  with "unsubscribe usr-tc" in the body of the message.
  34279.  For information on digests or retrieving files and old messages send
  34280.  "help" to the same address.  Do not use quotes in your message.
  34281.  
  34282.  
  34283. -------------------------------------------------------------------------------
  34284.  
  34285. From: Brian <signal@shreve.net>
  34286. Subject: Re: (usr-tc) New PRI rings busy. Any ideas? 
  34287. Date: 29 Mar 1999 21:03:12 -0600 (EST)
  34288.  
  34289. On Mon, 29 Mar 1999, Suncoast Networking USR Mailbox wrote:
  34290.  
  34291. > Up until now we've used GTE for our PRI's setup as NI2. 
  34292. > Our first CLEC PRI went in today on a PRI NIC/NAC with an 
  34293. > existing GTE PRI already operating. e.Spire is showing we
  34294. > have set the pri out of service locally, and all the lines
  34295. > of course get the standard busy signal. I'm showing everything
  34296. > looks good, except that no calls can get through. 
  34297.  
  34298. Are we talking HDM's or dual PRI cards here?
  34299.  
  34300. if hdm, check out 
  34301.  
  34302. chdev span
  34303. dis spnstats
  34304.  
  34305. show us the output
  34306.  
  34307. also dis atstat
  34308.  
  34309. > 
  34310. > I'm showing D channel up, all DS0's In Service. The only 
  34311. > difference between the GTE PRI's and the e.Spire PRI is NI2 
  34312. > vs. 5ESS. I can put the GTE PRI on either port, set it to NI2,
  34313. > and it fires right up. I can put the e.Spire PRI on either
  34314. > port, set for NI2 or 5ESS, and it won't come up. I've tried 
  34315.  
  34316. if on an hdm do:
  34317.  
  34318. chdev span
  34319. cmd svspcfg
  34320.  
  34321. > changing the span to in service (option 17). I've also tried 
  34322. > bringing up the rack with just the new PRI, and swapped the 
  34323. > T1 interface card, still no go. Rebooting and power cycling 
  34324. > along the way. B8ZS, ESF. Any ideas would be welcomed. 
  34325. > 
  34326.  
  34327. ok, sounds like dual PRI, its been a while since I have done anything with
  34328. that, but more than likely its a telco screwup since their isn't a whole
  34329. lot that really matters with PRI (b8zs, esf, switchtype).  How much
  34330. buildout are you running?  How far is the telco equipment from your tc?
  34331.  >
  34332. Thanks, >   Steve Kinkaid
  34333. >   Suncoast Networking 
  34334. > 
  34335. > 
  34336. > -
  34337. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34338. >  with "unsubscribe usr-tc" in the body of the message.
  34339. >  For information on digests or retrieving files and old messages send
  34340. >  "help" to the same address.  Do not use quotes in your message.
  34341. > 
  34342.  
  34343. Brian Feeny (BF304)     signal@shreve.net   
  34344. 318-222-2638 x 109    http://www.shreve.net/~signal      
  34345. Network Administrator   ShreveNet Inc. (ASN 11881)           
  34346.  
  34347.  
  34348. -
  34349.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34350.  with "unsubscribe usr-tc" in the body of the message.
  34351.  For information on digests or retrieving files and old messages send
  34352.  "help" to the same address.  Do not use quotes in your message.
  34353.  
  34354.  
  34355. -------------------------------------------------------------------------------
  34356.  
  34357. From: "Russ Miescke" <russm@powerweb.net>
  34358. Subject: (usr-tc) Ping Attacks?
  34359. Date: 29 Mar 1999 23:11:19 -0600
  34360.  
  34361. Are the Netserver cards susceptible to ping attacks?   If so which ones and
  34362. what is the command to filter against them?  I seem to be having a problem
  34363. that looks like the oob attack on an NT machine.  Throughput slows down to a
  34364. crawl and then just stops.  The Netserver card seems to freeze and must be
  34365. rebooted.
  34366. Russ Miescke
  34367. Power Web Connect
  34368.  
  34369.  
  34370.  
  34371. -
  34372.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34373.  with "unsubscribe usr-tc" in the body of the message.
  34374.  For information on digests or retrieving files and old messages send
  34375.  "help" to the same address.  Do not use quotes in your message.
  34376.  
  34377.  
  34378. -------------------------------------------------------------------------------
  34379.  
  34380. From: usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox)
  34381. Subject: Re: (usr-tc) New PRI rings busy. Any ideas? 
  34382. Date: 30 Mar 1999 00:40:31 -0500
  34383.  
  34384. Yes, this is a PRI NIC/NAC combo, not an HDM. I'm not sure 
  34385. what you mean by "how much" build out. The local loop goes 
  34386. to the local CO, which is only about 1000 yards from here. 
  34387. We have other PRI's out of there working fine. This new
  34388. Exchange Carrier and their switch is about 30 miles from
  34389. here. The Demarc/CPE is 10 feet from the racks. 
  34390.  
  34391. After following another suggestion I received of pulling just 
  34392. the PRI cards back and front, I'm getting an error repeated 
  34393. about 10 times after the PRI card boots of=
  34394.  
  34395. ERR:ucc_gen_error,ucc_null,bad event;,err:3
  34396.  
  34397. Does anyone know what that means? 
  34398.  
  34399. Thanks Again,
  34400.   Steve Kinkaid
  34401.   Suncoast Networking 
  34402.  
  34403. >
  34404. >> Up until now we've used GTE for our PRI's setup as NI2. 
  34405. >> Our first CLEC PRI went in today on a PRI NIC/NAC with an 
  34406. >> existing GTE PRI already operating. e.Spire is showing we
  34407. >> have set the pri out of service locally, and all the lines
  34408. >> of course get the standard busy signal. I'm showing everything
  34409. >> looks good, except that no calls can get through. 
  34410. >
  34411. >Are we talking HDM's or dual PRI cards here?
  34412. >
  34413. >if hdm, check out 
  34414. >
  34415. >chdev span
  34416. >dis spnstats
  34417. >
  34418. >show us the output
  34419. >
  34420. >also dis atstat
  34421. >
  34422. >> 
  34423. >> I'm showing D channel up, all DS0's In Service. The only 
  34424. >> difference between the GTE PRI's and the e.Spire PRI is NI2 
  34425. >> vs. 5ESS. I can put the GTE PRI on either port, set it to NI2,
  34426. >> and it fires right up. I can put the e.Spire PRI on either
  34427. >> port, set for NI2 or 5ESS, and it won't come up. I've tried 
  34428. >
  34429. >if on an hdm do:
  34430. >
  34431. >chdev span
  34432. >cmd svspcfg
  34433. >
  34434. >> changing the span to in service (option 17). I've also tried 
  34435. >> bringing up the rack with just the new PRI, and swapped the 
  34436. >> T1 interface card, still no go. Rebooting and power cycling 
  34437. >> along the way. B8ZS, ESF. Any ideas would be welcomed. 
  34438. >> 
  34439. >
  34440. >ok, sounds like dual PRI, its been a while since I have done anything with
  34441. >that, but more than likely its a telco screwup since their isn't a whole
  34442. >lot that really matters with PRI (b8zs, esf, switchtype).  How much
  34443. >buildout are you running?  How far is the telco equipment from your tc?
  34444. > >
  34445. >Thanks, >   Steve Kinkaid
  34446. >>   Suncoast Networking 
  34447. >> 
  34448. >> 
  34449. >> -
  34450. >>  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34451. >>  with "unsubscribe usr-tc" in the body of the message.
  34452. >>  For information on digests or retrieving files and old messages send
  34453. >>  "help" to the same address.  Do not use quotes in your message.
  34454. >> 
  34455. >
  34456. >-----------------------------------------------------
  34457. >Brian Feeny (BF304)     signal@shreve.net   
  34458. >318-222-2638 x 109    http://www.shreve.net/~signal      
  34459. >Network Administrator   ShreveNet Inc. (ASN 11881)           
  34460. >
  34461. >
  34462. >-
  34463. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34464. > with "unsubscribe usr-tc" in the body of the message.
  34465. > For information on digests or retrieving files and old messages send
  34466. > "help" to the same address.  Do not use quotes in your message.
  34467. >
  34468. >
  34469.  
  34470.  
  34471. -
  34472.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34473.  with "unsubscribe usr-tc" in the body of the message.
  34474.  For information on digests or retrieving files and old messages send
  34475.  "help" to the same address.  Do not use quotes in your message.
  34476.  
  34477.  
  34478. -------------------------------------------------------------------------------
  34479.  
  34480. From: usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox)
  34481. Subject: Re: (usr-tc) Ping Attacks?
  34482. Date: 30 Mar 1999 01:06:50 -0500
  34483.  
  34484. For what its worth, I block ICMP 8 at the firewall/router to all the 
  34485. netserver net0 IP's... I believe that Microsoft stopped the oob 
  34486. attacks against NT and 95 in a patch several months ago. Have you
  34487. tried the netstat command on the NT server to see what its talking 
  34488. to? 
  34489.  
  34490. Steve Kinkaid 
  34491. Suncoast Networking 
  34492.  
  34493. >Are the Netserver cards susceptible to ping attacks?   If so which ones and
  34494. >what is the command to filter against them?  I seem to be having a problem
  34495. >that looks like the oob attack on an NT machine.  Throughput slows down to a
  34496. >crawl and then just stops.  The Netserver card seems to freeze and must be
  34497. >rebooted.
  34498. >Russ Miescke
  34499. >Power Web Connect
  34500. >
  34501. >
  34502. >
  34503. >-
  34504. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34505. > with "unsubscribe usr-tc" in the body of the message.
  34506. > For information on digests or retrieving files and old messages send
  34507. > "help" to the same address.  Do not use quotes in your message.
  34508. >
  34509. >
  34510.  
  34511.  
  34512. -
  34513.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34514.  with "unsubscribe usr-tc" in the body of the message.
  34515.  For information on digests or retrieving files and old messages send
  34516.  "help" to the same address.  Do not use quotes in your message.
  34517.  
  34518.  
  34519. -------------------------------------------------------------------------------
  34520.  
  34521. From: Mike Andrews <mandrews@termfrost.org>
  34522. Subject: Re: (usr-tc) Ping Attacks?
  34523. Date: 30 Mar 1999 01:59:41 -0500 (EST)
  34524.  
  34525. I can't remember if they're vulnerable or not...  but there's at least
  34526. one other possible explanation for those symptoms: running out of RAM.
  34527. Do a "show mem" every so often and see if you're losing lots of ram over
  34528. the course of a few days.
  34529.  
  34530.  
  34531. Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort KY
  34532. mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without a
  34533. Microsoft operating system is like a dog without a brick tied to its head."
  34534.  
  34535. On Mon, 29 Mar 1999, Russ Miescke wrote:
  34536.  
  34537. > Are the Netserver cards susceptible to ping attacks?   If so which ones and
  34538. > what is the command to filter against them?  I seem to be having a problem
  34539. > that looks like the oob attack on an NT machine.  Throughput slows down to a
  34540. > crawl and then just stops.  The Netserver card seems to freeze and must be
  34541. > rebooted.
  34542. > Russ Miescke
  34543. > Power Web Connect
  34544. > 
  34545. > 
  34546. > 
  34547. > -
  34548. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34549. >  with "unsubscribe usr-tc" in the body of the message.
  34550. >  For information on digests or retrieving files and old messages send
  34551. >  "help" to the same address.  Do not use quotes in your message.
  34552. > 
  34553.  
  34554.  
  34555. -
  34556.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34557.  with "unsubscribe usr-tc" in the body of the message.
  34558.  For information on digests or retrieving files and old messages send
  34559.  "help" to the same address.  Do not use quotes in your message.
  34560.  
  34561.  
  34562. -------------------------------------------------------------------------------
  34563.  
  34564. From: "Russ Miescke" <russm@powerweb.net>
  34565. Subject: Re: (usr-tc) Ping Attacks?
  34566. Date: 30 Mar 1999 02:29:01 -0600
  34567.  
  34568. I thought about the ram problem.  Doesn't seem to lose much at all.  This
  34569. was running fine until 3 weeks ago.  The freeze ups seem to happen between
  34570. 6-10pm.  They do not happen on the weekend or ever during the day.  Too much
  34571. of a pattern for me.
  34572. Russ Miescke
  34573. Power Web Connect
  34574.  
  34575. ----- Original Message -----
  34576. Sent: Tuesday, March 30, 1999 12:59 AM
  34577.  
  34578.  
  34579. > I can't remember if they're vulnerable or not...  but there's at least
  34580. > one other possible explanation for those symptoms: running out of RAM.
  34581. > Do a "show mem" every so often and see if you're losing lots of ram over
  34582. > the course of a few days.
  34583. >
  34584. >
  34585. > Mike Andrews (icq 6602506) -- VP & Sysadmin, Digital Crescent, Frankfort
  34586. KY
  34587. > mandrews@dcr.net -=- http://www.termfrost.org --=-=-- "A computer without
  34588. a
  34589. > Microsoft operating system is like a dog without a brick tied to its
  34590. head."
  34591. >
  34592. > On Mon, 29 Mar 1999, Russ Miescke wrote:
  34593. >
  34594. > > Are the Netserver cards susceptible to ping attacks?   If so which ones
  34595. and
  34596. > > what is the command to filter against them?  I seem to be having a
  34597. problem
  34598. > > that looks like the oob attack on an NT machine.  Throughput slows down
  34599. to a
  34600. > > crawl and then just stops.  The Netserver card seems to freeze and must
  34601. be
  34602. > > rebooted.
  34603. > > Russ Miescke
  34604. > > Power Web Connect
  34605. > >
  34606. > >
  34607. > >
  34608. > > -
  34609. > >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34610. > >  with "unsubscribe usr-tc" in the body of the message.
  34611. > >  For information on digests or retrieving files and old messages send
  34612. > >  "help" to the same address.  Do not use quotes in your message.
  34613. > >
  34614. >
  34615. >
  34616. > -
  34617. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34618. >  with "unsubscribe usr-tc" in the body of the message.
  34619. >  For information on digests or retrieving files and old messages send
  34620. >  "help" to the same address.  Do not use quotes in your message.
  34621.  
  34622.  
  34623. -
  34624.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34625.  with "unsubscribe usr-tc" in the body of the message.
  34626.  For information on digests or retrieving files and old messages send
  34627.  "help" to the same address.  Do not use quotes in your message.
  34628.  
  34629.  
  34630. -------------------------------------------------------------------------------
  34631.  
  34632. From: "Russ Miescke" <russm@powerweb.net>
  34633. Subject: Re: (usr-tc) Ping Attacks?
  34634. Date: 30 Mar 1999 02:33:55 -0600
  34635.  
  34636. I have the NT servers patched.  This is only happening to the netserver
  34637. Card.
  34638. Russ Miescke
  34639. Power Web Connect
  34640.  
  34641. ----- Original Message -----
  34642. Sent: Tuesday, March 30, 1999 12:06 AM
  34643.  
  34644.  
  34645. > For what its worth, I block ICMP 8 at the firewall/router to all the
  34646. > netserver net0 IP's... I believe that Microsoft stopped the oob
  34647. > attacks against NT and 95 in a patch several months ago. Have you
  34648. > tried the netstat command on the NT server to see what its talking
  34649. > to?
  34650. >
  34651. > Steve Kinkaid
  34652. > Suncoast Networking
  34653. >
  34654. > >Are the Netserver cards susceptible to ping attacks?   If so which ones
  34655. and
  34656. > >what is the command to filter against them?  I seem to be having a
  34657. problem
  34658. > >that looks like the oob attack on an NT machine.  Throughput slows down
  34659. to a
  34660. > >crawl and then just stops.  The Netserver card seems to freeze and must
  34661. be
  34662. > >rebooted.
  34663. > >Russ Miescke
  34664. > >Power Web Connect
  34665. > >
  34666. > >
  34667. > >
  34668. > >-
  34669. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34670. > > with "unsubscribe usr-tc" in the body of the message.
  34671. > > For information on digests or retrieving files and old messages send
  34672. > > "help" to the same address.  Do not use quotes in your message.
  34673. > >
  34674. > >
  34675. >
  34676. >
  34677. > -
  34678. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34679. >  with "unsubscribe usr-tc" in the body of the message.
  34680. >  For information on digests or retrieving files and old messages send
  34681. >  "help" to the same address.  Do not use quotes in your message.
  34682. >
  34683.  
  34684.  
  34685. -
  34686.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34687.  with "unsubscribe usr-tc" in the body of the message.
  34688.  For information on digests or retrieving files and old messages send
  34689.  "help" to the same address.  Do not use quotes in your message.
  34690.  
  34691.  
  34692. -------------------------------------------------------------------------------
  34693.  
  34694. From: Jeff Mcadams <jeffm@iglou.com>
  34695. Subject: Re: (usr-tc) New PRI rings busy. Any ideas?
  34696. Date: 30 Mar 1999 07:17:43 -0500 (EST)
  34697.  
  34698. Thus spake Suncoast Networking USR Mailbox
  34699. >Up until now we've used GTE for our PRI's setup as NI2. 
  34700. >Our first CLEC PRI went in today on a PRI NIC/NAC with an 
  34701. >existing GTE PRI already operating. e.Spire is showing we
  34702. >have set the pri out of service locally, and all the lines
  34703. >of course get the standard busy signal. I'm showing everything
  34704. >looks good, except that no calls can get through. 
  34705.  
  34706. If you've got all your cause codes set to 17 (normal busy), try changing
  34707. them one by one to 58 (which should generate a fast busy or some sort of
  34708. message depending on the switch) and place a call between each one and
  34709. see when it changes.  That will at least tell you what condition on the
  34710. card is causing the problem...that is *if* the calls are at least
  34711. getting to the card.  I've never known a PRI to get a normal busy when
  34712. the calls aren't even making it to the PRI card, typically you'll get a
  34713. fast busy/all circuits busy message if the telco generates it since
  34714. PRI's are trunk-side.
  34715. -- 
  34716. Jeff McAdams                            Email: jeffm@iglou.com
  34717. Head Network Administrator              Voice: (502) 966-3848
  34718. IgLou Internet Services                        (800) 436-4456
  34719.  
  34720. -
  34721.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34722.  with "unsubscribe usr-tc" in the body of the message.
  34723.  For information on digests or retrieving files and old messages send
  34724.  "help" to the same address.  Do not use quotes in your message.
  34725.  
  34726.  
  34727. -------------------------------------------------------------------------------
  34728.  
  34729. From: usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox)
  34730. Subject: Re: (usr-tc) New PRI rings busy. Any ideas?
  34731. Date: 30 Mar 1999 08:00:31 -0500
  34732.  
  34733. All the cause codes are currently set to 58. Calls to the 
  34734. PRI get a normal busy. Should I try the reverse, setting
  34735. them to 17? 
  34736.  
  34737. Thanks,
  34738.   Steve Kinkaid
  34739.   Suncoast Networking
  34740.  
  34741. >Thus spake Suncoast Networking USR Mailbox
  34742. >>Up until now we've used GTE for our PRI's setup as NI2. 
  34743. >>Our first CLEC PRI went in today on a PRI NIC/NAC with an 
  34744. >>existing GTE PRI already operating. e.Spire is showing we
  34745. >>have set the pri out of service locally, and all the lines
  34746. >>of course get the standard busy signal. I'm showing everything
  34747. >>looks good, except that no calls can get through. 
  34748. >
  34749. >If you've got all your cause codes set to 17 (normal busy), try changing
  34750. >them one by one to 58 (which should generate a fast busy or some sort of
  34751. >message depending on the switch) and place a call between each one and
  34752. >see when it changes.  That will at least tell you what condition on the
  34753. >card is causing the problem...that is *if* the calls are at least
  34754. >getting to the card.  I've never known a PRI to get a normal busy when
  34755. >the calls aren't even making it to the PRI card, typically you'll get a
  34756. >fast busy/all circuits busy message if the telco generates it since
  34757. >PRI's are trunk-side.
  34758. >-- 
  34759. >Jeff McAdams                            Email: jeffm@iglou.com
  34760. >Head Network Administrator              Voice: (502) 966-3848
  34761. >IgLou Internet Services                        (800) 436-4456
  34762. >
  34763. >-
  34764. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34765. > with "unsubscribe usr-tc" in the body of the message.
  34766. > For information on digests or retrieving files and old messages send
  34767. > "help" to the same address.  Do not use quotes in your message.
  34768. >
  34769. >
  34770.  
  34771.  
  34772. -
  34773.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34774.  with "unsubscribe usr-tc" in the body of the message.
  34775.  For information on digests or retrieving files and old messages send
  34776.  "help" to the same address.  Do not use quotes in your message.
  34777.  
  34778.  
  34779. -------------------------------------------------------------------------------
  34780.  
  34781. From: usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox)
  34782. Subject: Re: (usr-tc) New PRI rings busy. Any ideas?
  34783. Date: 30 Mar 1999 08:28:51 -0500
  34784.  
  34785. Ok Steve, your overnight nap is over... I set the cause codes to 17,
  34786. no effect on calls. Still ringing regular busy to all access numbers. 
  34787.  
  34788. Here's the configuration. Again, except for switch type, 
  34789. this setup and configuration is working on the GTE pri's. The only 
  34790. difference is the switch types. 
  34791.  
  34792. Framing Mode ds1ESF
  34793. Line COding Options b8zs
  34794. Response to Loopback - ignore
  34795. Jitter Attenuation attenJitterOnXmtr
  34796. Transmitter Attenuation dB0
  34797. Primary Switch Type Set priSw5ESS
  34798. Idle byte Patter 254 (0xFE)
  34799. Call Proceeding/Connect on Setup on
  34800. ALERTING Response on setup off
  34801. Overlap RX mode diable
  34802. ---
  34803. Cause Codes - All = 58 (Also tried 17 no effect) 
  34804. ----
  34805. PRI Span Block Call Type - blocknone
  34806. ----
  34807. NFAS ID - 0
  34808. NFAS D Channel Use - dchannel
  34809. ----
  34810. DS0 Identification (Blanks)
  34811. Block Call Type = blockNone across the row
  34812. DS0 Assigned Slot Number = 2,3,4,etc (Ignored, using First Avail)
  34813. DS0 Assigned Channel Number = 1,2,3,4,1,etc 
  34814. ----
  34815. DS0 Service Configuration - inService -> Across the row 
  34816.                               except dchannels, notSupported
  34817. ----
  34818. ShortHaulNic - NotApplicable
  34819. ____
  34820.  
  34821. Timing Priority - Tried 1-2, 2-1, no effect.... 
  34822.  
  34823. Steve Kinkaid
  34824. Suncoast Networking
  34825.  
  34826.  
  34827. >All the cause codes are currently set to 58. Calls to the 
  34828. >PRI get a normal busy. Should I try the reverse, setting
  34829. >them to 17? 
  34830. >
  34831. >Thanks,
  34832. >  Steve Kinkaid
  34833. >  Suncoast Networking
  34834. >
  34835. >>Thus spake Suncoast Networking USR Mailbox
  34836. >>>Up until now we've used GTE for our PRI's setup as NI2. 
  34837. >>>Our first CLEC PRI went in today on a PRI NIC/NAC with an 
  34838. >>>existing GTE PRI already operating. e.Spire is showing we
  34839. >>>have set the pri out of service locally, and all the lines
  34840. >>>of course get the standard busy signal. I'm showing everything
  34841. >>>looks good, except that no calls can get through. 
  34842. >>
  34843. >>If you've got all your cause codes set to 17 (normal busy), try changing
  34844. >>them one by one to 58 (which should generate a fast busy or some sort of
  34845. >>message depending on the switch) and place a call between each one and
  34846. >>see when it changes.  That will at least tell you what condition on the
  34847. >>card is causing the problem...that is *if* the calls are at least
  34848. >>getting to the card.  I've never known a PRI to get a normal busy when
  34849. >>the calls aren't even making it to the PRI card, typically you'll get a
  34850. >>fast busy/all circuits busy message if the telco generates it since
  34851. >>PRI's are trunk-side.
  34852. >>-- 
  34853. >>Jeff McAdams                            Email: jeffm@iglou.com
  34854. >>Head Network Administrator              Voice: (502) 966-3848
  34855. >>IgLou Internet Services                        (800) 436-4456
  34856. >>
  34857. >>-
  34858. >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34859. >> with "unsubscribe usr-tc" in the body of the message.
  34860. >> For information on digests or retrieving files and old messages send
  34861. >> "help" to the same address.  Do not use quotes in your message.
  34862. >>
  34863. >>
  34864. >
  34865. >
  34866. >-
  34867. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34868. > with "unsubscribe usr-tc" in the body of the message.
  34869. > For information on digests or retrieving files and old messages send
  34870. > "help" to the same address.  Do not use quotes in your message.
  34871. >
  34872. >
  34873.  
  34874.  
  34875. -
  34876.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34877.  with "unsubscribe usr-tc" in the body of the message.
  34878.  For information on digests or retrieving files and old messages send
  34879.  "help" to the same address.  Do not use quotes in your message.
  34880.  
  34881.  
  34882. -------------------------------------------------------------------------------
  34883.  
  34884. From: Jeff Mcadams <jeffm@iglou.com>
  34885. Subject: Re: (usr-tc) New PRI rings busy. Any ideas?
  34886. Date: 30 Mar 1999 08:33:35 -0500 (EST)
  34887.  
  34888. Thus spake Suncoast Networking USR Mailbox
  34889. >All the cause codes are currently set to 58. Calls to the 
  34890. >PRI get a normal busy. Should I try the reverse, setting
  34891. >them to 17? 
  34892.  
  34893. No, 58 will generate a fast busy...meaning that the calls aren't even
  34894. making it to the PRI card.  Sounds like something is messed up in the
  34895. provisioning somewhere.  :/
  34896. -- 
  34897. Jeff McAdams                            Email: jeffm@iglou.com
  34898. Head Network Administrator              Voice: (502) 966-3848
  34899. IgLou Internet Services                        (800) 436-4456
  34900.  
  34901. -
  34902.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34903.  with "unsubscribe usr-tc" in the body of the message.
  34904.  For information on digests or retrieving files and old messages send
  34905.  "help" to the same address.  Do not use quotes in your message.
  34906.  
  34907.  
  34908. -------------------------------------------------------------------------------
  34909.  
  34910. From: matthews <matthews@brunnet.net>
  34911. Subject: RE: (usr-tc) New PRI rings busy. Any ideas?
  34912. Date: 30 Mar 1999 09:43:07 -0400
  34913.  
  34914. On Tuesday, March 30, 1999 9:29 AM, usrtcmail@flasuncoast.Net 
  34915. [SMTP:usrtcmail@flasuncoast.Net] wrote:
  34916. > Here's the configuration. Again, except for switch type,
  34917. > this setup and configuration is working on the GTE pri's. The only
  34918. > difference is the switch types.
  34919. > ----
  34920. > DS0 Service Configuration - inService -> Across the row
  34921. >                               except dchannels, notSupported
  34922. > ----
  34923.  
  34924. What does your performance monitor tell you in the Timeslot Status and DS0 
  34925. in service state status columns for each DS0?  They should say idle and 
  34926. inService in each column respectively.  Do the telco guys see the trunks 
  34927. and d channel as being up and idle?
  34928.  
  34929.  
  34930.  
  34931. -
  34932.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34933.  with "unsubscribe usr-tc" in the body of the message.
  34934.  For information on digests or retrieving files and old messages send
  34935.  "help" to the same address.  Do not use quotes in your message.
  34936.  
  34937.  
  34938. -------------------------------------------------------------------------------
  34939.  
  34940. From: jeff.binkley@asacomp.com (Jeff Binkley)
  34941. Subject: Re: (usr-tc) New PRI rings busy. Any ideas?
  34942. Date: 30 Mar 1999 09:12:00 -0500
  34943.  
  34944. -> Thus spake Suncoast Networking USR Mailbox
  34945. -> >Up until now we've used GTE for our PRI's setup as NI2.
  34946. -> >Our first CLEC PRI went in today on a PRI NIC/NAC with an
  34947. -> >existing GTE PRI already operating. e.Spire is showing we
  34948. -> >have set the pri out of service locally, and all the lines
  34949. -> >of course get the standard busy signal. I'm showing everything >looks good,
  34950. -> except that no calls can get through.
  34951. ->
  34952. -> If you've got all your cause codes set to 17 (normal busy), try changing
  34953. -> them one by one to 58 (which should generate a fast busy or some sort of
  34954. -> message depending on the switch) and place a call between each one and see
  34955. -> when it changes.  That will at least tell you what condition on the card is
  34956. -> causing the problem...that is *if* the calls are at least getting to the
  34957. -> card.  I've never known a PRI to get a normal busy when the calls aren't
  34958. -> even making it to the PRI card, typically you'll get a fast busy/all
  34959. -> circuits busy message if the telco generates it since PRI's are trunk-side.
  34960.  
  34961. Jeff,
  34962.  
  34963. Is there a listing of all of the cause codes available ?
  34964.  
  34965. Jeff Binkley
  34966. ASA Network Computing
  34967.  
  34968. -
  34969.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  34970.  with "unsubscribe usr-tc" in the body of the message.
  34971.  For information on digests or retrieving files and old messages send
  34972.  "help" to the same address.  Do not use quotes in your message.
  34973.  
  34974.  
  34975. -------------------------------------------------------------------------------
  34976.  
  34977. From: Brian Jacklin <csabmj@mail.tds.net>
  34978. Subject: Re: (usr-tc) New PRI rings busy. Any ideas?
  34979. Date: 30 Mar 1999 08:29:14 -0600 (CST)
  34980.  
  34981. Check out the Active Primary Switch type on  your PRI. 
  34982. With one of the CLEC's we use it was seeing the PRI as 4ESS switch type.
  34983.  We changed the setting and everything worked great.
  34984.  
  34985.  
  34986. > 
  34987. > Ok Steve, your overnight nap is over... I set the cause codes to 17,
  34988. > no effect on calls. Still ringing regular busy to all access numbers. 
  34989. > 
  34990. > Here's the configuration. Again, except for switch type, 
  34991. > this setup and configuration is working on the GTE pri's. The only 
  34992. > difference is the switch types. 
  34993. > 
  34994. > Framing Mode ds1ESF
  34995. > Line COding Options b8zs
  34996. > Response to Loopback - ignore
  34997. > Jitter Attenuation attenJitterOnXmtr
  34998. > Transmitter Attenuation dB0
  34999. > Primary Switch Type Set priSw5ESS
  35000. > Idle byte Patter 254 (0xFE)
  35001. > Call Proceeding/Connect on Setup on
  35002. > ALERTING Response on setup off
  35003. > Overlap RX mode diable
  35004. > ---
  35005. > Cause Codes - All = 58 (Also tried 17 no effect) 
  35006. > ----
  35007. > PRI Span Block Call Type - blocknone
  35008. > ----
  35009. > NFAS ID - 0
  35010. > NFAS D Channel Use - dchannel
  35011. > ----
  35012. > DS0 Identification (Blanks)
  35013. > Block Call Type = blockNone across the row
  35014. > DS0 Assigned Slot Number = 2,3,4,etc (Ignored, using First Avail)
  35015. > DS0 Assigned Channel Number = 1,2,3,4,1,etc 
  35016. > ----
  35017. > DS0 Service Configuration - inService -> Across the row 
  35018. >                               except dchannels, notSupported
  35019. > ----
  35020. > ShortHaulNic - NotApplicable
  35021. > ____
  35022. > 
  35023. > Timing Priority - Tried 1-2, 2-1, no effect.... 
  35024. > 
  35025. > Steve Kinkaid
  35026. > Suncoast Networking
  35027. > 
  35028. > 
  35029. > >All the cause codes are currently set to 58. Calls to the 
  35030. > >PRI get a normal busy. Should I try the reverse, setting
  35031. > >them to 17? 
  35032. > >
  35033. > >Thanks,
  35034. > >  Steve Kinkaid
  35035. > >  Suncoast Networking
  35036. > >
  35037. > >>Thus spake Suncoast Networking USR Mailbox
  35038. > >>>Up until now we've used GTE for our PRI's setup as NI2. 
  35039. > >>>Our first CLEC PRI went in today on a PRI NIC/NAC with an 
  35040. > >>>existing GTE PRI already operating. e.Spire is showing we
  35041. > >>>have set the pri out of service locally, and all the lines
  35042. > >>>of course get the standard busy signal. I'm showing everything
  35043. > >>>looks good, except that no calls can get through. 
  35044. > >>
  35045. > >>If you've got all your cause codes set to 17 (normal busy), try changing
  35046. > >>them one by one to 58 (which should generate a fast busy or some sort of
  35047. > >>message depending on the switch) and place a call between each one and
  35048. > >>see when it changes.  That will at least tell you what condition on the
  35049. > >>card is causing the problem...that is *if* the calls are at least
  35050. > >>getting to the card.  I've never known a PRI to get a normal busy when
  35051. > >>the calls aren't even making it to the PRI card, typically you'll get a
  35052. > >>fast busy/all circuits busy message if the telco generates it since
  35053. > >>PRI's are trunk-side.
  35054. > >>-- 
  35055. > >>Jeff McAdams                            Email: jeffm@iglou.com
  35056. > >>Head Network Administrator              Voice: (502) 966-3848
  35057. > >>IgLou Internet Services                        (800) 436-4456
  35058. > >>
  35059. > >>-
  35060. > >> To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35061. > >> with "unsubscribe usr-tc" in the body of the message.
  35062. > >> For information on digests or retrieving files and old messages send
  35063. > >> "help" to the same address.  Do not use quotes in your message.
  35064. > >>
  35065. > >>
  35066. > >
  35067. > >
  35068. > >-
  35069. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35070. > > with "unsubscribe usr-tc" in the body of the message.
  35071. > > For information on digests or retrieving files and old messages send
  35072. > > "help" to the same address.  Do not use quotes in your message.
  35073. > >
  35074. > >
  35075. > 
  35076. > 
  35077. > -
  35078. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35079. >  with "unsubscribe usr-tc" in the body of the message.
  35080. >  For information on digests or retrieving files and old messages send
  35081. >  "help" to the same address.  Do not use quotes in your message.
  35082. > 
  35083.  
  35084.  
  35085. -
  35086.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35087.  with "unsubscribe usr-tc" in the body of the message.
  35088.  For information on digests or retrieving files and old messages send
  35089.  "help" to the same address.  Do not use quotes in your message.
  35090.  
  35091.  
  35092. -------------------------------------------------------------------------------
  35093.  
  35094. From: Pete Ashdown <pashdown@xmission.com>
  35095. Subject: Re: (usr-tc) Ping Attacks?
  35096. Date: 30 Mar 1999 09:55:18 -0700 (MST)
  35097.  
  35098. Suncoast Networking USR Mailbox said once upon a time:
  35099. >
  35100. >For what its worth, I block ICMP 8 at the firewall/router to all the 
  35101. >netserver net0 IP's... I believe that Microsoft stopped the oob 
  35102. >attacks against NT and 95 in a patch several months ago. Have you
  35103. >tried the netstat command on the NT server to see what its talking 
  35104. >to? 
  35105.  
  35106. I block *ALL* traffic at our borders that is headed to Total Control
  35107. equipment.  There is no good reason (at least on this network) that the
  35108. TC's need to talk to the outside world.
  35109.  
  35110. -
  35111.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35112.  with "unsubscribe usr-tc" in the body of the message.
  35113.  For information on digests or retrieving files and old messages send
  35114.  "help" to the same address.  Do not use quotes in your message.
  35115.  
  35116.  
  35117. -------------------------------------------------------------------------------
  35118.  
  35119. From: usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox)
  35120. Subject: Re: (usr-tc) Ping Attacks?
  35121. Date: 30 Mar 1999 12:48:51 -0500
  35122.  
  35123. Pete, 
  35124.  
  35125. On the Netserver? If you completely blocked the IP of net0, 
  35126. which is essentially a gateway, how will your dial-up users
  35127. traffic route? 
  35128.  
  35129. Steve Kinkaid
  35130. Suncoast Networking
  35131.  
  35132.  
  35133. >Suncoast Networking USR Mailbox said once upon a time:
  35134. >>
  35135. >>For what its worth, I block ICMP 8 at the firewall/router to all the 
  35136. >>netserver net0 IP's... I believe that Microsoft stopped the oob 
  35137. >>attacks against NT and 95 in a patch several months ago. Have you
  35138. >>tried the netstat command on the NT server to see what its talking 
  35139. >>to? 
  35140. >
  35141. >I block *ALL* traffic at our borders that is headed to Total Control
  35142. >equipment.  There is no good reason (at least on this network) that the
  35143. >TC's need to talk to the outside world.
  35144. >
  35145. >-
  35146. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35147. > with "unsubscribe usr-tc" in the body of the message.
  35148. > For information on digests or retrieving files and old messages send
  35149. > "help" to the same address.  Do not use quotes in your message.
  35150. >
  35151. >
  35152.  
  35153.  
  35154. -
  35155.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35156.  with "unsubscribe usr-tc" in the body of the message.
  35157.  For information on digests or retrieving files and old messages send
  35158.  "help" to the same address.  Do not use quotes in your message.
  35159.  
  35160.  
  35161. -------------------------------------------------------------------------------
  35162.  
  35163. From: Brian <signal@shreve.net>
  35164. Subject: Re: (usr-tc) Ping Attacks?
  35165. Date: 30 Mar 1999 11:51:20 -0600 (EST)
  35166.  
  35167. On Tue, 30 Mar 1999, Pete Ashdown wrote:
  35168.  
  35169. > Suncoast Networking USR Mailbox said once upon a time:
  35170. > >
  35171. > >For what its worth, I block ICMP 8 at the firewall/router to all the 
  35172. > >netserver net0 IP's... I believe that Microsoft stopped the oob 
  35173. > >attacks against NT and 95 in a patch several months ago. Have you
  35174. > >tried the netstat command on the NT server to see what its talking 
  35175. > >to? 
  35176. > 
  35177. > I block *ALL* traffic at our borders that is headed to Total Control
  35178. > equipment.  There is no good reason (at least on this network) that the
  35179. > TC's need to talk to the outside world.
  35180.  
  35181. We use a whitelist on our access controls on our border, everything is
  35182. denied, and only specifics are permitted, such as web to the webserver,
  35183. etc.  Nothing is permitted to the TC's.  Of course the dynamic ip pools
  35184. are unrestrictred.
  35185.  
  35186.  
  35187. > 
  35188. > -
  35189. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35190. >  with "unsubscribe usr-tc" in the body of the message.
  35191. >  For information on digests or retrieving files and old messages send
  35192. >  "help" to the same address.  Do not use quotes in your message.
  35193. > 
  35194.  
  35195. Brian Feeny (BF304)     signal@shreve.net   
  35196. 318-222-2638 x 109    http://www.shreve.net/~signal      
  35197. Network Administrator   ShreveNet Inc. (ASN 11881)           
  35198.  
  35199.  
  35200. -
  35201.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35202.  with "unsubscribe usr-tc" in the body of the message.
  35203.  For information on digests or retrieving files and old messages send
  35204.  "help" to the same address.  Do not use quotes in your message.
  35205.  
  35206.  
  35207. -------------------------------------------------------------------------------
  35208.  
  35209. From: Brian <signal@shreve.net>
  35210. Subject: Re: (usr-tc) Ping Attacks?
  35211. Date: 30 Mar 1999 11:53:59 -0600 (EST)
  35212.  
  35213. On Tue, 30 Mar 1999, Suncoast Networking USR Mailbox wrote:
  35214.  
  35215. > Pete, 
  35216. > 
  35217. > On the Netserver? If you completely blocked the IP of net0, 
  35218. > which is essentially a gateway, how will your dial-up users
  35219. > traffic route? 
  35220. > 
  35221. > Steve Kinkaid
  35222. > Suncoast Networking
  35223.  
  35224. right, its a gateway, that talks to an ethernet interface on/behind his
  35225. border.  There is no reason for packets to come from accross the border
  35226. and too eth interfaces of his ARC's/Netservers.
  35227.  
  35228. Traffic to the dialup ip pools I am sure is unrestricted, or with very
  35229. little restriction (we block port 25 on outgoing from dynamic ip pools).
  35230.  
  35231. Smart ISP's would block all traffic to their lan, accept for what is
  35232. implicity allowed, such as mail to mail server, web to webserver, dns to
  35233. nameservers, etc.  the other approach is to allow all, and deny the bad
  35234. guys, but that is a bad way of doing it, I would argue its better to treat
  35235. all traffic as bad, accept for what you deam good.
  35236.  
  35237.  
  35238.  
  35239. > 
  35240. > 
  35241. > >Suncoast Networking USR Mailbox said once upon a time:
  35242. > >>
  35243. > >>For what its worth, I block ICMP 8 at the firewall/router to all the 
  35244. > >>netserver net0 IP's... I believe that Microsoft stopped the oob 
  35245. > >>attacks against NT and 95 in a patch several months ago. Have you
  35246. > >>tried the netstat command on the NT server to see what its talking 
  35247. > >>to? 
  35248. > >
  35249. > >I block *ALL* traffic at our borders that is headed to Total Control
  35250. > >equipment.  There is no good reason (at least on this network) that the
  35251. > >TC's need to talk to the outside world.
  35252. > >
  35253. > >-
  35254. > > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35255. > > with "unsubscribe usr-tc" in the body of the message.
  35256. > > For information on digests or retrieving files and old messages send
  35257. > > "help" to the same address.  Do not use quotes in your message.
  35258. > >
  35259. > >
  35260. > 
  35261. > 
  35262. > -
  35263. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35264. >  with "unsubscribe usr-tc" in the body of the message.
  35265. >  For information on digests or retrieving files and old messages send
  35266. >  "help" to the same address.  Do not use quotes in your message.
  35267. > 
  35268.  
  35269. Brian Feeny (BF304)     signal@shreve.net   
  35270. 318-222-2638 x 109    http://www.shreve.net/~signal      
  35271. Network Administrator   ShreveNet Inc. (ASN 11881)           
  35272.  
  35273.  
  35274. -
  35275.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35276.  with "unsubscribe usr-tc" in the body of the message.
  35277.  For information on digests or retrieving files and old messages send
  35278.  "help" to the same address.  Do not use quotes in your message.
  35279.  
  35280.  
  35281. -------------------------------------------------------------------------------
  35282.  
  35283. From: "Mark Starr" <squid@greenapple.com>
  35284. Subject: (usr-tc) MPIP
  35285. Date: 30 Mar 1999 14:06:30 -0500
  35286.  
  35287. I set up the MPIP stuff and have noticed that on the hub acting as the
  35288. server, it keeps bundles alive even though the user has dropped. Any ideal
  35289. on how to manually remove MPIP links from the server?
  35290.  
  35291. Thanks,
  35292. Mark
  35293. Green Apple Inc
  35294.  
  35295.  
  35296. -
  35297.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35298.  with "unsubscribe usr-tc" in the body of the message.
  35299.  For information on digests or retrieving files and old messages send
  35300.  "help" to the same address.  Do not use quotes in your message.
  35301.  
  35302.  
  35303. -------------------------------------------------------------------------------
  35304.  
  35305. From: David Bolen <db3l@ans.net>
  35306. Subject: Re: (usr-tc) New PRI rings busy. Any ideas?
  35307. Date: 30 Mar 1999 14:36:56 EST
  35308.  
  35309. usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes:
  35310.  
  35311. > Ok Steve, your overnight nap is over... I set the cause codes to 17,
  35312. > no effect on calls. Still ringing regular busy to all access numbers. 
  35313.  
  35314. If you can receive and/or log SNMP traps, enable the PRI span level
  35315. traps for the card in question, at a minimum either "callArriveEvent"
  35316. or "callTermFailedEvent".
  35317.  
  35318. The arrive trap is generated the instant that the PRI card gets an
  35319. inbound call signal (setup message on the D channel) from the telco -
  35320. regardless of whether or not it is going to be able to service the
  35321. call.
  35322.  
  35323. The failed trap is generated anytime the PRI gets a call arrival
  35324. indication (D channel setup) but is unable for any reason to service
  35325. the call, connecting it to some other device (modem or NETServer) in
  35326. the hub.
  35327.  
  35328. If you don't receive either of these traps, then the telco isn't even
  35329. sending calls to your card, and the problem is earlier than the card.
  35330. If you do receive the traps, the failed trap contains some reason
  35331. information for the failure that may help.
  35332.  
  35333. You might also check the debug screen (Ctrl-D) option 11 (call control
  35334. counters) and print the error counters.  That might give some insight
  35335. into any cases where the PRI got a call but couldn't deliver it
  35336. successfully to a modem.  You can then track these to specific modems
  35337. using option 10 (IGW/QBMDM information) suboption 11 (Mdm Dev Table)
  35338. to get various call counters on a per modem basis.  There are some
  35339. other counters to check calls that may have been dropped for other
  35340. reasons.
  35341.  
  35342. -- David
  35343.  
  35344. /-----------------------------------------------------------------------\
  35345.  \               David Bolen              \  Internet: db3l@ans.net    /
  35346.   |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  35347.  / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  35348. \-----------------------------------------------------------------------/
  35349.  
  35350. -
  35351.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35352.  with "unsubscribe usr-tc" in the body of the message.
  35353.  For information on digests or retrieving files and old messages send
  35354.  "help" to the same address.  Do not use quotes in your message.
  35355.  
  35356.  
  35357. -------------------------------------------------------------------------------
  35358.  
  35359. From: usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox)
  35360. Subject: Re: (usr-tc) New PRI rings busy. Any ideas?
  35361. Date: 30 Mar 1999 17:51:47 -0500
  35362.  
  35363. Now that is cool!! (Control-D) Thank you! 
  35364.  
  35365. Option 11 shows no errors. Option 10 GPF's the card. Option 4 shows 
  35366. some interesting call control debugging information. When I unplug 
  35367. or plug in Span 0, it detects it, and reports the span is down, up, 
  35368. etc. But calling the associated numbers to that PRI don't show up 
  35369. here at all. I'll have to spend a little more time to see what I 
  35370. can glean from those SNMP strings. 
  35371.  
  35372. I kicked it back to the CLEC this morning. They said they would
  35373. get back with me. They turned it over to the switch guys. I've 
  35374. continued to work on it on and off today, but now I'm pretty certain 
  35375. the problem is not with the TC. 
  35376.  
  35377. The response has been fantastic! Thanks for all the great suggestions!
  35378.  
  35379. Steve Kinkaid
  35380. Suncoast Networking
  35381. Largo, Florida
  35382.  
  35383.  
  35384. >usrtcmail@flasuncoast.Net (Suncoast Networking USR Mailbox) writes:
  35385. >
  35386. >> Ok Steve, your overnight nap is over... I set the cause codes to 17,
  35387. >> no effect on calls. Still ringing regular busy to all access numbers. 
  35388. >
  35389. >If you can receive and/or log SNMP traps, enable the PRI span level
  35390. >traps for the card in question, at a minimum either "callArriveEvent"
  35391. >or "callTermFailedEvent".
  35392. >
  35393. >The arrive trap is generated the instant that the PRI card gets an
  35394. >inbound call signal (setup message on the D channel) from the telco -
  35395. >regardless of whether or not it is going to be able to service the
  35396. >call.
  35397. >
  35398. >The failed trap is generated anytime the PRI gets a call arrival
  35399. >indication (D channel setup) but is unable for any reason to service
  35400. >the call, connecting it to some other device (modem or NETServer) in
  35401. >the hub.
  35402. >
  35403. >If you don't receive either of these traps, then the telco isn't even
  35404. >sending calls to your card, and the problem is earlier than the card.
  35405. >If you do receive the traps, the failed trap contains some reason
  35406. >information for the failure that may help.
  35407. >
  35408. >You might also check the debug screen (Ctrl-D) option 11 (call control
  35409. >counters) and print the error counters.  That might give some insight
  35410. >into any cases where the PRI got a call but couldn't deliver it
  35411. >successfully to a modem.  You can then track these to specific modems
  35412. >using option 10 (IGW/QBMDM information) suboption 11 (Mdm Dev Table)
  35413. >to get various call counters on a per modem basis.  There are some
  35414. >other counters to check calls that may have been dropped for other
  35415. >reasons.
  35416. >
  35417. >-- David
  35418. >
  35419. >/-----------------------------------------------------------------------\
  35420. > \               David Bolen              \  Internet: db3l@ans.net    /
  35421. >  |        UUNET Technologies, Inc.         \   Phone: (914) 701-5327 |
  35422. > / 100 Manhattanville Rd, Purchase, NY 10577  \   Fax: (914) 701-5310  \
  35423. >\-----------------------------------------------------------------------/
  35424. >
  35425. >-
  35426. > To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35427. > with "unsubscribe usr-tc" in the body of the message.
  35428. > For information on digests or retrieving files and old messages send
  35429. > "help" to the same address.  Do not use quotes in your message.
  35430. >
  35431. >
  35432.  
  35433.  
  35434. -
  35435.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35436.  with "unsubscribe usr-tc" in the body of the message.
  35437.  For information on digests or retrieving files and old messages send
  35438.  "help" to the same address.  Do not use quotes in your message.
  35439.  
  35440.  
  35441. -------------------------------------------------------------------------------
  35442.  
  35443. From: Robert von Bismarck <rvb@petrel.ch>
  35444. Subject: (usr-tc) HELP ! PRI won't come back...
  35445. Date: 31 Mar 1999 17:11:56 +0200
  35446.  
  35447. Guys,
  35448.  
  35449. I got a problem here with power fluctuations, and while the electricians
  35450. find out what is going on, and fix it, my PRI's are getting toasted every
  35451. now and then (UPS won't catch it, it's a neutral/mass thing with the PRI
  35452. boxes from the telco).
  35453.  
  35454. Symptoms : D-Channel goes down, and stays down. I need a hardware reset on
  35455. the HDM to reset it, so it comes back up. Sometimes a receiver reframe
  35456. works, sometimes not.
  35457.  
  35458. I'm running HDM's with 1.2.5 code on E1/PRI's here (30 channels) fed from an
  35459. Alcatel VN-6 switch (speaks DSS1)
  35460.  
  35461. The thing that has me worried is that the PRI's won't come back up, unless I
  35462. force 'em through TCM or console.
  35463.  
  35464. Has anyone seen this, found a fix ?
  35465.  
  35466. I was wondering if raising the receiver gain would change anything, but I
  35467. can't really experiment with the equipment as it's in production...
  35468.  
  35469. Thanks for any help,
  35470.  
  35471. Robert
  35472.  
  35473.  
  35474.  
  35475. --
  35476. Robert von Bismarck
  35477. Network Systems Engineer
  35478. Petrel Communications SA / SPAN
  35479. Tel : +41 22 304 47 47
  35480. Fax : +41 22 300 48 43
  35481. WWW : http://www.petrel.ch
  35482. e-mail : rvb@petrel.ch
  35483.  
  35484. -
  35485.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35486.  with "unsubscribe usr-tc" in the body of the message.
  35487.  For information on digests or retrieving files and old messages send
  35488.  "help" to the same address.  Do not use quotes in your message.
  35489.  
  35490.  
  35491. -------------------------------------------------------------------------------
  35492.  
  35493. From: "Chris Ashcraft" <Chris_Ashcraft@mw.3com.com>
  35494. Subject: (usr-tc) Dedicated DSP modem
  35495. Date: 31 Mar 1999 09:48:54 -0600
  35496.  
  35497.  
  35498.  
  35499. Hi Scott,
  35500. Having TelCo assign a number to a specific DS0 would be the easiest way.
  35501.    Ask TelCo for two phone numbers: one for the dedicated DS0 and one for the
  35502.    hunt group.  Make sure the dedicated DS0 is not in the hunt group.
  35503.    Map the dedicated DS0 to the modem you want to dedicate for this application.
  35504.    By default, the DS0s directly correspond to the modem (i.e. DS0 3  and modem
  35505.    3, DS0 7 and modem 7).  To view your mapping configuration, check timeslot
  35506.    mapping.
  35507.    Configure the modems for fixed assignment.
  35508.    Save the configuration to the NMCs NVRAM.
  35509.  
  35510. If you have questions about the specifics, let me know.
  35511.  
  35512. Also, one drawback is you would overwork some modems because of fixed
  35513. assignment.  In my opinion, a Quad Modem would be best for this application.
  35514. But it will definitely work with a HiPer DSP as well.
  35515.  
  35516. All the best
  35517. /Chris
  35518. 3Com
  35519.  
  35520. ____________________________________________________________________________
  35521.  
  35522. I currently have a call in to the telco to see if they assign a POTS number
  35523. to a single channel and make it separate from the POTS number assigned to
  35524. the rest of the channels.  They're quite sure they can but they have yet to
  35525. get back to me.  I think that would effectively accomplish what you're
  35526. trying to do without having to bugger with the DSP configuration.
  35527.  
  35528.  
  35529. On Wednesday, March 17, 1999 3:56 PM, Network Administrator
  35530. [SMTP:netadmin@seidata.com] wrote:
  35531. >
  35532. > I am working to implementing a dedicated modem from a DSP card. The modem
  35533. > would be free from the hunt group on the T1. I was curious if someone had
  35534. a
  35535. > clue on how to configure the DSP or ARC card for this feature. I have
  35536. read
  35537. > through several pages of manuals, but this feature is not mentioned. At
  35538. > least I have not come across it. I am running the following software
  35539. > versions:
  35540. > NMC  5.5.5
  35541. > ARC  4.1.59
  35542. > DSP  1.2.59
  35543. >
  35544. >
  35545. > Scott Childers
  35546. > Network Systems Manager
  35547. > SEI Data Network Services
  35548. > http://www.seidata.com
  35549. > VenusNet
  35550. > http://www.venus.net
  35551.  
  35552. -
  35553.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35554.  with "unsubscribe usr-tc" in the body of the message.
  35555.  For information on digests or retrieving files and old messages send
  35556.  "help" to the same address.  Do not use quotes in your message.
  35557.  
  35558.  
  35559. -------------------------------------------------------------------------------
  35560.  
  35561. From: "Billy Huddleston" <billy@nxs.net>
  35562. Subject: (usr-tc) HyperARC and Cisco 804's
  35563. Date: 31 Mar 1999 15:20:42 -0500
  35564.  
  35565. Has anyone had problems with Cisco 804's doing Multilink PPP? If so how did
  35566. you fix the problem?
  35567.  
  35568. Thanks, Billy Huddleston
  35569.  
  35570.              +--------------------------------------------------+
  35571.              | Billy Huddleston           System Administrator  |
  35572.              | Net-Express               http://www.nxs.net     |
  35573.              | 114 Sherway Rd.          Voice: 423-691-2014     |
  35574.              | Knoxville, TN  37922       Fax: 423-691-9894     |
  35575.              | billy@nxs.net                                    |
  35576.              +--------------------------------------------------+
  35577.  
  35578.  
  35579. -
  35580.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35581.  with "unsubscribe usr-tc" in the body of the message.
  35582.  For information on digests or retrieving files and old messages send
  35583.  "help" to the same address.  Do not use quotes in your message.
  35584.  
  35585.  
  35586. -------------------------------------------------------------------------------
  35587.  
  35588. From: Carl Litt <carl@execulink.com>
  35589. Subject: Re: (usr-tc) Call Failure Logging
  35590. Date: 31 Mar 1999 17:01:29 -0500 (EST)
  35591.  
  35592.  
  35593. The DMS100 here is set to 255ms.
  35594.  
  35595. Either way, I don't think it's relevant in this case.  The switch is
  35596. routing calls by least-recently-used, and the DSP's are using fixed
  35597. assignment.
  35598.  
  35599. Except in cases where the POP is full, it would be a relatively long time
  35600. before that DS0 (and associated modem) was reused.  And as I noted, this
  35601. behaviour can be seen early in the day, when the POP is mostly open.
  35602.  
  35603. The failure reason given is almost always "carrierLoss".  At times when
  35604. we are near full, I can make calls and have unusual tones from the modem
  35605. (either constant retraining, or one long solid tone).
  35606.  
  35607. On Thu, 25 Mar 1999 ISPCnsl001@aol.com wrote:
  35608.  
  35609. > >  Has anyone bothered counting the number of call failures on the
  35610. > >  DSP's?  I have included a script below which parses through our
  35611. > >  SNMP trap logs and generates a simple report on the number of call
  35612. > >  failures ordered by modem.  The values get reset every midnight.
  35613. > >  
  35614. > >  Here is a sample of what you get.  Note that this report was generated
  35615. > >  mid afternoon.  I've confident that the top 7 modems have not
  35616. > >  had a successful call today.
  35617. > 
  35618. > What are your reason's for call failure?  
  35619. > I'm not sure how your call routing is set up on your DMS 100 or how you have
  35620. > it set up on the DSP's but I'll bet the guard time you have specified on your
  35621. > DMS 100 is default; which is 70ms I believe.  This has been discussed on the
  35622. > list before but I would try changing it to 250ms.  This will give the modems
  35623. > more time to reset and make themselves available to take a call after the last
  35624. > call disconnects.  You can change this setting on the fly and since you are
  35625. > the telco you will be able to do it in a minute.  If this doesn't solve your
  35626. > trouble then please give details on the reasons for call failure as reported
  35627. > by the modems
  35628. > 
  35629. > Brian
  35630.  
  35631.  
  35632.  
  35633. -
  35634.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35635.  with "unsubscribe usr-tc" in the body of the message.
  35636.  For information on digests or retrieving files and old messages send
  35637.  "help" to the same address.  Do not use quotes in your message.
  35638.  
  35639.  
  35640. -------------------------------------------------------------------------------
  35641.  
  35642. From: "Eric Billeter" <ebilleter@cableone.net>
  35643. Subject: (usr-tc) DSP modem failure reason
  35644. Date: 31 Mar 1999 15:22:01 -0700
  35645.  
  35646. Currently I have 2 modems on a DSP card (modem 5 and 6) which will fail
  35647. every
  35648. connection attempt.  The following is displayed in TCM for call failure
  35649. reason.
  35650.  
  35651. noDSPRespToKA(95)
  35652.  
  35653. I recently updated the code on the cards to 1.2.43 restored from defaults
  35654. etc..
  35655. Anyone else seen this or any insights on what this error is.  These are
  35656. running on
  35657. channelized T1 circuits. None of my other sites or cards in this chassis
  35658. exhibit
  35659. similar failures.
  35660.  
  35661. Eric T. Billeter                   Cable One
  35662. Internet Engineer                  1314 North 3rd Street
  35663. ebilleter@cableone.net             Phoenix, AZ 85004
  35664.  
  35665.  
  35666.  
  35667.  
  35668. -
  35669.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35670.  with "unsubscribe usr-tc" in the body of the message.
  35671.  For information on digests or retrieving files and old messages send
  35672.  "help" to the same address.  Do not use quotes in your message.
  35673.  
  35674.  
  35675. -------------------------------------------------------------------------------
  35676.  
  35677. From: Blake Fithen <fithen@NetworksPlus.com>
  35678. Subject: RE: (usr-tc) HyperARC and Cisco 804's
  35679. Date: 31 Mar 1999 16:24:18 -0600
  35680.  
  35681. We've got three setup and going flawlessly.  Email me 
  35682. privately if you want the config's.
  35683.  
  35684. blake
  35685.  
  35686. > -----Original Message-----
  35687. > From: Billy Huddleston [mailto:billy@nxs.net]
  35688. > Sent: Wednesday, March 31, 1999 2:21 PM
  35689. > To: usr-tc@lists.xmission.com
  35690. > Subject: (usr-tc) HyperARC and Cisco 804's
  35691. > 
  35692. > 
  35693. > Has anyone had problems with Cisco 804's doing Multilink PPP? 
  35694. > If so how did
  35695. > you fix the problem?
  35696. > 
  35697. > Thanks, Billy Huddleston
  35698. > 
  35699. >              +--------------------------------------------------+
  35700. >              | Billy Huddleston           System Administrator  |
  35701. >              | Net-Express               http://www.nxs.net     |
  35702. >              | 114 Sherway Rd.          Voice: 423-691-2014     |
  35703. >              | Knoxville, TN  37922       Fax: 423-691-9894     |
  35704. >              | billy@nxs.net                                    |
  35705. >              +--------------------------------------------------+
  35706. > 
  35707. > 
  35708. > -
  35709. >  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35710. >  with "unsubscribe usr-tc" in the body of the message.
  35711. >  For information on digests or retrieving files and old messages send
  35712. >  "help" to the same address.  Do not use quotes in your message.
  35713. > 
  35714.  
  35715. -
  35716.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35717.  with "unsubscribe usr-tc" in the body of the message.
  35718.  For information on digests or retrieving files and old messages send
  35719.  "help" to the same address.  Do not use quotes in your message.
  35720.  
  35721.  
  35722. -------------------------------------------------------------------------------
  35723.  
  35724. From: "David Bachta" <David_Bachta@mw.3com.com>
  35725. Subject: Re: (usr-tc) DSP modem failure reason
  35726. Date: 31 Mar 1999 17:44:58 -0600
  35727.  
  35728.  
  35729.  
  35730. Hi Eric,
  35731.  
  35732. Does this problem persist even after a reboot?  Have you tried re-seating the
  35733. card in the chassis?  Is it only happening after upgrading to 1.2.43?
  35734.  
  35735. This could be a DSP chip failure.  The call failure reason translates to 'no DSP
  35736. response to Keep Alive messages' which means 1 of your DSP chips is not
  35737. responding to keep alive messages from the operational code.
  35738.  
  35739. Regards,
  35740. David
  35741.  
  35742.  
  35743.  
  35744.  
  35745. "Eric Billeter" <ebilleter@cableone.net> on 03/31/99 04:22:01 PM
  35746.  
  35747. Please respond to usr-tc@lists.xmission.com
  35748.  
  35749. cc:    (David Bachta/MW/US/3Com)
  35750.  
  35751.  
  35752.  
  35753.  
  35754. Currently I have 2 modems on a DSP card (modem 5 and 6) which will fail
  35755. every
  35756. connection attempt.  The following is displayed in TCM for call failure
  35757. reason.
  35758.  
  35759. noDSPRespToKA(95)
  35760.  
  35761. I recently updated the code on the cards to 1.2.43 restored from defaults
  35762. etc..
  35763. Anyone else seen this or any insights on what this error is.  These are
  35764. running on
  35765. channelized T1 circuits. None of my other sites or cards in this chassis
  35766. exhibit
  35767. similar failures.
  35768.  
  35769. Eric T. Billeter                   Cable One
  35770. Internet Engineer                  1314 North 3rd Street
  35771. ebilleter@cableone.net             Phoenix, AZ 85004
  35772.  
  35773.  
  35774.  
  35775.  
  35776. -
  35777.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35778.  with "unsubscribe usr-tc" in the body of the message.
  35779.  For information on digests or retrieving files and old messages send
  35780.  "help" to the same address.  Do not use quotes in your message.
  35781.  
  35782.  
  35783.  
  35784.  
  35785.  
  35786.  
  35787.  
  35788.  
  35789. -
  35790.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35791.  with "unsubscribe usr-tc" in the body of the message.
  35792.  For information on digests or retrieving files and old messages send
  35793.  "help" to the same address.  Do not use quotes in your message.
  35794.  
  35795.  
  35796. -------------------------------------------------------------------------------
  35797.  
  35798. From: Carl Litt <carl@execulink.com>
  35799. Subject: Re: (usr-tc) Call Failure Logging
  35800. Date: 31 Mar 1999 17:01:29 -0500 (EST)
  35801.  
  35802.  
  35803. The DMS100 here is set to 255ms.
  35804.  
  35805. Either way, I don't think it's relevant in this case.  The switch is
  35806. routing calls by least-recently-used, and the DSP's are using fixed
  35807. assignment.
  35808.  
  35809. Except in cases where the POP is full, it would be a relatively long time
  35810. before that DS0 (and associated modem) was reused.  And as I noted, this
  35811. behaviour can be seen early in the day, when the POP is mostly open.
  35812.  
  35813. The failure reason given is almost always "carrierLoss".  At times when
  35814. we are near full, I can make calls and have unusual tones from the modem
  35815. (either constant retraining, or one long solid tone).
  35816.  
  35817. On Thu, 25 Mar 1999 ISPCnsl001@aol.com wrote:
  35818.  
  35819. > >  Has anyone bothered counting the number of call failures on the
  35820. > >  DSP's?  I have included a script below which parses through our
  35821. > >  SNMP trap logs and generates a simple report on the number of call
  35822. > >  failures ordered by modem.  The values get reset every midnight.
  35823. > >  
  35824. > >  Here is a sample of what you get.  Note that this report was generated
  35825. > >  mid afternoon.  I've confident that the top 7 modems have not
  35826. > >  had a successful call today.
  35827. > 
  35828. > What are your reason's for call failure?  
  35829. > I'm not sure how your call routing is set up on your DMS 100 or how you have
  35830. > it set up on the DSP's but I'll bet the guard time you have specified on your
  35831. > DMS 100 is default; which is 70ms I believe.  This has been discussed on the
  35832. > list before but I would try changing it to 250ms.  This will give the modems
  35833. > more time to reset and make themselves available to take a call after the last
  35834. > call disconnects.  You can change this setting on the fly and since you are
  35835. > the telco you will be able to do it in a minute.  If this doesn't solve your
  35836. > trouble then please give details on the reasons for call failure as reported
  35837. > by the modems
  35838. > 
  35839. > Brian
  35840.  
  35841.  
  35842.  
  35843. -
  35844.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35845.  with "unsubscribe usr-tc" in the body of the message.
  35846.  For information on digests or retrieving files and old messages send
  35847.  "help" to the same address.  Do not use quotes in your message.
  35848.  
  35849.  
  35850. -------------------------------------------------------------------------------
  35851.  
  35852. From: "Matthew Pearson" <mpearson@tiac.net>
  35853. Subject: (usr-tc) How do you setup Multilink PPP on a HiperARC?
  35854. Date: 31 Mar 1999 21:57:22 -0500
  35855.  
  35856. Anyone have a quick doc on this? I've scoured 3com's site with no luck!
  35857.  
  35858. Help!
  35859.  
  35860. Thanks
  35861.  
  35862. -
  35863.  To unsubscribe to usr-tc, send an email to "majordomo@xmission.com"
  35864.  with "unsubscribe usr-tc" in the body of the message.
  35865.  For information on digests or retrieving files and old messages send
  35866.  "help" to the same address.  Do not use quotes in your message.
  35867.  
  35868.